From noreply@sourceforge.net  Mon Apr  1 00:14:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 16:14:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-537533 ] Grossly inefficient re
Message-ID: <E16rpSZ-0000hu-00@usw-sf-web3.sourceforge.net>

Bugs item #537533, was opened at 2002-03-31 17:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537533&group_id=5470

Category: Regular Expressions
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Pekka Pessi (ppessi)
>Assigned to: Tim Peters (tim_one)
Summary: Grossly inefficient re

Initial Comment:
Here is a regexp (ported from a awk script,
supposed to match C comments):

/[*][^*]*([*]+[^/][^*]+)*[*]+/

The regexp is *sometimes* *very* slow when run in
Python. Also, while replacing the regexp with
sub(), the Python interpreter is in deep recursion
in sre and does not respond to any signals.

I *think* this should be a O(N) regexp.

An example script demonstrating the problem is
attached. I have an example where adding two
characters to the input makes the re.sub() some
250000 times longer to execute.

There was no noticeable difference between sre and
pre modules.

I have a RedHat 7.2 box with a 600 MHz
PentiumIII, I'm using is Python 2.2 Linux RPMs
by Sean Reifschneider <jafo-rpms@tummy.com>:

Python 2.2 (#1, Dec 23 2001, 09:30:32) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2

Same problem applies to the Python 1.5.2 provided by
Redhat:
Python 1.5.2 (#1, Jul  5 2001, 03:02:19)  [GCC 2.96
20000731 (Red Hat Linux 7.1 2 on linux-i386
Copyright 1991-1995 Stichting Mathematisch Centrum,
Amsterdam


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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-31 19:14

Message:
Logged In: YES 
user_id=31435

No, it's not necessarily linear-time when it fails to 
match, as it does so fail in your second string.  Then you 
have 17 instances of "**" stacked up via your [*]+, and it 
has to backtrack through 2**17 = 128K possibilities (at 
each of the 17 points, whether to match one or two *s).  It 
will run enormously faster in fails-to-match cases if you 
simply change [*]+ to [*].  The failing case will run just 
as fast as the successful one then.

If you've read Friedl, the general unrolling pattern is

normal* (special normal*)*

Changing special to special+ instead can be a disaster in 
failing cases, as you've discovered here.  That's why 
Friedl didn't write it "special+" to begin with <wink>.

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

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


From noreply@sourceforge.net  Mon Apr  1 02:42:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 18:42:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-537582 ] incorrect pid returned from os.spawn
Message-ID: <E16rrm3-0007iq-00@usw-sf-web2.sourceforge.net>

Bugs item #537582, was opened at 2002-04-01 02:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537582&group_id=5470

Category: Windows
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: alastair nicol (ajnicol)
Assigned to: Tim Peters (tim_one)
Summary: incorrect pid returned from os.spawn

Initial Comment:
The pid returned from the os.spawnv and os.spawnl method
is incorrect.

This can be easily demostrated by swawning a python
prog containing "time.sleep(100000)". The pid returned
by spawn isnt the same as the pid as reported by task
manager. 

I have only tried this with os.spawnl and os.spawnv

For example:-
spawnv reported pid=92
windows reported pid=1484

Software:
Python 2.2 (downloaded .exe from python.org)
Windows 2000 Pro

Al

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

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


From noreply@sourceforge.net  Mon Apr  1 03:17:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 19:17:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-537582 ] incorrect pid returned from os.spawn
Message-ID: <E16rsJw-0007vo-00@usw-sf-web1.sourceforge.net>

Bugs item #537582, was opened at 2002-03-31 21:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537582&group_id=5470

>Category: Documentation
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: alastair nicol (ajnicol)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect pid returned from os.spawn

Initial Comment:
The pid returned from the os.spawnv and os.spawnl method
is incorrect.

This can be easily demostrated by swawning a python
prog containing "time.sleep(100000)". The pid returned
by spawn isnt the same as the pid as reported by task
manager. 

I have only tried this with os.spawnl and os.spawnv

For example:-
spawnv reported pid=92
windows reported pid=1484

Software:
Python 2.2 (downloaded .exe from python.org)
Windows 2000 Pro

Al

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

>Comment By: Tim Peters (tim_one)
Date: 2002-03-31 22:17

Message:
Logged In: YES 
user_id=31435

There's nothing wrong with what the spawn functions return 
on Windows -- indeed, they return exactly what the 
Microsoft spawn functions return.

The problem is that, on Windows, processes have 
both "process handles" and "process ids", they're both 
integers, and Microsoft's own docs confuse the two 
routinely.  "process handle" is the better name for what 
spawn returns on Windows.  You wouldn't want it to return 
the process id:  almost all Win32 API functions require a 
process handle.

Reassigned to Fred and changed category to Docs:  Fred, can 
you fiddle things to explain that the spawn family really 
returns what Windows calls a "process handle"?  Ditto that 
os.waitpid() in 2.3 on Windows takes a process handle as 
argument?

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

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


From noreply@sourceforge.net  Mon Apr  1 05:35:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 21:35:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-537484 ] SMTPLib sendmail fails on hyphenated adr
Message-ID: <E16ruTB-00011A-00@usw-sf-web2.sourceforge.net>

Bugs item #537484, was opened at 2002-03-31 14:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537484&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Anderson (shadowlore)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: SMTPLib sendmail fails on hyphenated adr

Initial Comment:
When using smtplib's SMTP.sendmail, if the To: address
contains a hyphen, the To: header will be silently dropped.

To duplicate:

Follow the docstring for smtplib.SMTP.sendmail, and use
a hyphenated email address, such as foo-help@somewhere.org






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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-01 00:35

Message:
Logged In: YES 
user_id=12800

I don't believe it.  I use smtplib all the time to send
messages to Mailman addresses that contain hyphens and I've
never seen a problem, going back to Python 1.5.2 and up to
Python 2.3(cvs).

Note that as far as the SMTP protocol is concerned, and
smtplib as well, the body of the message which contains the
To: header, really isn't part of the SMTP dialog.  The
envelope sender and recipients are the important determining
factors in where the message goes and where the message
comes from.  These are the first two arguments to
.sendmail().  The body of the message -- including the
headers -- is spit right out to the SMTP server, after
canonicalizing stuff like line endings as per the RFC.

Much more likely is that your MTA -- i.e. the thing you're
connected to (your SMTP server) -- is munging things.

If you can explain more about your environment, I might be
able to help.  You should also attach a .py file that
exactly reproduces your problem and I will test it with my MTA.

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

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


From noreply@sourceforge.net  Mon Apr  1 06:35:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 31 Mar 2002 22:35:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-537615 ] LangRef for 2.2 talks like 2.1
Message-ID: <E16rvPr-0004XD-00@usw-sf-web4.sourceforge.net>

Bugs item #537615, was opened at 2002-04-01 03:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537615&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: LangRef for 2.2 talks like 2.1

Initial Comment:
There maybe other spots in the docs with the same
problem, but I noticed that Apendix A of the Language
Reference for Python 2.2 talks as if it was still about
Python 2.1

As of today (31st March 2002), the following urls
exemplify what I mean:
http://python.sourceforge.net/maint-docs/ref/futures.html
http://python.sourceforge.net/maint-docs/ref/nested-scopes.html

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

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


From noreply@sourceforge.net  Mon Apr  1 09:36:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 01:36:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16ryF3-0003Sc-00@usw-sf-web2.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-01 09:36

Message:
Logged In: YES 
user_id=6656

Assign to Guido.

Bearing in mind that I haven't even tried to understand this 
bug, the fact that you can't come up with a test case stands 
against you... if you're just asking where to put it, stick 
it in test_descr.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-31 23:17

Message:
Logged In: YES 
user_id=56214

Patch #537536 submitted to fix this.  "make test" output is
same as before the patch.  If someone can give me an idea of
where/how to insert a regression test for the bug being
fixed, I'll submit a patch for that, too.  Thanks.


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:19

Message:
Logged In: YES 
user_id=6656

Unless someone can come up with a obviously correct patch 
(and convince Guido that it's obviously correct) very soon, 
this isn't going to go into 2.2.1.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:38

Message:
Logged In: YES 
user_id=56214

Ugh.  I just realized that my "presumable fix" is actually
wrong.  I checked back on my "Python super" workaround, and
realized I modified Guido's example slightly, to call
__get__(self.__obj__,starttype), instead of
__get__(self.__obj__).  This implies that the fix to
super_getattro is a little more complicated, since
super_getattro doesn't have a C variable equivalent to
starttype in the Python version of super.  :(


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 12:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

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

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


From noreply@sourceforge.net  Mon Apr  1 09:37:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 01:37:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16ryFz-0003TR-00@usw-sf-web2.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-01 09:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 23:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 05:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 03:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 17:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 15:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 13:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 20:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 19:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 18:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 17:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 13:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-14 04:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 22:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 21:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Mon Apr  1 13:01:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 05:01:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16s1Re-0008Td-00@usw-sf-web4.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 08:01

Message:
Logged In: YES 
user_id=6380

Nah, just stick it in. Even if it doesn't work, it's
harmless.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 04:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 18:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 00:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-27 22:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 12:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 10:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 08:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 15:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 14:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 13:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 12:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 08:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 23:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 17:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 16:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Mon Apr  1 13:03:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 05:03:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16s1T5-0005iH-00@usw-sf-web2.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 13:03

Message:
Logged In: YES 
user_id=426262

It is difficult for me to test this because I am no longer 
using the same system, but I made a special journey this 
morning to test the bug fix.

Unfortunately, using the fix exposed what appears to be 
another error. Here is the traceback:

>>> webpage = urllib.urlopen('http://www.python.org').read()
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    webpage = urllib.urlopen('http://www.python.org').read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 166, in open
    name = 'open_' + urltype
TypeError: cannot concatenate 'str' and 'NoneType' objects

I have attempted to investigate this. The error occurred in 
the "open" function. On this system, the value of "urltype" 
is initially "http", and "proxy" is "//www-
cache.freeserve.com:8080". But then a split is performed on 
the "proxy" variable to split off the urltype, but the 
urltype has already been separated. Therefore, "urltype" is 
then assigned "None", causing the TypeError.

F.Y.I, self.proxies on this system is:
{'ftp', '//www-cache.freeserve.com:8080', 'http': '//www-
cache.freeserve.com:8080'}

I got it to work by removing the line:
urltype, proxyhost = splittype(proxy)

and changing the following line to:
host.selector = splithost(proxy)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 13:01

Message:
Logged In: YES 
user_id=6380

Nah, just stick it in. Even if it doesn't work, it's
harmless.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 09:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 23:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 05:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 03:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 17:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 15:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 13:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 20:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 19:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 18:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 17:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 13:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-14 04:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 22:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 21:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Mon Apr  1 13:07:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 05:07:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16s1WX-0005ku-00@usw-sf-web2.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 13:07

Message:
Logged In: YES 
user_id=426262

Sorry, the last line on that last post should read:
host, selector = splithost(proxy)


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 13:03

Message:
Logged In: YES 
user_id=426262

It is difficult for me to test this because I am no longer 
using the same system, but I made a special journey this 
morning to test the bug fix.

Unfortunately, using the fix exposed what appears to be 
another error. Here is the traceback:

>>> webpage = urllib.urlopen('http://www.python.org').read()
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    webpage = urllib.urlopen('http://www.python.org').read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 166, in open
    name = 'open_' + urltype
TypeError: cannot concatenate 'str' and 'NoneType' objects

I have attempted to investigate this. The error occurred in 
the "open" function. On this system, the value of "urltype" 
is initially "http", and "proxy" is "//www-
cache.freeserve.com:8080". But then a split is performed on 
the "proxy" variable to split off the urltype, but the 
urltype has already been separated. Therefore, "urltype" is 
then assigned "None", causing the TypeError.

F.Y.I, self.proxies on this system is:
{'ftp', '//www-cache.freeserve.com:8080', 'http': '//www-
cache.freeserve.com:8080'}

I got it to work by removing the line:
urltype, proxyhost = splittype(proxy)

and changing the following line to:
host.selector = splithost(proxy)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 13:01

Message:
Logged In: YES 
user_id=6380

Nah, just stick it in. Even if it doesn't work, it's
harmless.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 09:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 23:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 05:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 03:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 17:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 15:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 13:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 20:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 19:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 18:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 17:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 13:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-14 04:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 22:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 21:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Mon Apr  1 13:34:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 05:34:47 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16s1xP-0005s8-00@usw-sf-web1.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 08:34

Message:
Logged In: YES 
user_id=6380

Michael, obviously it's better to hold off. :-(

I apologize for the wasted trip, Jason. I think I know where
I messed up but it'll have to wait until after breakfast (my
family are calling me :-).

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 08:07

Message:
Logged In: YES 
user_id=426262

Sorry, the last line on that last post should read:
host, selector = splithost(proxy)


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 08:03

Message:
Logged In: YES 
user_id=426262

It is difficult for me to test this because I am no longer 
using the same system, but I made a special journey this 
morning to test the bug fix.

Unfortunately, using the fix exposed what appears to be 
another error. Here is the traceback:

>>> webpage = urllib.urlopen('http://www.python.org').read()
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    webpage = urllib.urlopen('http://www.python.org').read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 166, in open
    name = 'open_' + urltype
TypeError: cannot concatenate 'str' and 'NoneType' objects

I have attempted to investigate this. The error occurred in 
the "open" function. On this system, the value of "urltype" 
is initially "http", and "proxy" is "//www-
cache.freeserve.com:8080". But then a split is performed on 
the "proxy" variable to split off the urltype, but the 
urltype has already been separated. Therefore, "urltype" is 
then assigned "None", causing the TypeError.

F.Y.I, self.proxies on this system is:
{'ftp', '//www-cache.freeserve.com:8080', 'http': '//www-
cache.freeserve.com:8080'}

I got it to work by removing the line:
urltype, proxyhost = splittype(proxy)

and changing the following line to:
host.selector = splithost(proxy)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 08:01

Message:
Logged In: YES 
user_id=6380

Nah, just stick it in. Even if it doesn't work, it's
harmless.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 04:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 18:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 00:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-27 22:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 12:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 10:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 08:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 15:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 14:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 13:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 12:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 08:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 23:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 17:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 16:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Mon Apr  1 14:17:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 06:17:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-537450 ] Improper object initialization
Message-ID: <E16s2d9-0001CT-00@usw-sf-web3.sourceforge.net>

Bugs item #537450, was opened at 2002-03-31 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improper object initialization

Initial Comment:
The descr tutorial specifies this rule:

  __new__ must return an object. There's nothing that
  requires that it return a new object that is an 
  instance of its class argument, although that is the 
  convention. If you return an existing object, the 
  constructor call will still call its __init__ 
  method. If you return an object of a different 
  class, its __init__ method will be called. 

I believe that this rule adds an unnecessary wart to 
the language, since it is not appropriate to call 
__init__, especially with the same arguments as 
__new__ on an 'unexpected' class returned by __new__.
It is simple enough to check that the resulting class 
is an instance of the expected class and to only then 
call __init__.  Otherwise, it should be assumed that 
__new__ is returning a fully constructed instance of 
another class.  In the rare and obscure case that one 
does wish to call __init__ on an object of a different 
class, then it may be done manually from within 
__new__.

So basically, my argument is for explicit versus
implicit semantics.  If __new__(cls) returns an 
instance where type(instance) is not cls, then
__init__ should not be called implicitly.  The
burden should be on the programmer to explicitly
ensure that the object is properly constructed.

Here is an example where the current rule results
in confusing and apparently random behavior
(if one doesn't have initimate knowledge of the
Python implementation, that is):

class Foo(object):
  def __new__(cls, x):
    if x == 0:
      return [1,2,3]
    if x == 1:
      return 1
    if x == 2:
      return (1,2,3)
    if x == 3:
      return '1'
    if x == 4:
      return {1:1,2:2,3:3}
    else:
      return super(cls, Foo).__new__(cls)

for i in range(6):
  try:
    print 'Foo(%d) =' % i,Foo(i)
  except:
    print 'Foo(%d) failed' % i

Which under Python 2.2 results in the following output:
  Foo(0) failed
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) failed
  Foo(5) = <__main__.Foo object at 0x8147f54>

Under the proposed new rule, the output would be
much more sensible:
  Foo(0) = [1,2,3]
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) = {1:1,2:2,3:3}
  Foo(5) = <__main__.Foo object at 0x8147f54>

If there is agreement on this issue, I will submit
a very simple patch to address this.


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

>Comment By: Kevin Jacobs (jacobs99)
Date: 2002-04-01 09:17

Message:
Logged In: YES 
user_id=459565

Patch attached.  Passes Python descr tests and our 
extremely comprehensive in-house test suite that
tortures new-style classes in fairly gruesome ways.

Note: The ugly test to avoid calling tp_init on
      type(x) calls was intentionally left in the code, 
      to handle the case of calling type(type).
      It is very likely that the test is now unnecessary 
      and can be removed since calling tp_init on type
      objects should be safe, because they do not implement 
      their own tp_init.  However, for the sake of
      simplicity, I'm going to leave this additional 
      cleanup to Guido, or others.


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

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


From noreply@sourceforge.net  Mon Apr  1 14:43:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 06:43:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-537450 ] Improper object initialization
Message-ID: <E16s31l-0006iW-00@usw-sf-web1.sourceforge.net>

Bugs item #537450, was opened at 2002-03-31 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Improper object initialization

Initial Comment:
The descr tutorial specifies this rule:

  __new__ must return an object. There's nothing that
  requires that it return a new object that is an 
  instance of its class argument, although that is the 
  convention. If you return an existing object, the 
  constructor call will still call its __init__ 
  method. If you return an object of a different 
  class, its __init__ method will be called. 

I believe that this rule adds an unnecessary wart to 
the language, since it is not appropriate to call 
__init__, especially with the same arguments as 
__new__ on an 'unexpected' class returned by __new__.
It is simple enough to check that the resulting class 
is an instance of the expected class and to only then 
call __init__.  Otherwise, it should be assumed that 
__new__ is returning a fully constructed instance of 
another class.  In the rare and obscure case that one 
does wish to call __init__ on an object of a different 
class, then it may be done manually from within 
__new__.

So basically, my argument is for explicit versus
implicit semantics.  If __new__(cls) returns an 
instance where type(instance) is not cls, then
__init__ should not be called implicitly.  The
burden should be on the programmer to explicitly
ensure that the object is properly constructed.

Here is an example where the current rule results
in confusing and apparently random behavior
(if one doesn't have initimate knowledge of the
Python implementation, that is):

class Foo(object):
  def __new__(cls, x):
    if x == 0:
      return [1,2,3]
    if x == 1:
      return 1
    if x == 2:
      return (1,2,3)
    if x == 3:
      return '1'
    if x == 4:
      return {1:1,2:2,3:3}
    else:
      return super(cls, Foo).__new__(cls)

for i in range(6):
  try:
    print 'Foo(%d) =' % i,Foo(i)
  except:
    print 'Foo(%d) failed' % i

Which under Python 2.2 results in the following output:
  Foo(0) failed
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) failed
  Foo(5) = <__main__.Foo object at 0x8147f54>

Under the proposed new rule, the output would be
much more sensible:
  Foo(0) = [1,2,3]
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) = {1:1,2:2,3:3}
  Foo(5) = <__main__.Foo object at 0x8147f54>

If there is agreement on this issue, I will submit
a very simple patch to address this.


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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-01 09:43

Message:
Logged In: YES 
user_id=31435

Thanks, Kevin!  Assigned to Guido, under the theory that it 
lands on his plate sooner or later, and better sooner.

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

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-04-01 09:17

Message:
Logged In: YES 
user_id=459565

Patch attached.  Passes Python descr tests and our 
extremely comprehensive in-house test suite that
tortures new-style classes in fairly gruesome ways.

Note: The ugly test to avoid calling tp_init on
      type(x) calls was intentionally left in the code, 
      to handle the case of calling type(type).
      It is very likely that the test is now unnecessary 
      and can be removed since calling tp_init on type
      objects should be safe, because they do not implement 
      their own tp_init.  However, for the sake of
      simplicity, I'm going to leave this additional 
      cleanup to Guido, or others.


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

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


From noreply@sourceforge.net  Mon Apr  1 15:38:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 07:38:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y"
Message-ID: <E16s3ss-00027w-00@usw-sf-web3.sourceforge.net>

Bugs item #496922, was opened at 2001-12-26 18:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Integrate "What's new in Python x.y"

Initial Comment:
We should find a way to integrate Andrew Kuchling's
"What's new in Python X.Y?" documents with the
corresponding Python documentation to make it easier to
locate for users.

This could be done either by incorporating the document
into the standard documentation package (preferred for
off-line users) or by adding a link to the online
version of the document.

This should be done in time for Python 2.3.

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

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-04-01 10:38

Message:
Logged In: YES 
user_id=11375

SourceForge has carried out my support request, so if you do 
an update in Docs/whatsnew, you'll pick up 
whatsnew{20,21,22}.tex.  Reassigning to Fred.  

I'll add a note to whatsnew-22 about 2.2.1.

Is it worth doing the same integration for 2.0 and 2.1?


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:11

Message:
Logged In: YES 
user_id=6656

Sheesh, this is the third time I've attempted to follow up to 
this report.

Yes, 2.2.1 will be released on or about the ninth of April.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 14:15

Message:
Logged In: YES 
user_id=3066

If it can be done by sometime next weekend, that should be
good enough for me.  I think we're shooting for the
following Tuesday for the release, so I'll probably be
finishing the formatting on Monday.

Michael Hudson should correct me if I'm wrong on the
schedule.  ;-)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-31 13:32

Message:
Logged In: YES 
user_id=11375

I've already filed a request to add my CVS files to the
repository. 
http://sourceforge.net/tracker/?func=detail&aid=535390&group_id=1&atid=200001

When is 2.2.1 supposed to be wrapped for final release?  Do
I have another week?


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 01:30

Message:
Logged In: YES 
user_id=3066

Andrew, can you add the 2.2 document as
Doc/whatsnew/whatsnew22.tex?  Once this is done, re-assign
to me to complete the integration steps.

Thanks!

Raised priority since Guido wants this in 2.2.1, and its
coming up soon.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 10:18

Message:
Logged In: YES 
user_id=6380

Could you do this for 2.2.1 too?


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

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


From noreply@sourceforge.net  Mon Apr  1 16:13:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 08:13:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-496922 ] Integrate "What's new in Python x.y"
Message-ID: <E16s4RS-0007ty-00@usw-sf-web2.sourceforge.net>

Bugs item #496922, was opened at 2001-12-26 18:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=496922&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Integrate "What's new in Python x.y"

Initial Comment:
We should find a way to integrate Andrew Kuchling's
"What's new in Python X.Y?" documents with the
corresponding Python documentation to make it easier to
locate for users.

This could be done either by incorporating the document
into the standard documentation package (preferred for
off-line users) or by adding a link to the online
version of the document.

This should be done in time for Python 2.3.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-01 11:13

Message:
Logged In: YES 
user_id=3066

Integration complete for 2.2 maintenance releases.

There's no need to integrate older releases unless we're
still expecting anyone to upgrade to them from something
even older.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2002-04-01 10:38

Message:
Logged In: YES 
user_id=11375

SourceForge has carried out my support request, so if you do 
an update in Docs/whatsnew, you'll pick up 
whatsnew{20,21,22}.tex.  Reassigning to Fred.  

I'll add a note to whatsnew-22 about 2.2.1.

Is it worth doing the same integration for 2.0 and 2.1?


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:11

Message:
Logged In: YES 
user_id=6656

Sheesh, this is the third time I've attempted to follow up to 
this report.

Yes, 2.2.1 will be released on or about the ninth of April.


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 14:15

Message:
Logged In: YES 
user_id=3066

If it can be done by sometime next weekend, that should be
good enough for me.  I think we're shooting for the
following Tuesday for the release, so I'll probably be
finishing the formatting on Monday.

Michael Hudson should correct me if I'm wrong on the
schedule.  ;-)

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

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-31 13:32

Message:
Logged In: YES 
user_id=11375

I've already filed a request to add my CVS files to the
repository. 
http://sourceforge.net/tracker/?func=detail&aid=535390&group_id=1&atid=200001

When is 2.2.1 supposed to be wrapped for final release?  Do
I have another week?


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-31 01:30

Message:
Logged In: YES 
user_id=3066

Andrew, can you add the 2.2 document as
Doc/whatsnew/whatsnew22.tex?  Once this is done, re-assign
to me to complete the integration steps.

Thanks!

Raised priority since Guido wants this in 2.2.1, and its
coming up soon.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 10:18

Message:
Logged In: YES 
user_id=6380

Could you do this for 2.2.1 too?


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

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


From noreply@sourceforge.net  Mon Apr  1 17:46:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 09:46:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-537615 ] LangRef for 2.2 talks like 2.1
Message-ID: <E16s5tI-0003Mr-00@usw-sf-web4.sourceforge.net>

Bugs item #537615, was opened at 2002-04-01 06:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537615&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Leonardo Rochael Almeida (rochael)
>Assigned to: Jeremy Hylton (jhylton)
Summary: LangRef for 2.2 talks like 2.1

Initial Comment:
There maybe other spots in the docs with the same
problem, but I noticed that Apendix A of the Language
Reference for Python 2.2 talks as if it was still about
Python 2.1

As of today (31st March 2002), the following urls
exemplify what I mean:
http://python.sourceforge.net/maint-docs/ref/futures.html
http://python.sourceforge.net/maint-docs/ref/nested-scopes.html

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

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


From noreply@sourceforge.net  Mon Apr  1 17:49:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 09:49:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-536449 ] pydoc getopt fails
Message-ID: <E16s5vZ-0003OM-00@usw-sf-web4.sourceforge.net>

Bugs item #536449, was opened at 2002-03-28 20:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536449&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
>Assigned to: Jeremy Hylton (jhylton)
Summary: pydoc getopt fails

Initial Comment:
slothrop:~> pydoc getopt
Traceback (most recent call last):
  File "/usr/local/bin/pydoc", line 4, in ?
    pydoc.cli()
  File "/usr/local/lib/python2.3/pydoc.py", line 2077,
in cli
    doc(arg)
  File "/usr/local/lib/python2.3/pydoc.py", line 1341,
in doc
    pager(title % (desc + suffix) + '\n\n' +
text.document(thing, name))
  File "/usr/local/lib/python2.3/pydoc.py", line 267,
in document
    if inspect.ismodule(object): return
apply(self.docmodule, args)
  File "/usr/local/lib/python2.3/pydoc.py", line 961,
in docmodule
    contents.append(self.document(value, key, name))
  File "/usr/local/lib/python2.3/pydoc.py", line 268,
in document
    if inspect.isclass(object): return
apply(self.docclass, args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1093,
in docclass
    lambda t: t[1] == 'method')
  File "/usr/local/lib/python2.3/pydoc.py", line 1035,
in spill
    name, mod, object))
  File "/usr/local/lib/python2.3/pydoc.py", line 269,
in document
    if inspect.isroutine(object): return
apply(self.docroutine, args)
  File "/usr/local/lib/python2.3/pydoc.py", line 1154,
in docroutine
    doc = getdoc(object) or ''
  File "/usr/local/lib/python2.3/pydoc.py", line 66, in
getdoc
    result = inspect.getdoc(object) or
inspect.getcomments(object)
  File "/usr/local/lib/python2.3/inspect.py", line 420,
in getcomments
    try: lines, lnum = findsource(object)
  File "/usr/local/lib/python2.3/inspect.py", line 384,
in findsource
    file = getsourcefile(object) or getfile(object)
  File "/usr/local/lib/python2.3/inspect.py", line 329,
in getsourcefile
    filename = getfile(object)
  File "/usr/local/lib/python2.3/inspect.py", line 309,
in getfile
    raise TypeError, 'arg is not a module, class,
method, ' \
TypeError: arg is not a module, class, method,
function, traceback, frame, or code object


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-01 17:49

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.31 of inspect.py by catching TypeError in 
getcomments().  Good enough, I guess.


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

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


From noreply@sourceforge.net  Mon Apr  1 19:46:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 11:46:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16s7lG-0002Dq-00@usw-sf-web2.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Guido van Rossum (gvanrossum)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



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

>Comment By: Phillip J. Eby (pje)
Date: 2002-04-01 19:46

Message:
Logged In: YES 
user_id=56214

I was indeed just asking where to put it, and how to
*insert* the test.  Anyway, I found that most of what was
needed for the test was already in
test_descr.classmethods(), there were just a few conditions
using super() that needed adding.  I've uploaded the patch
for test_descr to the patch #537536 for this bug.

By the way, the bug/patch submission guidelines were a
little unclear to me; specifically whether I was supposed to
put the patch with the bug or the bug with the patch or
upload everything to both or what.  Hope my ignorance hasn't
inconvenienced anyone; this is my first time submitting
Python bugs and fixes.  Also, I hadn't worked with the test
framework used in Python's test suite before, although I've
done quite a bit with unittest in my own code.


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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 09:36

Message:
Logged In: YES 
user_id=6656

Assign to Guido.

Bearing in mind that I haven't even tried to understand this 
bug, the fact that you can't come up with a test case stands 
against you... if you're just asking where to put it, stick 
it in test_descr.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-31 23:17

Message:
Logged In: YES 
user_id=56214

Patch #537536 submitted to fix this.  "make test" output is
same as before the patch.  If someone can give me an idea of
where/how to insert a regression test for the bug being
fixed, I'll submit a patch for that, too.  Thanks.


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:19

Message:
Logged In: YES 
user_id=6656

Unless someone can come up with a obviously correct patch 
(and convince Guido that it's obviously correct) very soon, 
this isn't going to go into 2.2.1.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:38

Message:
Logged In: YES 
user_id=56214

Ugh.  I just realized that my "presumable fix" is actually
wrong.  I checked back on my "Python super" workaround, and
realized I modified Guido's example slightly, to call
__get__(self.__obj__,starttype), instead of
__get__(self.__obj__).  This implies that the fix to
super_getattro is a little more complicated, since
super_getattro doesn't have a C variable equivalent to
starttype in the Python version of super.  :(


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 12:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

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

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


From noreply@sourceforge.net  Mon Apr  1 20:05:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 12:05:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-537998 ] windows getpass broken on python 2.2
Message-ID: <E16s838-00024H-00@usw-sf-web1.sourceforge.net>

Bugs item #537998, was opened at 2002-04-01 15:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537998&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Tim Peters (tim_one)
Summary: windows getpass broken on python 2.2

Initial Comment:
Windows 2000 Python 2.2

>>> import getpass
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)
>>> getpass.getpass()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python22\lib\getpass.py", line 29, in
unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
AttributeError: 'module' object has no attribute
'tcgetattr'
>>>

I think the problem is that TERMIOS.py and termios.py
are the same thing on windows which causes a strange
Deprecation warning.  Python 2.1 used to fail on import
of termios

C:\Documents and Settings\bkelley\My
Documents\Downloads\Webware>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import termios
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)

anyway, TERMIOS.py should probably not be installed on
windows.  This should be removed from 2.2.1c2
Brian


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

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


From noreply@sourceforge.net  Mon Apr  1 20:45:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 12:45:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-537998 ] windows getpass broken on python 2.2
Message-ID: <E16s8g5-0002Yl-00@usw-sf-web1.sourceforge.net>

Bugs item #537998, was opened at 2002-04-01 20:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537998&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Brian Kelley (wc2so1)
Assigned to: Tim Peters (tim_one)
Summary: windows getpass broken on python 2.2

Initial Comment:
Windows 2000 Python 2.2

>>> import getpass
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)
>>> getpass.getpass()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python22\lib\getpass.py", line 29, in
unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
AttributeError: 'module' object has no attribute
'tcgetattr'
>>>

I think the problem is that TERMIOS.py and termios.py
are the same thing on windows which causes a strange
Deprecation warning.  Python 2.1 used to fail on import
of termios

C:\Documents and Settings\bkelley\My
Documents\Downloads\Webware>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import termios
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)

anyway, TERMIOS.py should probably not be installed on
windows.  This should be removed from 2.2.1c2
Brian


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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-01 20:45

Message:
Logged In: YES 
user_id=6656

Oops.  That sucks.

Tim, this must be case confusion of some kind.  termios.py 
has never existed, however there's now a placeholder Lib/
TERMIOS.py, deprecated in favour of using the termios 
(lowercase) module.  Is Brian's suggestion of just not 
installing TERMIOS.py feasible?

Brian: thanks!


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

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


From noreply@sourceforge.net  Mon Apr  1 20:50:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 12:50:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16s8kr-0002cO-00@usw-sf-web1.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 22:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Guido van Rossum (gvanrossum)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-01 20:50

Message:
Logged In: YES 
user_id=6656

OK, you've found the right place, good.

The bug/patch guidlines are probably confusing because, 
unless you're part of the Python project I think you can't 
attach a file to a report you didn't submit.  Generally I 
prefer patches to be attached to bugs, but that's just my 
opinion, I don't know what other developers think.  I also 
think the whole bug/patch division is misguided, but that's 
another rant entirely.

I think you're doing fine!  Now we just wait for Guido to 
stop changing nappies :)


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

Comment By: Phillip J. Eby (pje)
Date: 2002-04-01 19:46

Message:
Logged In: YES 
user_id=56214

I was indeed just asking where to put it, and how to
*insert* the test.  Anyway, I found that most of what was
needed for the test was already in
test_descr.classmethods(), there were just a few conditions
using super() that needed adding.  I've uploaded the patch
for test_descr to the patch #537536 for this bug.

By the way, the bug/patch submission guidelines were a
little unclear to me; specifically whether I was supposed to
put the patch with the bug or the bug with the patch or
upload everything to both or what.  Hope my ignorance hasn't
inconvenienced anyone; this is my first time submitting
Python bugs and fixes.  Also, I hadn't worked with the test
framework used in Python's test suite before, although I've
done quite a bit with unittest in my own code.


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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 09:36

Message:
Logged In: YES 
user_id=6656

Assign to Guido.

Bearing in mind that I haven't even tried to understand this 
bug, the fact that you can't come up with a test case stands 
against you... if you're just asking where to put it, stick 
it in test_descr.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-31 23:17

Message:
Logged In: YES 
user_id=56214

Patch #537536 submitted to fix this.  "make test" output is
same as before the patch.  If someone can give me an idea of
where/how to insert a regression test for the bug being
fixed, I'll submit a patch for that, too.  Thanks.


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 20:19

Message:
Logged In: YES 
user_id=6656

Unless someone can come up with a obviously correct patch 
(and convince Guido that it's obviously correct) very soon, 
this isn't going to go into 2.2.1.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:38

Message:
Logged In: YES 
user_id=56214

Ugh.  I just realized that my "presumable fix" is actually
wrong.  I checked back on my "Python super" workaround, and
realized I modified Guido's example slightly, to call
__get__(self.__obj__,starttype), instead of
__get__(self.__obj__).  This implies that the fix to
super_getattro is a little more complicated, since
super_getattro doesn't have a C variable equivalent to
starttype in the Python version of super.  :(


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 13:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 12:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

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

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


From noreply@sourceforge.net  Mon Apr  1 21:09:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 13:09:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-537998 ] windows getpass broken on python 2.2
Message-ID: <E16s93I-0003D2-00@usw-sf-web2.sourceforge.net>

Bugs item #537998, was opened at 2002-04-01 15:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537998&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Brian Kelley (wc2so1)
Assigned to: Tim Peters (tim_one)
Summary: windows getpass broken on python 2.2

Initial Comment:
Windows 2000 Python 2.2

>>> import getpass
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)
>>> getpass.getpass()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python22\lib\getpass.py", line 29, in
unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
AttributeError: 'module' object has no attribute
'tcgetattr'
>>>

I think the problem is that TERMIOS.py and termios.py
are the same thing on windows which causes a strange
Deprecation warning.  Python 2.1 used to fail on import
of termios

C:\Documents and Settings\bkelley\My
Documents\Downloads\Webware>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import termios
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)

anyway, TERMIOS.py should probably not be installed on
windows.  This should be removed from 2.2.1c2
Brian


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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-01 16:09

Message:
Logged In: YES 
user_id=31435

getpass() works fine on Windows:

C:\Python22>python
Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import getpass
>>> getpass.getpass()
Password:
'abc'
>>>

I suspect Brian has set the PYTHONCASEOK envar on Windows, 
in which case any number of insane things can happen (it 
tells Python to ignore case mismatches then).  Brian?

Not shipping TERMIOS.py isn't an option.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 15:45

Message:
Logged In: YES 
user_id=6656

Oops.  That sucks.

Tim, this must be case confusion of some kind.  termios.py 
has never existed, however there's now a placeholder Lib/
TERMIOS.py, deprecated in favour of using the termios 
(lowercase) module.  Is Brian's suggestion of just not 
installing TERMIOS.py feasible?

Brian: thanks!


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

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


From noreply@sourceforge.net  Mon Apr  1 21:35:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 13:35:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-537615 ] LangRef for 2.2 talks like 2.1
Message-ID: <E16s9Sr-00039B-00@usw-sf-web1.sourceforge.net>

Bugs item #537615, was opened at 2002-04-01 06:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537615&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Leonardo Rochael Almeida (rochael)
Assigned to: Jeremy Hylton (jhylton)
Summary: LangRef for 2.2 talks like 2.1

Initial Comment:
There maybe other spots in the docs with the same
problem, but I noticed that Apendix A of the Language
Reference for Python 2.2 talks as if it was still about
Python 2.1

As of today (31st March 2002), the following urls
exemplify what I mean:
http://python.sourceforge.net/maint-docs/ref/futures.html
http://python.sourceforge.net/maint-docs/ref/nested-scopes.html

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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-01 21:35

Message:
Logged In: YES 
user_id=31392

The documentation has been updated for Python 2.3.  I 
haven't back-ported changes to the 2.2 maintenance branch, 
but it should be mostly mechanical to do so.  (The 
beginning of section A.1 must be changed because generates 
aren't a standard feature in 2.2.)


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

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


From noreply@sourceforge.net  Mon Apr  1 21:54:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 13:54:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-407783 ] urllib2: AbstractHTTPHandler limits flexible client implemen
Message-ID: <E16s9kb-0003lb-00@usw-sf-web2.sourceforge.net>

Bugs item #407783, was opened at 2001-03-12 00:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=407783&group_id=5470

Category: Python Library
Group: None
>Status: Closed
Resolution: Postponed
Priority: 4
Submitted By: Bill Bumgarner (bbum)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2: AbstractHTTPHandler limits flexible client implemen

Initial Comment:
The implementation of the do_open() method on the AbstractHTTPHandler class contains a couple of "features" that could be considered to be "bugs".  In any case, each time I have wanted to use urllib2 for relatively straightforward development of an HTTP client, I have had to effectively replace the HTTPHandler with one that reimplements do_open() (or http_open() in 2.0).  Maybe my usage is not the norm-- in any case, the more information, the better...

Specifics (all names in context of Python 2.1):

- AbstractHTTPHandler does not allow for anything but GET or POST requests.   GET is the default and POST happens anytime the request object contains data to be passed to the server.

This limitation is the only thing that stands in the way of using the AbstractHTTPHandler *directly* to implement, say, a WebDAV client or to do something like a site sucker that uses the HEAD method to determine if content has changed.

- [this is likely a bug]  the method will throw an exception if *any* response is received from the server other than 200.   However, HTTP defines that all 2XX responses should be treated as successful. 

In any case, there are *a lot* of contexts within which a non-200 response may be treated as a 'success' of some sort or another.  Regardless, it is really outside of the scope of the AbstractHTTPHandler's implementation to make the success/failure decision-- it should simply return  the same thing regardless of the response status.

- [a bug?] Whenever an exception is raised (a non-200 code is received), the status code and reason (as provided by the server) are both lost. 

I see that moshez has been primarily responsible for recent changes surrounding this code.  I would be happy to contribute to the evolution of the code;  please feel free to contact me directly.


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

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-01 21:54

Message:
Logged In: YES 
user_id=31392

I still think this is a useful feature, but I don't have 
time to champion it.  Since the original poster hasn't 
followed up in the last year, I'll just close the report.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-09 18:06

Message:
Logged In: YES 
user_id=31392

It's only six or seven months since there was an active
discussion on this bug report.  Anyone still interested in
fixing it?  I think it's reasonable to try and fix these
issues for 2.2, but I don't have time to implement it all
myself.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 18:07

Message:
Logged In: YES 
user_id=6380

Unassigning from Moshe -- he doesn't seem to have time
(Moshe, if you're still interested, just change the owner
field back to you).

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

Comment By: Moshe Zadka (moshez)
Date: 2001-04-09 14:02

Message:
Logged In: YES 
user_id=11645

I'm formally postponing it until the 2.1 release comes out
-- clearly none of this can be considered a bug fix.

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

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-20 00:37

Message:
Logged In: YES 
user_id=103811

OK-- I can understand that logic (close to beta, etc).

Given the prominence of Python in the WebDav 
community combined with the increasing use of 2xx 
(and 1xx) codes, it would be extremely useful to 
include-- at the least-- examples of handling such via 
the urllib2 modules.   

Beyond that, it would be quite helpful to the developers 
to expend some amount of engineering effort such that 
handling 2xx response codes doesn't require 
__getattr__ trickery! 

Similarly, breaking out the HTTP raw connection setup 
from the method that actually composes and sends the 
HTTP request would be helpful in that it would greatly 
reduce the amount of code that has to be duplicated 
when subclassing the handler to customize handling of 
2xx or when specifying methods other than GET/POST.

I.e. most developers will be confused to the point of 
being overwhelmed if "how do I customize responses 
such that they don't raise" or "how do I send an 
OPTIONS or HEAD request" requires figuring out how 
to deal with setting up and sending a request via the 
much-lower-level-than-urllib2 HTTP API.


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

Comment By: Moshe Zadka (moshez)
Date: 2001-03-18 09:22

Message:
Logged In: YES 
user_id=11645

None of these can really be classified as "bugs" rather then
functionality enhancement requests, and this is something
I'm not sure I want to do this close to the second beta.

BTW, one thing I'm sure I *don't* want to change -- handling
of 20x codes. If you want to handle 201/206/whatever, then
just handle them. With some __getattr__ trickery, you can
have a class that handles all http_error_20x errors, so this
is *easy* for 3rd party urllib2 extensions to add.

Regarding explicitly determining the command: just put the
command inside the request object, and use it in your
own HTTPHandler/HTTPSHandler. This may be done in the next
version of urllib2 (for 2.2). At that time I might also add
the feature that other encodings (not just
application/x-www-form-urlencoded, but also
multipart/form-data) will be supported.



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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-03-16 18:43

Message:
Logged In: YES 
user_id=31392

I haven't had any spare cycles to devote to urllib2 this
year.  Perhaps Moshe can be of more help in the near term. 
Following the 2.1 release, I may have more time.

I never used urllib2 it a situation that produced anything
other than vanilla responses -- 200, 401, etc.  I'm not to
surprised to hear that there are problems with 2XX cases.

Can you post some examples of the sorts of things you want
to do?  It sounds reasonable in the abstract, but some code
would help.  If not in this patch archive, perhaps on
comp.lang.python?


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

Comment By: Bill Bumgarner (bbum)
Date: 2001-03-12 03:59

Message:
Logged In: YES 
user_id=103811

I realized that the exception throw behaviour is more fundamental to the underlying implementation than may have been indicated in the above description.  In particular, throwing an HTTP exception when handling a 401 is key to making the various Authentication Handlers work.

I still feel that the behaviour should be normalized across all requests such that the callee is responsible for determining error conditions or, at the lest, has access to the same data in a relatively similar format upon success or failure.


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

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


From noreply@sourceforge.net  Mon Apr  1 23:05:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 15:05:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-518767 ] array module has undocumented features
Message-ID: <E16sAru-0004Zn-00@usw-sf-web2.sourceforge.net>

Bugs item #518767, was opened at 2002-02-17 10:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518767&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: array module has undocumented features

Initial Comment:
It turns out arrays support list slice operations and
string operations:

p = array('B','potato')
p[2:2]=array('B','banana')  # works!  insert banana
re.search('ta',p).span()    # also works!

I wouldn't have guessed from the docs for the array
module that the slice and regexp operations were
supported.  If they're "officially" supposed to work,
the doc should be say so.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-01 18:05

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libarray.tex revision 1.31.8.1, clarified
in 1.33.

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

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


From noreply@sourceforge.net  Mon Apr  1 23:06:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 15:06:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-536469 ] module array:  C type descriptions wrong
Message-ID: <E16sAsI-0004DF-00@usw-sf-web1.sourceforge.net>

Bugs item #536469, was opened at 2002-03-28 15:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536469&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Histed (histed)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: module array:  C type descriptions wrong

Initial Comment:
The C types corresponding to the 'array' type codes
seem to be documented incorrectly.

See:
http://www.python.org/doc/current/lib/module-array.html

All C integer types are listed as 'int' or 'unsigned
int'.  I'm guessing from the sizes and the C standard
that these should be 'char', 'short', 'int', and 'long'.

This agrees with what the Python Essential reference
has to say (Beazley, p127)



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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-01 18:06

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libarray.tex revisions 1.31.8.1 and 1.33.

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

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


From noreply@sourceforge.net  Mon Apr  1 23:14:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 15:14:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-537511 ] ref to non-existant PyArg_ConvertTuple
Message-ID: <E16sB0m-0004If-00@usw-sf-web1.sourceforge.net>

Bugs item #537511, was opened at 2002-03-31 16:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537511&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ref to non-existant PyArg_ConvertTuple

Initial Comment:
In Doc/ext/extending.tex, there is a reference to
PyArg_ConvertTuple which does not exist.  I'm not sure
what this is referring to, otherwise I would fix it. 
Perhaps, PyArgUnpackTuple is meant?  If someone can
provide quick guidance, I can fix it.

Here's the text:

status = converter(object, address);

where \var{object} is the Python object to be converted
and \var{address} is the \ctype{void *} argument that
was passed to \cfunction{PyArg_ConvertTuple()}.

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-01 18:14

Message:
Logged In: YES 
user_id=3066

That was supposed to be PyArg_ParseTuple().
Fixed in Doc/ext/extending.tex revisions 1.16 and 1.11.6.1,
and in Doc/ext/ext.tex revision 1.95.2.3.

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

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


From noreply@sourceforge.net  Mon Apr  1 23:30:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 15:30:59 -0800
Subject: [Python-bugs-list] [ python-Bugs-537582 ] incorrect pid returned from os.spawn
Message-ID: <E16sBGN-0004TN-00@usw-sf-web1.sourceforge.net>

Bugs item #537582, was opened at 2002-03-31 21:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537582&group_id=5470

Category: Documentation
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: alastair nicol (ajnicol)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: incorrect pid returned from os.spawn

Initial Comment:
The pid returned from the os.spawnv and os.spawnl method
is incorrect.

This can be easily demostrated by swawning a python
prog containing "time.sleep(100000)". The pid returned
by spawn isnt the same as the pid as reported by task
manager. 

I have only tried this with os.spawnl and os.spawnv

For example:-
spawnv reported pid=92
windows reported pid=1484

Software:
Python 2.2 (downloaded .exe from python.org)
Windows 2000 Pro

Al

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-01 18:30

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libos.tex revisions 1.74.2.1.2.1 and 1.78.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-31 22:17

Message:
Logged In: YES 
user_id=31435

There's nothing wrong with what the spawn functions return 
on Windows -- indeed, they return exactly what the 
Microsoft spawn functions return.

The problem is that, on Windows, processes have 
both "process handles" and "process ids", they're both 
integers, and Microsoft's own docs confuse the two 
routinely.  "process handle" is the better name for what 
spawn returns on Windows.  You wouldn't want it to return 
the process id:  almost all Win32 API functions require a 
process handle.

Reassigned to Fred and changed category to Docs:  Fred, can 
you fiddle things to explain that the spawn family really 
returns what Windows calls a "process handle"?  Ditto that 
os.waitpid() in 2.3 on Windows takes a process handle as 
argument?

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

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


From noreply@sourceforge.net  Mon Apr  1 23:57:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 15:57:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-460613 ] test_commands fails on SGI
Message-ID: <E16sBfx-0007uA-00@usw-sf-web3.sourceforge.net>

Bugs item #460613, was opened at 2001-09-11 04:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460613&group_id=5470

>Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sjoerd Mullender (sjoerd)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: test_commands fails on SGI

Initial Comment:
test_commands fails on SGI.
The problem is that the test expects /bin/ls to be a
file, whereas on IRIX it's a symbolic link.

For completeness, here is the output of running the
test:
+ ./python ../Lib/test/regrtest.py test_commands.py
test_commands
test test_commands failed -- Traceback (most recent
call last):
  File "../Lib/test/test_commands.py", line 43, in
test_getstatus
    self.assert_(re.match(pat, getstatus("/bin/ls"),
re.VERBOSE))
  File
"/ufs/sjoerd/src/Python/dist/src/Lib/unittest.py", line
256, in failUnless
    if not expr: raise self.failureException, msg
AssertionError

1 test failed:
    test_commands


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-01 18:57

Message:
Logged In: YES 
user_id=3066

Removed dependency on system configuration in
Lib/test/test_commands.py revision 1.4, using patch provided
in bug #497160.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 09:57

Message:
Logged In: YES 
user_id=6380

Related to [ #497160 ] test_commands assumes ls is in /bin.

Assigned to Fred Drake, who wrote the test suite.

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

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


From noreply@sourceforge.net  Mon Apr  1 23:58:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 15:58:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-497160 ] test_commands assumes ls is in /bin
Message-ID: <E16sBgW-0007gZ-00@usw-sf-web4.sourceforge.net>

Bugs item #497160, was opened at 2001-12-27 16:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497160&group_id=5470

Category: Build
Group: Python 2.2
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: test_commands assumes ls is in /bin

Initial Comment:
I got this test failure while building Python 2.2:
test test_commands failed -- Traceback (most recent
call last):
  File "./Lib/test/test_commands.py", line 43, in
test_getstatus
    self.assert_(re.match(pat, getstatus("/bin/ls"),
re.VERBOSE))
  File
"/fs/home/mount/home/prj/b/Python-2.2/Lib/unittest.py",
line 262, in failUnless
    if not expr: raise self.failureException, msg
AssertionError

My ls happens to be somewhere other than /bin.  It would
be nice if the test used a different file, such as "/",
".", or even "./Lib/test/test_commands.py".

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-01 18:58

Message:
Logged In: YES 
user_id=3066

Checked in patch as provided in Lib/test/test_commands.py
revision 1.4; closed bug #460613 as well.

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-27 15:36

Message:
Logged In: YES 
user_id=6656

No attempt was made to fix this for 2.2.1c2.

I didn't make fixing little bugs in the tests a priority, 
sorry.

I don't think it's been fixed on the trunk.

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

Comment By: Paul Jarc (prjsf)
Date: 2002-03-26 16:50

Message:
Logged In: YES 
user_id=412110

This problem still exists in 2.2.1c2.  Is there something wrong
with my patch?

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

Comment By: Paul Jarc (prjsf)
Date: 2001-12-31 02:12

Message:
Logged In: YES 
user_id=412110

Sorry, I should have thought of providing a patch to begin
with.
<URL:http://multivac.cwru.edu./prj/python-test-commands.patch>
This regexp test is weaker than the original one, but seems to 
be still stronger than necessary.  If ls is broken here, we
don't care, because it isn't part of Python.  All wee need is
to be able to spawn a shell.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 09:55

Message:
Logged In: YES 
user_id=6380

Assigned to Fred Drake, who wrote the test suite.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 09:54

Message:
Logged In: YES 
user_id=6380

OK, reopening.

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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2001-12-29 06:55

Message:
Logged In: YES 
user_id=43607

This bug report is related to [ #460613 ] test_commands fails on SGI, which nobody ever seems to have noticed 
and which is still open.
The problem there is that /bin/ls *does* exist, but is a symlink.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 17:42

Message:
Logged In: YES 
user_id=6380

If the patch is so simple, why don't you provide it?

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

Comment By: Paul Jarc (prjsf)
Date: 2001-12-28 17:20

Message:
Logged In: YES 
user_id=412110

The test suite already uses $PATH to *run* ls (as does other
software, which is why I don't get into a lot of trouble).
It merely uses /bin/ls as a filename to pass to ls so it can
check the output.  Any other filename will do just as well
here, and the fix is extremely simple; what's the benefit of
listing /bin/ls in particular that makes it worth risk
breaking on systems like this?

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 16:56

Message:
Logged In: YES 
user_id=6380

I think you are going to get in a lot of trouble when
/bin/ls doesn't exist. It's not worth fixing the test suite
for this.

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

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


From noreply@sourceforge.net  Tue Apr  2 03:24:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 19:24:43 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16sEuZ-0001dL-00@usw-sf-web3.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 22:24

Message:
Logged In: YES 
user_id=6380

The code I added to getproxies_registry() was wrong.

Can you try this instead? Manually patch the urllib.py to
replace the two lines

    type, address = splittype(address)
    if not type:

with these (indented the same):

    import re
    if not re.match('^([^/:]+)://', address):

This will ensure that the proxies dict looks like it should,
e.g. in your case it would be

{'ftp', 'http://www-cache.freeserve.com:8080',
 'http': 'http://www-cache.freeserve.com:8080'}

I'll see if I can test this myself when I have access to a
working Windows machine tomorrow.

Michael: when I check that it, you'll know it's good for
2.2.1. :-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 08:34

Message:
Logged In: YES 
user_id=6380

Michael, obviously it's better to hold off. :-(

I apologize for the wasted trip, Jason. I think I know where
I messed up but it'll have to wait until after breakfast (my
family are calling me :-).

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 08:07

Message:
Logged In: YES 
user_id=426262

Sorry, the last line on that last post should read:
host, selector = splithost(proxy)


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 08:03

Message:
Logged In: YES 
user_id=426262

It is difficult for me to test this because I am no longer 
using the same system, but I made a special journey this 
morning to test the bug fix.

Unfortunately, using the fix exposed what appears to be 
another error. Here is the traceback:

>>> webpage = urllib.urlopen('http://www.python.org').read()
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    webpage = urllib.urlopen('http://www.python.org').read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 166, in open
    name = 'open_' + urltype
TypeError: cannot concatenate 'str' and 'NoneType' objects

I have attempted to investigate this. The error occurred in 
the "open" function. On this system, the value of "urltype" 
is initially "http", and "proxy" is "//www-
cache.freeserve.com:8080". But then a split is performed on 
the "proxy" variable to split off the urltype, but the 
urltype has already been separated. Therefore, "urltype" is 
then assigned "None", causing the TypeError.

F.Y.I, self.proxies on this system is:
{'ftp', '//www-cache.freeserve.com:8080', 'http': '//www-
cache.freeserve.com:8080'}

I got it to work by removing the line:
urltype, proxyhost = splittype(proxy)

and changing the following line to:
host.selector = splithost(proxy)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 08:01

Message:
Logged In: YES 
user_id=6380

Nah, just stick it in. Even if it doesn't work, it's
harmless.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 04:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 18:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 00:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-27 22:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 12:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 10:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 08:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 15:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 14:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 13:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 12:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 08:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 23:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 17:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 16:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Tue Apr  2 05:08:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 21:08:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-505152 ] pprint should (optionally) use str
Message-ID: <E16sGXI-0002gc-00@usw-sf-web3.sourceforge.net>

Bugs item #505152, was opened at 2002-01-17 18:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505152&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pprint should (optionally) use str

Initial Comment:
pprint.pprint() uses repr to display an object. 
However I think it's at least as likely that pretty
printing would be used as a human debugging tool rather
than for generating a string "which can be used as
input to the interpreter".

pprint.pprint() -- and PrettyPrinter.pprint() should
optionally use str() to print a human readable
representation of the object.


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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-02 00:08

Message:
Logged In: YES 
user_id=3066

The usefulness of str() seems questionable; if the issue is
debugging, repr()-like presentation seems to make more
sense.  I do think the pretty-printer should be configurable
(via subclassing at least).

I've checked in an attempt to make it easier to change the
machinery use, but I'm not sure this is really the right change.

I'm closing the bug report as vague, but am interested in
suggestions for improving the pprint module.

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

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


From noreply@sourceforge.net  Tue Apr  2 05:15:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 01 Apr 2002 21:15:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-505152 ] pprint should (optionally) use str
Message-ID: <E16sGe1-00081r-00@usw-sf-web1.sourceforge.net>

Bugs item #505152, was opened at 2002-01-17 18:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505152&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pprint should (optionally) use str

Initial Comment:
pprint.pprint() uses repr to display an object. 
However I think it's at least as likely that pretty
printing would be used as a human debugging tool rather
than for generating a string "which can be used as
input to the interpreter".

pprint.pprint() -- and PrettyPrinter.pprint() should
optionally use str() to print a human readable
representation of the object.


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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-02 00:15

Message:
Logged In: YES 
user_id=12800

I'll make two points.  First, the pprint module
documentation should clearly state that repr() is used
instead of str().  It seems vague to me.

Second, perhaps we should add a pprint.sprint() to use str()
instead of repr().  I don't think the class needs to be
derivable, since other than str and repr, I can't think of
what you'd want to pretty print about an object. :)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-02 00:08

Message:
Logged In: YES 
user_id=3066

The usefulness of str() seems questionable; if the issue is
debugging, repr()-like presentation seems to make more
sense.  I do think the pretty-printer should be configurable
(via subclassing at least).

I've checked in an attempt to make it easier to change the
machinery use, but I'm not sure this is really the right change.

I'm closing the bug report as vague, but am interested in
suggestions for improving the pprint module.

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

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


From noreply@sourceforge.net  Tue Apr  2 08:44:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 00:44:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-535545 ] make fails at posixmodule.c
Message-ID: <E16sJuI-00051W-00@usw-sf-web3.sourceforge.net>

Bugs item #535545, was opened at 2002-03-27 03:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535545&group_id=5470

Category: Build
>Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Whit Blauvelt (whit)
Assigned to: Martin v. L�wis (loewis)
Summary: make fails at posixmodule.c

Initial Comment:
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. 
-I./Include -DHAVE_CONFIG_H   -c 
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1

This using gcc version 2.95.3 on what started life as 
a Red Hat 6.0 system.



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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-02 10:44

Message:
Logged In: YES 
user_id=21627

For 2.2.1, no action is needed - this is a system
configuration problem. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:21

Message:
Logged In: YES 
user_id=6656

Martin, what if anything do you think should be done here?

I'm leery of mucking with configure.in at this point.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 18:12

Message:
Logged In: YES 
user_id=133413

Have autoconf 2.13. Never explicitly used it though, and 
don't know the theory of it. If I patch, then invoke 
autoconf, then invoke configure ... well, that may not be 
what you mean, because it doesn't get around the problem.

If I just use your new configure file, that doesn't work 
either. Please specify the exact steps you require.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-29 17:35

Message:
Logged In: YES 
user_id=21627

If you have autoconf, you can just use the patch to
configure.in, and invoke 'autoconf'. In case you don't have
autoconf, I'll attach the complete configure file.


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 17:30

Message:
Logged In: YES 
user_id=133413

Um ...

# patch -p1 <../conf.txt 
patching file `configure.in'
patching file `configure'
Reversed (or previously applied) patch detected!  Assume -R?
[n] 
Apply anyway? [n] y
Hunk #1 FAILED at 1.
Hunk #2 FAILED at 1428.
2 out of 267 hunks FAILED -- saving rejects to configure.rej

If I say yes to -R, almost all hunks fail.

***************
*** 1,6 ****
  #! /bin/sh

- # From configure.in Revision: 1.288.6.3

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
--- 1,6 ----
  #! /bin/sh

+ # From configure.in Revision: 1.288.6.4

  # Guess values for system-dependent variables and create
Makefiles.
  # Generated automatically using autoconf version 2.13
***************
*** 1428,1434 ****
          fi      
        case $ac_sys_system in
        AIX*)
-          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $(LINKCC)";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)
--- 1428,1434 ----
          fi      
        case $ac_sys_system in
        AIX*)
+          LINKCC="\/Modules/makexp_aix
Modules/python.exp \\ \; $LINKCC";;
        dgux*)
           LINKCC="LD_RUN_PATH=$libdir $(LINKCC)";;
        Monterey64*)

Well, I'll try it as patched - those hunks don't look like
much is lost.

The config.log doesn't look good:

configure:2016: checking for sys/resource.h
configure:2026: gcc -E  conftest.c >/dev/null 2>conftest.out
In file included from /usr/include/sys/resource.h:25,
                 from configure:2022:
/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition
configure: failed program was:
#line 2021 "configure"
#include "confdefs.h"
#include <sys/resource.h>



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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=21627

Please try the attached conf.txt with an otherwise
unmodified system, and report whether it solves the problem.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 05:33

Message:
Logged In: YES 
user_id=133413

Probably not wisely, I tried changing the definition of
RLIM_INFINITY in bits/resource.h to match that in the kernel
header.  That took Python through the install, with make
test producing:

166 tests OK.
1 test failed:
    test_mmap
20 tests skipped:
    test_al test_cd test_cl test_curses test_dl test_gl
test_imgfile
    test_largefile test_linuxaudiodev test_minidom test_nis
    test_ntpath test_pyexpat test_sax test_socket_ssl
    test_socketserver test_sunaudiodev test_unicode_file
test_winreg
    test_winsound
4 skips unexpected on linux2:
    test_minidom test_linuxaudiodev test_pyexpat test_sax
make: *** [test] Error 1

As I understand all this, the definition to prefer should
probably be the one from glibc rather than the kernel (if it
even makes a difference on this value). Is this the one
which would be in effect if Python's configure were simply
to accept that resource.h is present rather than rejecting
it for this difference? 

RLIM_INFINITY btw is changed to match more recent kernels in
glibc 2.2 - but there's no rpm of that for Red Hat 6.x, and
of course building your own glibc is a good way to break a
system.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-29 00:03

Message:
Logged In: YES 
user_id=133413

A Google search leads me to a comment from Linus himself 
explaining that all the distributions symlinking like Red 
Hat 6.0 did are broken. I'm sure his theory is right, but 
out here in the real world, as he notes, many distros do 
that and most of us do have the idea that the current 
kernel should be built in /usr/src/linux. (Seems that rpms 
and debs of kernels put new kernel code there too - but 
I've always built kernels from tar.) 

Anyway, Linus's take is at: 
http://www.uwsg.iu.edu/hypermail/linux/kernel/0007.3/0587.html


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 23:43

Message:
Logged In: YES 
user_id=133413

You have good instincts on what to believe. I was mislead 
because rerunning configure produces a config.log without 
the warnings about resource.h. However running it in a 
freshly openned tar reproduces that warning; and even 
running it twice there (the second time, no warning) 
results in compilation failing at the same place.

So I think you have it - configure takes _any_ gcc warning 
as indicating nonexistence. And I think I see why the 
conflict comes on some systems but not on others. Red Hat 
6.0 sets /usr/include/asm as follows:

asm -> ../src/linux/include/asm/

That directory includes a "resource.h". On this box that 
happens to be code included with kernel 2.4.16, largely 
consisting of a modified definition of RLIM_INFINITY. I'd 
guess if the box still had a 2.2 kernel there would be no 
gcc warning. The whole of that file is:

#ifndef _I386_RESOURCE_H
#define _I386_RESOURCE_H

/*
 * Resource limits
 */

#define RLIMIT_CPU      0               /* CPU time in ms 
*/
#define RLIMIT_FSIZE    1               /* Maximum 
filesize */
#define RLIMIT_DATA     2               /* max data size */
#define RLIMIT_STACK    3               /* max stack size 
*/
#define RLIMIT_CORE     4               /* max core file 
size */
#define RLIMIT_RSS      5               /* max resident 
set size */
#define RLIMIT_NPROC    6               /* max number of 
processes */
#define RLIMIT_NOFILE   7               /* max number of 
open files */
#define RLIMIT_MEMLOCK  8               /* max 
locked-in-memory address space */
#define RLIMIT_AS       9               /* address space 
limit */
#define RLIMIT_LOCKS    10              /* maximum file 
locks held */

#define RLIM_NLIMITS    11

/*
 * SuS says limits have to be unsigned.
 * Which makes a ton more sense anyway.
 */
#define RLIM_INFINITY   (~0UL)

#ifdef __KERNEL__

#define INIT_RLIMITS                                    {                                                               { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {      _STK_LIM, RLIM_INFINITY },                       {             0, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       {             0,             0 },                       {      INR_OPEN,     INR_OPEN  },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },                       { RLIM_INFINITY, RLIM_INFINITY },               }
 
#endif /* __KERNEL__ */

#endif




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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-28 22:08

Message:
Logged In: YES 
user_id=21627

This is hard to believe: the spaces should have no effect.
Please consider the config.log analysis of the problem:

/usr/include/bits/resource.h:109: warning: `RLIM_INFINITY'
redefined
/usr/include/asm/resource.h:26: warning: this is the
location of the previous definition

Apparently, configure treats these warnings as an indication
that sys/resource.h is absent. config.log also gives the
"program" it tried to compile - if your theory is correct,
changing the spaces should silence the gcc warning. Could
you please verify this theory (i.e. compiling the program

#include <sys/resource.h>

both with the original and the modified resource.h)

It appears that configure should disable warnings in gcc;
I'll try to come up with a patch.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 18:20

Message:
Logged In: YES 
user_id=133413

Think you've led me to the problem.

/usr/include/bits/resource.h has:

/* Value to indicate that there is no limit.  */
#ifndef __USE_FILE_OFFSET64
# define RLIM_INFINITY ((long int)(~0UL >> 1))
#else
# define RLIM_INFINITY 0x7fffffffffffffffLL
#endif

#ifdef __USE_LARGEFILE64
# define RLIM64_INFINITY 0x7fffffffffffffffLL
#endif

Removing the spaces after "#" before "define" results in 
configure correctly recognizing resource.h. Then the 
question would be: is this a shortcoming of configure, or 
are those spaces actually disabling bugs in this version 
of bits/resource.h? 


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:56

Message:
Logged In: YES 
user_id=133413

Right, HAVE_SYS_RESOURCE_H is commented out.

config.log attached.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-28 17:42

Message:
Logged In: YES 
user_id=21627

Thanks, now we are getting somewhere. It appears that
pyconfig.h does not define HAVE_SYS_RESOURCE_H on your
system (can you confirm this? it should be commented out).

Since you reported earlier that that
/usr/include/sys/resource.h *is* present, it seems that
configure has not properly detected this fact. Can you
please attach the config.log also? 

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 17:02

Message:
Logged In: YES 
user_id=133413

Here it is.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-28 16:38

Message:
Logged In: YES 
user_id=21627

Unfortunately, I still can't see what is causing this
problem. Can you please regenerate posixmodule.i once more,
this time adding "--save-temps -dD"? That will give all
preprocessor defines.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:13

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...

Oh error: "File Upload: ArtifactFile: File must be > 20 
bytes and < 256000 bytes in length" and the size is 361734 
- time to compress


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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 14:10

Message:
Logged In: YES 
user_id=133413

Honest, it was checked. But here we go (again)...


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-28 11:17

Message:
Logged In: YES 
user_id=21627

Unfortunately, it is not attached; please check the checkbox.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-28 01:35

Message:
Logged In: YES 
user_id=133413

Attached is the end of the stderr output and 
posixmodule.i (combined in 1 file)



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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-28 01:06

Message:
Logged In: YES 
user_id=21627

I can't reproduce the problem on a similarly-configured machine.

Can you please add the options --trace-includes --save-temps
to the gcc command line? The first one will produce a lot of
output to stderr, the other will produce posixmodule.i.
Please attach both to the report.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 20:17

Message:
Logged In: YES 
user_id=133413

I'm _not_ certain about header files. The fragments you 
ask about are there _except_ for 

#define PRIO_PROCESS PRIO_PROCESS

The file is attached. I don't need a fix at this point, 
but if it's worth fixing for others ... or knowing what to 
specify as the system requirement here....


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 17:34

Message:
Logged In: YES 
user_id=21627

Are you sure you have installed the header files for this C
library as well? Can you please attach your copy or
/usr/include/bits/resource.h to this report? It should
contain the fragment

  PRIO_PROCESS = 0,             /* WHO is a process ID.  */
#define PRIO_PROCESS PRIO_PROCESS

Furthermore, /usr/include/sys/resource.h should contain the
fragment

/* Get the system-dependent definitions of structures and
bit values.  */
#include <bits/resource.h>

If you are not interested in investigating this further,
that would be fine as well.

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

Comment By: Whit Blauvelt (whit)
Date: 2002-03-27 16:33

Message:
Logged In: YES 
user_id=133413

glibc-2.1.3-15.i386.rpm
If by PRIO_ constants you mean shell variables(?), none.
Python configure reports "checking for getpriority  yes"

Each of the 2.x series fails to compile at that same point.
1.52 had no problem - and is all I actually needed at this
point.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 13:21

Message:
Logged In: YES 
user_id=21627

What is the glibc release that you use? What PRIO_ constants
are defined on your system? Do you have the getpriority call?

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

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


From noreply@sourceforge.net  Tue Apr  2 10:21:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 02:21:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16sLPk-0003Jr-00@usw-sf-web2.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 18:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Jason Cowley (sachmoz)
Date: 2002-04-02 10:21

Message:
Logged In: YES 
user_id=426262

I have tested the 're' version on the system that had the 
problem (Windows 2000) and it works fine.

Thanks everyone.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-02 03:24

Message:
Logged In: YES 
user_id=6380

The code I added to getproxies_registry() was wrong.

Can you try this instead? Manually patch the urllib.py to
replace the two lines

    type, address = splittype(address)
    if not type:

with these (indented the same):

    import re
    if not re.match('^([^/:]+)://', address):

This will ensure that the proxies dict looks like it should,
e.g. in your case it would be

{'ftp', 'http://www-cache.freeserve.com:8080',
 'http': 'http://www-cache.freeserve.com:8080'}

I'll see if I can test this myself when I have access to a
working Windows machine tomorrow.

Michael: when I check that it, you'll know it's good for
2.2.1. :-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 13:34

Message:
Logged In: YES 
user_id=6380

Michael, obviously it's better to hold off. :-(

I apologize for the wasted trip, Jason. I think I know where
I messed up but it'll have to wait until after breakfast (my
family are calling me :-).

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 13:07

Message:
Logged In: YES 
user_id=426262

Sorry, the last line on that last post should read:
host, selector = splithost(proxy)


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 13:03

Message:
Logged In: YES 
user_id=426262

It is difficult for me to test this because I am no longer 
using the same system, but I made a special journey this 
morning to test the bug fix.

Unfortunately, using the fix exposed what appears to be 
another error. Here is the traceback:

>>> webpage = urllib.urlopen('http://www.python.org').read()
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    webpage = urllib.urlopen('http://www.python.org').read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 166, in open
    name = 'open_' + urltype
TypeError: cannot concatenate 'str' and 'NoneType' objects

I have attempted to investigate this. The error occurred in 
the "open" function. On this system, the value of "urltype" 
is initially "http", and "proxy" is "//www-
cache.freeserve.com:8080". But then a split is performed on 
the "proxy" variable to split off the urltype, but the 
urltype has already been separated. Therefore, "urltype" is 
then assigned "None", causing the TypeError.

F.Y.I, self.proxies on this system is:
{'ftp', '//www-cache.freeserve.com:8080', 'http': '//www-
cache.freeserve.com:8080'}

I got it to work by removing the line:
urltype, proxyhost = splittype(proxy)

and changing the following line to:
host.selector = splithost(proxy)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 13:01

Message:
Logged In: YES 
user_id=6380

Nah, just stick it in. Even if it doesn't work, it's
harmless.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 09:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 23:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 05:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-28 03:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 17:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 15:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 13:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 20:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 20:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 19:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 18:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 17:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 13:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-14 04:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 22:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 21:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Tue Apr  2 14:39:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 06:39:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-503031 ] urllib.py: open_http() host problem
Message-ID: <E16sPR9-0006AF-00@usw-sf-web1.sourceforge.net>

Bugs item #503031, was opened at 2002-01-13 13:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=503031&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Jason Cowley (sachmoz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.py: open_http() host problem

Initial Comment:
While trying to use the httplib.py urlopen() function, 
as follows:

doc = urlopen("http://www.python.org").read()
print doc

I was receiving the following trace:

Traceback (most recent call last):
  File "C:/Documents and 
Settings/Administrator/Desktop/jason/grabpage.py", 
line 3, in ?
    doc = urlopen("http://www.python.org").read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 178, in open
    return getattr(self, name)(url)
  File "C:\Python22\lib\urllib.py", line 283, in 
open_http
    h = httplib.HTTP(host)
  File "C:\Python22\lib\httplib.py", line 688, in 
__init__
    self._setup(self._connection_class(host, port))
  File "C:\Python22\lib\httplib.py", line 343, in 
__init__
    self._set_hostport(host, port)
  File "C:\Python22\lib\httplib.py", line 349, in 
_set_hostport
    port = int(host[i+1:])
ValueError: invalid literal for int(): 

I managed to track the problem down to the function 
open_http() in urllib.py. The value of the 'host' 
variable contained the string 'http:' rather 
than 'www.python.org', when a call is made as follows:

httplib.HTTP(host)

Line 272 of urllib.py should be setting the 
variable 'host' to the value of 'realhost' but the 
statement is never executed. The function 'proxy_bypas
()' doesn't appear to do anything but return 0.

I fixed it for my own purposes by adding a statement:

host = realhost


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-02 09:39

Message:
Logged In: YES 
user_id=6380

Thanks! Checked in.  Take it away, Michael! :-)

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-02 05:21

Message:
Logged In: YES 
user_id=426262

I have tested the 're' version on the system that had the 
problem (Windows 2000) and it works fine.

Thanks everyone.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 22:24

Message:
Logged In: YES 
user_id=6380

The code I added to getproxies_registry() was wrong.

Can you try this instead? Manually patch the urllib.py to
replace the two lines

    type, address = splittype(address)
    if not type:

with these (indented the same):

    import re
    if not re.match('^([^/:]+)://', address):

This will ensure that the proxies dict looks like it should,
e.g. in your case it would be

{'ftp', 'http://www-cache.freeserve.com:8080',
 'http': 'http://www-cache.freeserve.com:8080'}

I'll see if I can test this myself when I have access to a
working Windows machine tomorrow.

Michael: when I check that it, you'll know it's good for
2.2.1. :-)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 08:34

Message:
Logged In: YES 
user_id=6380

Michael, obviously it's better to hold off. :-(

I apologize for the wasted trip, Jason. I think I know where
I messed up but it'll have to wait until after breakfast (my
family are calling me :-).

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 08:07

Message:
Logged In: YES 
user_id=426262

Sorry, the last line on that last post should read:
host, selector = splithost(proxy)


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-04-01 08:03

Message:
Logged In: YES 
user_id=426262

It is difficult for me to test this because I am no longer 
using the same system, but I made a special journey this 
morning to test the bug fix.

Unfortunately, using the fix exposed what appears to be 
another error. Here is the traceback:

>>> webpage = urllib.urlopen('http://www.python.org').read()
Traceback (most recent call last):
  File "<pyshell#7>", line 1, in ?
    webpage = urllib.urlopen('http://www.python.org').read()
  File "C:\Python22\lib\urllib.py", line 73, in urlopen
    return _urlopener.open(url)
  File "C:\Python22\lib\urllib.py", line 166, in open
    name = 'open_' + urltype
TypeError: cannot concatenate 'str' and 'NoneType' objects

I have attempted to investigate this. The error occurred in 
the "open" function. On this system, the value of "urltype" 
is initially "http", and "proxy" is "//www-
cache.freeserve.com:8080". But then a split is performed on 
the "proxy" variable to split off the urltype, but the 
urltype has already been separated. Therefore, "urltype" is 
then assigned "None", causing the TypeError.

F.Y.I, self.proxies on this system is:
{'ftp', '//www-cache.freeserve.com:8080', 'http': '//www-
cache.freeserve.com:8080'}

I got it to work by removing the line:
urltype, proxyhost = splittype(proxy)

and changing the following line to:
host.selector = splithost(proxy)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-01 08:01

Message:
Logged In: YES 
user_id=6380

Nah, just stick it in. Even if it doesn't work, it's
harmless.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 04:37

Message:
Logged In: YES 
user_id=6656

Do you want me to wait for confirmation before sticking this 
in release22-maint?


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-31 18:40

Message:
Logged In: YES 
user_id=6380

I've checked in my bugfix into CVS as urllib.py: 1.140.

Jason or someone else who is experiencing this problem, can
you please check that this fix (also in attachment
"urllib.diff") solves the problem for you?

(Hm, this should be a 2.2.1 bugfix candidate too.)

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-28 00:48

Message:
Logged In: YES 
user_id=6380

Not so quick, Mark.  Are your proxy settings the same as
his?

I've uploaded a proposed fix that does what Thomas Heller
recommends (urllib.diff). Thomas or sachmoz, can you verify
that it works?

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

Comment By: Mark Hammond (mhammond)
Date: 2002-03-27 22:43

Message:
Logged In: YES 
user_id=14198

Can not repro this:

>>> import urllib
>>> doc = urllib.urlopen("http://www.python.org").read() 
>>> len(doc)
11851
>>> 

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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 12:31

Message:
Logged In: YES 
user_id=11105

The (my) conclusion of all this is:

    # Per-protocol settings
    for p in proxyServer.split(';'):
        protocol, address = p.split('=', 1)
        proxies[protocol] = '%s://%s' % (protocol, address)

It should add a "http://" prefix if one isn't already there.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-16 10:37

Message:
Logged In: YES 
user_id=426262

I have found the document that theller referred to online, 
the URL is:

http://www.microsoft.com/WINDOWS2000/techinfo/reskit/en/ierk
/Ch13_d.htm

or alternatively:

http://www.microsoft.com/windows2000/techinfo/reskit/en-
us/default.asp?url=/WINDOWS2000/techinfo/reskit/en-
us/ierk/Ch13_d.asp

The actual registry entries that I posted earlier appear to 
be set by Windows2000/IE6. If you make the following series 
of clicks from IE:

Tools | Internet Options | Connections

Then in the section: Dial-up and Virtual Private Network 
settings click the Settings... button, then the Advanced... 
button under Proxy server, you will see a list of proxy 
servers for different protocols.

If I add a fake proxy server for Gopher, such as:

http://www-cache.sachmoz.com

with port 8080, the registry key data is altered to:

ftp=http://www-cache.freeserve.com:8080;gopher=http://www-
cache.sachmoz.com:8080;http=http://www-
cache.freeserve.com:8080


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

Comment By: Thomas Heller (theller)
Date: 2002-01-16 08:03

Message:
Logged In: YES 
user_id=11105

Here's a quote from Microsoft docs (Windows 2000 Server
Resource Kit). I have not found it online, but it's in my
local MSDN library April 2001:
MSDNLibrary ->
 Resource Kits ->
  Windows 2000 Server Resource Kit ->
   Internet Explorer 5 Resource Kit ->
    Part 3: Customizing ->
     Chapter 13: Setting up Servers ->
      Working with Proxy Servers

<quote>
Proxy locations that do not begin with a protocol (such as
http:// or ftp://) are assumed to be a CERN-type HTTP proxy.
For example, when the user types proxy, it's treated the
same as if the user typed http://proxy. For FTP gateways,
such as the TIS FTP gateway, the proxy should be listed with
the ftp:// in front of the proxy name. For example, an FTP
gateway for an FTP proxy would have this format: 

ftp://ftpproxy

When you enter proxy settings, use the following syntax,
where <address> is the Web address of the proxy server and
<port> is the port number assigned to the proxy server:

http://<address>:<port>

For example, if the address of the proxy server is
proxy.example.microsoft.com and the port number is 80, the
setting in the Proxy Server box for LAN settings in the
Proxy Settings dialog box or the Proxy Settings screen of
the Customization wizard should read as follows:

http://proxy.example.microsoft.com:80

</quote>

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:58

Message:
Logged In: YES 
user_id=11105

Isn't the correct setting for an ftp 
proxy "http://192.168.0.15:3128" instead 
of "ftp://192.168.0.15:3128".

At least, in Python 2.1, only the former works for me.
In Python 2.2 neither does, but maybe that's a different 
issue.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 15:18

Message:
Logged In: YES 
user_id=6380

Looks like this code block in getproxies_registry() is
broken then:

                    # Per-protocol settings
                    for p in proxyServer.split(';'):
                        protocol, address = p.split('=', 1)
                        proxies[protocol] = '%s://%s' %
(protocol, address)

It should only add the <protocol>:// prefix if one isn't
already there.

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

Comment By: Thomas Heller (theller)
Date: 2002-01-15 15:07

Message:
Logged In: YES 
user_id=11105

It seems sachmoz registry settings are valid for IE, I 
checked this by changing my own settings from

ftp=192.168.0.15:3128;http=192.168.0.13:3128

to 

ftp=http://192.168.0.15:3128;http=http://192.168.0.13:3128

IE works either before or after this change.

Here's the only article I found on MSDN showing an example:

http://support.microsoft.com/default.aspx?scid=kb;EN-
US;q164035

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 14:24

Message:
Logged In: YES 
user_id=6380

I'm assigning this to Mark Hammond, who knows more about the
Windows registry. Could there be a bug in the function
getproxies_registry()? See the last two posts from sachmoz;
ignore the original problem description.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-15 13:17

Message:
Logged In: YES 
user_id=426262

The actual settings in the registry look slightly different:

http=http://www-cache.freeserve.com:8080;ftp=http://www-
cache.freeserve.com:8080

Notice the '=' signs.

These settings have been set automatically by Freeserve, 
and so there are perhaps millions of people in the UK with 
the same registry settings (and therefore the same problem).

I have mailed Freeserve to ask them to confirm if the 
settings are correct.


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 12:46

Message:
Logged In: YES 
user_id=6380

If that's really what getproxies_registry() prints, then
look again at the URL in the dict for key 'http'. It says

'http://http://www-cache.freeserve.com:8080'

In other words a double http:// prefix!!!

If you fix the registry the problem will go away.

I don't think this is a problem with urllib.py.


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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-14 08:04

Message:
Logged In: YES 
user_id=426262

I hope this is what you need:

>>> print getproxies_environment()
{}
>>> print getproxies_registry()
{'ftp': 'ftp://http://www-
cache.freeserve.com:8080', 'http': 'http://http://www-
cache.freeserve.com:8080'}
>>>


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 23:46

Message:
Logged In: YES 
user_id=6380

Hm, you can only ever end up in that code block if you have
some kind of proxy settings active. On Windows, those are in
the registry, even if you think they are not.

Your fix is clearly not right -- but in order to find out
what is right, I need your proxy settings.

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

Comment By: Jason Cowley (sachmoz)
Date: 2002-01-13 17:35

Message:
Logged In: YES 
user_id=426262

I am not using a proxy, but I have a dial-up connection to 
an ISP and I am using Windows 2000.

The Python version info is:

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32

Here is the modification I made to urllib.py:

272: if proxy_bypass(realhost):
273:   host = realhost # this line was not being executed
274: host = realhost   # I added this to fix urlopen()

Without this line I added, the following statement was
being executed 9-10 lines below, with 'http:' as the value
of host:

h = httplib.HTTP(host)

Which later caused the problem when _set_hostport in 
httplib.py tries to convert an empty string to an int on 
line 349:
 
port = int(host[i+1:])

I have attached my copy of "urllib.py".


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-13 16:33

Message:
Logged In: YES 
user_id=6380

I cannot reproduce this.

What are your proxy settings?


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

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


From noreply@sourceforge.net  Tue Apr  2 14:44:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 06:44:22 -0800
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E16sPWI-0000hS-00@usw-sf-web4.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 04:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: Extension Modules
Group: Platform-specific
>Status: Open
>Resolution: Remind
>Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-02 09:44

Message:
Logged In: YES 
user_id=6380

Reopened and raised priority to 7. We should get this sorted
out for 2.2.1 final is released.

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

Comment By: Troels Walsted Hansen (troels)
Date: 2002-01-16 13:02

Message:
Logged In: YES 
user_id=32863

Unfortunately 1024 is too much as well. I just finished a 
long session with Purify on Solaris (with 
FD_SETSIZE==1024), and stack corruption occurs unless I 
change the test to "#if FD_SETSIZE > 1023"

Maybe the limit should be lowered to 511 so Windows users 
will get same behaviour as the old code?

I have been testing Python 2.2, browsing CVS tells me the 
code is the same at this point in time.


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-18 15:48

Message:
Logged In: YES 
user_id=12800

Ah I forgot to close this bug report.  This code's been in
the  source long enough to have uncovered problems if there
were any.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-16 17:58

Message:
Logged In: YES 
user_id=31435

Back to Barry for re-testing on Linux:  I checked in 
another version that refuses to add 3 to FD_SETSIZE 
anymore.  Fortune favors the bold.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 12:53

Message:
Logged In: YES 
user_id=12800

I've just checked in a minimal patch, taking the easy way
out (i.e. testing for FD_SETSIZE > 1024).  This subtly
changes the behavior on Windows (where Tim says the value is
now 512) since Windows won't normally take the
allocate-on-heap path now.  

selectmodule.c 2.54 has the change.

The changes pass on Linux both for normal, small FD_SETSIZEs
and for artificially cranked FD_SETSIZEs.  Assigning back to
Tim for verification on Windows.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-06 16:52

Message:
Logged In: YES 
user_id=31435

Reassigned to Barry.  I may a good choice to write the 
code, but not to test it (I know zilch about sockets, and 
can't provoke the problem on Windows anyway).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 08:36

Message:
Logged In: YES 
user_id=6380

Dear Anonymous,

a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.

A better idea is currently being discussed on python-dev.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 04:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

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

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


From noreply@sourceforge.net  Tue Apr  2 14:59:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 06:59:09 -0800
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E16sPkb-0006hR-00@usw-sf-web2.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 04:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: Remind
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Tim Peters (tim_one)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

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

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-02 09:59

Message:
Logged In: YES 
user_id=12800

Could this be an off-by-one error in the #if choice for
SELECT_USES_HEAP?  Also, I don't know what the right answer
is for Windows, and I don't have a Solaris 8 box handy (I've
had trouble getting access to the SF compile farm).

I'm reassigning this bug to Tim for pronouncement on troels
Windows question.  If we do drop it to 511, then it'll
probably be fine for Solaris (and I can certainly test it on
Linux).  Otherwise, perhaps we should drop it to 1023.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-02 09:44

Message:
Logged In: YES 
user_id=6380

Reopened and raised priority to 7. We should get this sorted
out for 2.2.1 final is released.

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

Comment By: Troels Walsted Hansen (troels)
Date: 2002-01-16 13:02

Message:
Logged In: YES 
user_id=32863

Unfortunately 1024 is too much as well. I just finished a 
long session with Purify on Solaris (with 
FD_SETSIZE==1024), and stack corruption occurs unless I 
change the test to "#if FD_SETSIZE > 1023"

Maybe the limit should be lowered to 511 so Windows users 
will get same behaviour as the old code?

I have been testing Python 2.2, browsing CVS tells me the 
code is the same at this point in time.


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-18 15:48

Message:
Logged In: YES 
user_id=12800

Ah I forgot to close this bug report.  This code's been in
the  source long enough to have uncovered problems if there
were any.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-16 17:58

Message:
Logged In: YES 
user_id=31435

Back to Barry for re-testing on Linux:  I checked in 
another version that refuses to add 3 to FD_SETSIZE 
anymore.  Fortune favors the bold.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 12:53

Message:
Logged In: YES 
user_id=12800

I've just checked in a minimal patch, taking the easy way
out (i.e. testing for FD_SETSIZE > 1024).  This subtly
changes the behavior on Windows (where Tim says the value is
now 512) since Windows won't normally take the
allocate-on-heap path now.  

selectmodule.c 2.54 has the change.

The changes pass on Linux both for normal, small FD_SETSIZEs
and for artificially cranked FD_SETSIZEs.  Assigning back to
Tim for verification on Windows.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-06 16:52

Message:
Logged In: YES 
user_id=31435

Reassigned to Barry.  I may a good choice to write the 
code, but not to test it (I know zilch about sockets, and 
can't provoke the problem on Windows anyway).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 08:36

Message:
Logged In: YES 
user_id=6380

Dear Anonymous,

a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.

A better idea is currently being discussed on python-dev.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 04:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

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

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


From noreply@sourceforge.net  Tue Apr  2 17:14:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 09:14:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16sRrQ-0002SH-00@usw-sf-web4.sourceforge.net>

Bugs item #524600, was opened at 2002-03-01 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



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

Comment By: Patrick Miller (patmiller)
Date: 2002-04-02 09:14

Message:
Logged In: YES 
user_id=30074

>From my reading of the header, we need to

#ifdef STUPID_TRU64_STAT_MACROS
#define __V40_OBJ_COMPAT
#endif
#include "sys/stat.h"

When you do that, the include looks like....
% cpp  -D__V40_OBJ_COMPAT /usr/include/sys/stat.h | fgrep
stat
  struct stat {
  extern int stat ();
  extern int fstat ();
    extern int lstat ();
(some of above lines removed for readability)


Here's the scoop from stat.h

/*
 * Define the function prototypes for stat, fstat and
lstat.  The __(())
 * MACRO is use to control whether ANSI C or K&R style
function prototypes
 * are declared.
 *
 * The normal path will have __EXTERN_PREFIX defined, no
wrapper function
 * MACROs for stat, fstat, or lstat will exist, and the
__F64_XXX__() MACROs
 * will all be no-ops.  This will result in declaring
function prototypes
 * for _F64_stat, _F64_fstat, and _F64_lstat, and all
function calls to
 * stat, fstat, and lstat in the module will be
transparently renamed to the
 * _F64_xxx variant.
 *
 * If a compiler other than DECC is being used then, the
__F64_XXX__()
 * MACROs will perform the function renaming.
 *
 * If the program has created its own wrapper function
MACROs to rename one
 * of the stat, fstat, or lstat functions, then that
function will be
 * declared using the name provided by the program's MACRO. 
The wrapper
 * function prototypes are declared using the new stat
structure (Wrappers
 * that want the old stat structure should be compiled with
 * __V40_OBJ_COMPAT).
 *
 * Finally if either __V40_OBJ_COMPAT is defined, XPG4
standard compliance
 * has been requested, or ISO C or ANSI C standard
compliance has been
 * requested, then the function prototypes will be declared
using the names
 * stat, fstat, and lstat (no function renaming will
occur).  Calls to these
 * functions will return the old stat structure.
 *
 * Again, please do not write programs that directly call
_F64_xxx named
 * fucntions.  Use the standard stat, fstat, and lstat
function names and
 * allow this header file to perform the necessary renaming
as part of the
 * compile.  That way the program will remain portable.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-31 03:31

Message:
Logged In: YES 
user_id=21627

Then this *is* a gcc issue. First, gcc does not implement
the pragma, but should (I just added support for the SunPRO
pragma redefine_extname to gcc for precisely the same
reason: Sun also renames LFS functions). If the #ifdef
really is for DECC, then it is doubtful, though, whether gcc
should define DECC even if it supports the pragma.

It is questionable whose problem this is, but I doubt Compaq
will care much about breakage occurring only with a
third-party compiler. GCC has a strategy for this, so it is
a gcc bug that this strategy is not applied: fixincludes.
GCC produces shadow copies of the system headers to correct
all kinds of problems. It should apply such fixing also to
these headers.

For the specific case, it would probably be sufficient to
change the #define line to

#define stat __F64_stat

Then, taking an address of stat will take the address of
__F64_stat. Better yet, the fixed header files should use
the GCC equivalent of the DECC pragma:

int stat(char*, struct stat*)
  __attribute__((alias("__F64_stat");

Adding this to fixincludes will be a challenge, though; for
Sun, we decided that it is easier to implement the Sun
pragma (especially as it was protected with an #ifdef
__PRAGMA_REDEFINE_EXTNAME, so gcc does not need to claim
being SUNC).

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-30 21:38

Message:
Logged In: YES 
user_id=555

I don't have the code at hand, but it looks something like this:

#ifdef DECC
#pragma something_that_maps_stat_to__F64_stat
#else
#define stat(...) __F64_stat(...)
#endif

I'm quite confident it's not a gcc issue, except in that any
merely standards-compliant compiler would fail here.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-30 00:47

Message:
Logged In: YES 
user_id=21627

So where is the magic that redirects stat to _F64_stat? It
would be ok if there was no stat prototype, under the
'as-if' rule: If that magic behaved as if there was a stat
prototype (i.e. allowing to take the address of stat), then
there would be no problem.

Could it be that this is gcc related? I know that users have
successfully built Python 2.x on Tru64 5.x, probably using
the system compiler. So it might be that gcc has bogus
headers, or is missing a feature that it needs to work
correctly on that machine.

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-29 19:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

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

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 14:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-29 01:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


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

Comment By: Mike Coleman (mkc)
Date: 2002-03-27 16:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-03 13:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

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

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


From noreply@sourceforge.net  Tue Apr  2 17:30:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 09:30:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16sS6z-0002pD-00@usw-sf-web3.sourceforge.net>

Bugs item #524600, was opened at 2002-03-02 00:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-02 19:30

Message:
Logged In: YES 
user_id=21627

So what is the difference between the old and the new stat
structure? Defining __V40_OBJ_COMPAT seems wrong to me; I
assume you want to use the new stat structure, and you do
want to call the F64 functions. If the compiler does not
support that scenario, it's a compiler bug.

patmiller's comment offers a work-around, though: putting
__V40_OBJ_COMPAT into CFLAGS (and probably OPT as well)
should allow compilation to succeed.

Closing as 'won't fix'.

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

Comment By: Patrick Miller (patmiller)
Date: 2002-04-02 19:14

Message:
Logged In: YES 
user_id=30074

>From my reading of the header, we need to

#ifdef STUPID_TRU64_STAT_MACROS
#define __V40_OBJ_COMPAT
#endif
#include "sys/stat.h"

When you do that, the include looks like....
% cpp  -D__V40_OBJ_COMPAT /usr/include/sys/stat.h | fgrep
stat
  struct stat {
  extern int stat ();
  extern int fstat ();
    extern int lstat ();
(some of above lines removed for readability)


Here's the scoop from stat.h

/*
 * Define the function prototypes for stat, fstat and
lstat.  The __(())
 * MACRO is use to control whether ANSI C or K&R style
function prototypes
 * are declared.
 *
 * The normal path will have __EXTERN_PREFIX defined, no
wrapper function
 * MACROs for stat, fstat, or lstat will exist, and the
__F64_XXX__() MACROs
 * will all be no-ops.  This will result in declaring
function prototypes
 * for _F64_stat, _F64_fstat, and _F64_lstat, and all
function calls to
 * stat, fstat, and lstat in the module will be
transparently renamed to the
 * _F64_xxx variant.
 *
 * If a compiler other than DECC is being used then, the
__F64_XXX__()
 * MACROs will perform the function renaming.
 *
 * If the program has created its own wrapper function
MACROs to rename one
 * of the stat, fstat, or lstat functions, then that
function will be
 * declared using the name provided by the program's MACRO. 
The wrapper
 * function prototypes are declared using the new stat
structure (Wrappers
 * that want the old stat structure should be compiled with
 * __V40_OBJ_COMPAT).
 *
 * Finally if either __V40_OBJ_COMPAT is defined, XPG4
standard compliance
 * has been requested, or ISO C or ANSI C standard
compliance has been
 * requested, then the function prototypes will be declared
using the names
 * stat, fstat, and lstat (no function renaming will
occur).  Calls to these
 * functions will return the old stat structure.
 *
 * Again, please do not write programs that directly call
_F64_xxx named
 * fucntions.  Use the standard stat, fstat, and lstat
function names and
 * allow this header file to perform the necessary renaming
as part of the
 * compile.  That way the program will remain portable.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-31 13:31

Message:
Logged In: YES 
user_id=21627

Then this *is* a gcc issue. First, gcc does not implement
the pragma, but should (I just added support for the SunPRO
pragma redefine_extname to gcc for precisely the same
reason: Sun also renames LFS functions). If the #ifdef
really is for DECC, then it is doubtful, though, whether gcc
should define DECC even if it supports the pragma.

It is questionable whose problem this is, but I doubt Compaq
will care much about breakage occurring only with a
third-party compiler. GCC has a strategy for this, so it is
a gcc bug that this strategy is not applied: fixincludes.
GCC produces shadow copies of the system headers to correct
all kinds of problems. It should apply such fixing also to
these headers.

For the specific case, it would probably be sufficient to
change the #define line to

#define stat __F64_stat

Then, taking an address of stat will take the address of
__F64_stat. Better yet, the fixed header files should use
the GCC equivalent of the DECC pragma:

int stat(char*, struct stat*)
  __attribute__((alias("__F64_stat");

Adding this to fixincludes will be a challenge, though; for
Sun, we decided that it is easier to implement the Sun
pragma (especially as it was protected with an #ifdef
__PRAGMA_REDEFINE_EXTNAME, so gcc does not need to claim
being SUNC).

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-31 07:38

Message:
Logged In: YES 
user_id=555

I don't have the code at hand, but it looks something like this:

#ifdef DECC
#pragma something_that_maps_stat_to__F64_stat
#else
#define stat(...) __F64_stat(...)
#endif

I'm quite confident it's not a gcc issue, except in that any
merely standards-compliant compiler would fail here.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-30 09:47

Message:
Logged In: YES 
user_id=21627

So where is the magic that redirects stat to _F64_stat? It
would be ok if there was no stat prototype, under the
'as-if' rule: If that magic behaved as if there was a stat
prototype (i.e. allowing to take the address of stat), then
there would be no problem.

Could it be that this is gcc related? I know that users have
successfully built Python 2.x on Tru64 5.x, probably using
the system compiler. So it might be that gcc has bogus
headers, or is missing a feature that it needs to work
correctly on that machine.

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-30 04:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

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

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 23:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-29 10:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


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

Comment By: Mike Coleman (mkc)
Date: 2002-03-28 01:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-03 22:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

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

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


From noreply@sourceforge.net  Tue Apr  2 17:42:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 09:42:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E16sSIR-0008Mf-00@usw-sf-web1.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 04:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: Remind
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.
.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-02 12:42

Message:
Logged In: YES 
user_id=31435

troels, which version of Solaris are you using?  This 
report is getting confused because the original report was 
talking about Solaris 8 with FD_SETSIZE 65536.  You say 
FD_SETSIZE is 1024 for you, so yours is likely to be a 
different problem entirely.  Are you using a 64-bit or a 32-
bit system?

Changing the limit doesn't appear to be a good idea at this 
time:  the evidence here suggests more that there's a bug 
in the stack-based version of this code than that you're 
actually running out of stack space.  But that there's "a 
bug" at all isn't clear either:  as far as I can tell, the 
only reason you're claiming "there's a bug" is because 
Purify complains.  Purify isn't always accurate.  Can you 
say more about what Purify's exact complaint is?  Can you 
attach a small executable program that triggers the 
complaint?

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-02 09:59

Message:
Logged In: YES 
user_id=12800

Could this be an off-by-one error in the #if choice for
SELECT_USES_HEAP?  Also, I don't know what the right answer
is for Windows, and I don't have a Solaris 8 box handy (I've
had trouble getting access to the SF compile farm).

I'm reassigning this bug to Tim for pronouncement on troels
Windows question.  If we do drop it to 511, then it'll
probably be fine for Solaris (and I can certainly test it on
Linux).  Otherwise, perhaps we should drop it to 1023.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-02 09:44

Message:
Logged In: YES 
user_id=6380

Reopened and raised priority to 7. We should get this sorted
out for 2.2.1 final is released.

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

Comment By: Troels Walsted Hansen (troels)
Date: 2002-01-16 13:02

Message:
Logged In: YES 
user_id=32863

Unfortunately 1024 is too much as well. I just finished a 
long session with Purify on Solaris (with 
FD_SETSIZE==1024), and stack corruption occurs unless I 
change the test to "#if FD_SETSIZE > 1023"

Maybe the limit should be lowered to 511 so Windows users 
will get same behaviour as the old code?

I have been testing Python 2.2, browsing CVS tells me the 
code is the same at this point in time.


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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-10-18 15:48

Message:
Logged In: YES 
user_id=12800

Ah I forgot to close this bug report.  This code's been in
the  source long enough to have uncovered problems if there
were any.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-16 17:58

Message:
Logged In: YES 
user_id=31435

Back to Barry for re-testing on Linux:  I checked in 
another version that refuses to add 3 to FD_SETSIZE 
anymore.  Fortune favors the bold.

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

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-08-16 12:53

Message:
Logged In: YES 
user_id=12800

I've just checked in a minimal patch, taking the easy way
out (i.e. testing for FD_SETSIZE > 1024).  This subtly
changes the behavior on Windows (where Tim says the value is
now 512) since Windows won't normally take the
allocate-on-heap path now.  

selectmodule.c 2.54 has the change.

The changes pass on Linux both for normal, small FD_SETSIZEs
and for artificially cranked FD_SETSIZEs.  Assigning back to
Tim for verification on Windows.

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

Comment By: Tim Peters (tim_one)
Date: 2001-08-06 16:52

Message:
Logged In: YES 
user_id=31435

Reassigned to Barry.  I may a good choice to write the 
code, but not to test it (I know zilch about sockets, and 
can't provoke the problem on Windows anyway).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 08:36

Message:
Logged In: YES 
user_id=6380

Dear Anonymous,

a quick workaround is to change the three #ifdef MS_WINDOWS
in selectmodule.c into #if FD_SETSIZE > 1024.

A better idea is currently being discussed on python-dev.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-06 04:31

Message:
Logged In: NO 

The attachment missed, this is the mentioned script:

import threading
import telnetlib

def telnetToHost():
    
        hostname = "my_hostname"
        username = "user_name"
        password = "password"
        
        tn = telnetlib.Telnet(hostname)
        tn.read_until("login: ")
        tn.write(username + '\n')
        tn.read_until("Password: ")
        tn.write(password + '\n')

class MyThread(threading.Thread):
        
        def run(self):
                print "ThreadID", self.cnt, "started"
                telnetToHost()
                print "ThreadID", self.cnt, "finished"

for i in range(0,4):
        m = MyThread()
        m.cnt = i
        m.start()

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

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


From noreply@sourceforge.net  Tue Apr  2 17:54:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 09:54:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16sSU1-00036D-00@usw-sf-web3.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


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

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


From noreply@sourceforge.net  Tue Apr  2 18:25:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:25:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-538369 ] time.mktime() doesn't raise exception
Message-ID: <E16sSy2-0003Im-00@usw-sf-web4.sourceforge.net>

Bugs item #538369, was opened at 2002-04-02 13:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538369&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.mktime() doesn't raise exception

Initial Comment:
RH 6.2/alpha, egcs-2.91 , python 2.2.1c2:

import time
time.mktime((999999,)*9)

should raise and exception. It doesn't.
This is similar to bug 460357, where this
occurs on Sparc64.


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

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


From noreply@sourceforge.net  Tue Apr  2 18:33:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:33:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16sT6N-0000lP-00@usw-sf-web2.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 17:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-02 18:33

Message:
Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?


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

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


From noreply@sourceforge.net  Tue Apr  2 18:36:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:36:02 -0800
Subject: [Python-bugs-list] [ python-Bugs-538369 ] time.mktime() doesn't raise exception
Message-ID: <E16sT8U-0000n9-00@usw-sf-web2.sourceforge.net>

Bugs item #538369, was opened at 2002-04-02 18:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538369&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.mktime() doesn't raise exception

Initial Comment:
RH 6.2/alpha, egcs-2.91 , python 2.2.1c2:

import time
time.mktime((999999,)*9)

should raise and exception. It doesn't.
This is similar to bug 460357, where this
occurs on Sparc64.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-02 18:36

Message:
Logged In: YES 
user_id=6656

Why should it?  Isn't this just a bug in the test?  (Not 
rhetorical questions!)


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

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


From noreply@sourceforge.net  Tue Apr  2 18:40:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:40:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-537998 ] windows getpass broken on python 2.2
Message-ID: <E16sTCS-0000qB-00@usw-sf-web2.sourceforge.net>

Bugs item #537998, was opened at 2002-04-01 20:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537998&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Tim Peters (tim_one)
Summary: windows getpass broken on python 2.2

Initial Comment:
Windows 2000 Python 2.2

>>> import getpass
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)
>>> getpass.getpass()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python22\lib\getpass.py", line 29, in
unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
AttributeError: 'module' object has no attribute
'tcgetattr'
>>>

I think the problem is that TERMIOS.py and termios.py
are the same thing on windows which causes a strange
Deprecation warning.  Python 2.1 used to fail on import
of termios

C:\Documents and Settings\bkelley\My
Documents\Downloads\Webware>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import termios
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)

anyway, TERMIOS.py should probably not be installed on
windows.  This should be removed from 2.2.1c2
Brian


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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-02 18:40

Message:
Logged In: YES 
user_id=6656

Oh good.  Lowering priority on assumption this isn't our 
fault.

Maybe PYTHONCASEOK should die?


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

Comment By: Tim Peters (tim_one)
Date: 2002-04-01 21:09

Message:
Logged In: YES 
user_id=31435

getpass() works fine on Windows:

C:\Python22>python
Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import getpass
>>> getpass.getpass()
Password:
'abc'
>>>

I suspect Brian has set the PYTHONCASEOK envar on Windows, 
in which case any number of insane things can happen (it 
tells Python to ignore case mismatches then).  Brian?

Not shipping TERMIOS.py isn't an option.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 20:45

Message:
Logged In: YES 
user_id=6656

Oops.  That sucks.

Tim, this must be case confusion of some kind.  termios.py 
has never existed, however there's now a placeholder Lib/
TERMIOS.py, deprecated in favour of using the termios 
(lowercase) module.  Is Brian's suggestion of just not 
installing TERMIOS.py feasible?

Brian: thanks!


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

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


From noreply@sourceforge.net  Tue Apr  2 18:45:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:45:20 -0800
Subject: [Python-bugs-list] [ python-Bugs-538369 ] time.mktime() doesn't raise exception
Message-ID: <E16sTHU-0003jl-00@usw-sf-web3.sourceforge.net>

Bugs item #538369, was opened at 2002-04-02 13:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538369&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.mktime() doesn't raise exception

Initial Comment:
RH 6.2/alpha, egcs-2.91 , python 2.2.1c2:

import time
time.mktime((999999,)*9)

should raise and exception. It doesn't.
This is similar to bug 460357, where this
occurs on Sparc64.


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

>Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:45

Message:
Logged In: YES 
user_id=503643

I guess I misunderstood the spec on time.mktime().
I was under the impression that if one of the
slots in the tuple, like seconds, was out of range,
then it should raise an exception. It doesn't and
it doesn't do it on RH7.1/i386/python 2.2 or
Win2k/i386/python 2.2.

But, in my defense, test_time says it *should* raise
an exception. Which is where I started. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:36

Message:
Logged In: YES 
user_id=6656

Why should it?  Isn't this just a bug in the test?  (Not 
rhetorical questions!)


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

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


From noreply@sourceforge.net  Tue Apr  2 18:47:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:47:58 -0800
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16sTK2-0003lg-00@usw-sf-web3.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


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

>Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:47

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:33

Message:
Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?


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

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


From noreply@sourceforge.net  Tue Apr  2 18:48:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:48:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16sTKh-0003mP-00@usw-sf-web3.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


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

>Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:48

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:47

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:33

Message:
Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?


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

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


From noreply@sourceforge.net  Tue Apr  2 18:49:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:49:45 -0800
Subject: [Python-bugs-list] [ python-Bugs-538369 ] time.mktime() doesn't raise exception
Message-ID: <E16sTLl-0000wc-00@usw-sf-web2.sourceforge.net>

Bugs item #538369, was opened at 2002-04-02 18:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538369&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.mktime() doesn't raise exception

Initial Comment:
RH 6.2/alpha, egcs-2.91 , python 2.2.1c2:

import time
time.mktime((999999,)*9)

should raise and exception. It doesn't.
This is similar to bug 460357, where this
occurs on Sparc64.


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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-02 18:49

Message:
Logged In: YES 
user_id=6656

Well, I don't know what mktime should do either :-/

Yes, there's a bug here.  Tests shouldn't fail on 64bit 
platforms (the same thing happens on IA64, too).  I don't 
know the issues well enough to fix it myself, though.


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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 18:45

Message:
Logged In: YES 
user_id=503643

I guess I misunderstood the spec on time.mktime().
I was under the impression that if one of the
slots in the tuple, like seconds, was out of range,
then it should raise an exception. It doesn't and
it doesn't do it on RH7.1/i386/python 2.2 or
Win2k/i386/python 2.2.

But, in my defense, test_time says it *should* raise
an exception. Which is where I started. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 18:36

Message:
Logged In: YES 
user_id=6656

Why should it?  Isn't this just a bug in the test?  (Not 
rhetorical questions!)


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

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


From noreply@sourceforge.net  Tue Apr  2 18:50:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:50:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-537998 ] windows getpass broken on python 2.2
Message-ID: <E16sTMd-0000xF-00@usw-sf-web2.sourceforge.net>

Bugs item #537998, was opened at 2002-04-01 15:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537998&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Tim Peters (tim_one)
Summary: windows getpass broken on python 2.2

Initial Comment:
Windows 2000 Python 2.2

>>> import getpass
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)
>>> getpass.getpass()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python22\lib\getpass.py", line 29, in
unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
AttributeError: 'module' object has no attribute
'tcgetattr'
>>>

I think the problem is that TERMIOS.py and termios.py
are the same thing on windows which causes a strange
Deprecation warning.  Python 2.1 used to fail on import
of termios

C:\Documents and Settings\bkelley\My
Documents\Downloads\Webware>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import termios
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)

anyway, TERMIOS.py should probably not be installed on
windows.  This should be removed from 2.2.1c2
Brian


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

Comment By: Brian Kelley (wc2so1)
Date: 2002-04-02 13:50

Message:
Logged In: YES 
user_id=424987

For some reason a lowercase "termios.pyc" ended up in my
python directory.  I removed it and everything worked fine.
 If it happens again, I'll let you all know.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:40

Message:
Logged In: YES 
user_id=6656

Oh good.  Lowering priority on assumption this isn't our 
fault.

Maybe PYTHONCASEOK should die?


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

Comment By: Tim Peters (tim_one)
Date: 2002-04-01 16:09

Message:
Logged In: YES 
user_id=31435

getpass() works fine on Windows:

C:\Python22>python
Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import getpass
>>> getpass.getpass()
Password:
'abc'
>>>

I suspect Brian has set the PYTHONCASEOK envar on Windows, 
in which case any number of insane things can happen (it 
tells Python to ignore case mismatches then).  Brian?

Not shipping TERMIOS.py isn't an option.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 15:45

Message:
Logged In: YES 
user_id=6656

Oops.  That sucks.

Tim, this must be case confusion of some kind.  termios.py 
has never existed, however there's now a placeholder Lib/
TERMIOS.py, deprecated in favour of using the termios 
(lowercase) module.  Is Brian's suggestion of just not 
installing TERMIOS.py feasible?

Brian: thanks!


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

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


From noreply@sourceforge.net  Tue Apr  2 18:51:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:51:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16sTNk-0000y5-00@usw-sf-web2.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 17:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-02 18:51

Message:
Logged In: YES 
user_id=6656

Oh.  That means it might be our fault.  Damn.

Erm, clutching at straws: what flavour of alpha is this?  I'm 
guessing this is some kind of alignment problem.



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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 18:48

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 18:47

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 18:33

Message:
Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?


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

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


From noreply@sourceforge.net  Tue Apr  2 18:59:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 10:59:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16sTVS-0003uM-00@usw-sf-web3.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


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

>Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:59

Message:
Logged In: YES 
user_id=503643

EV6 I think. Can I run a command to find out?


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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:51

Message:
Logged In: YES 
user_id=6656

Oh.  That means it might be our fault.  Damn.

Erm, clutching at straws: what flavour of alpha is this?  I'm 
guessing this is some kind of alignment problem.



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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:48

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:47

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:33

Message:
Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?


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

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


From noreply@sourceforge.net  Tue Apr  2 19:18:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 11:18:17 -0800
Subject: [Python-bugs-list] [ python-Bugs-537998 ] windows getpass broken on python 2.2
Message-ID: <E16sTnN-0003uV-00@usw-sf-web4.sourceforge.net>

Bugs item #537998, was opened at 2002-04-01 15:05
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537998&group_id=5470

Category: Windows
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Brian Kelley (wc2so1)
Assigned to: Tim Peters (tim_one)
Summary: windows getpass broken on python 2.2

Initial Comment:
Windows 2000 Python 2.2

>>> import getpass
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)
>>> getpass.getpass()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "c:\python22\lib\getpass.py", line 29, in
unix_getpass
    old = termios.tcgetattr(fd)     # a copy to save
AttributeError: 'module' object has no attribute
'tcgetattr'
>>>

I think the problem is that TERMIOS.py and termios.py
are the same thing on windows which causes a strange
Deprecation warning.  Python 2.1 used to fail on import
of termios

C:\Documents and Settings\bkelley\My
Documents\Downloads\Webware>python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for
more information.
>>> import termios
C:\Python22\lib\termios.py:7: DeprecationWarning: the
TERMIOS module is deprecated; please use termios
  DeprecationWarning)

anyway, TERMIOS.py should probably not be installed on
windows.  This should be removed from 2.2.1c2
Brian


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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-02 14:18

Message:
Logged In: YES 
user_id=31435

Closing as Not-a-Bug.  If it pops up again, we can reopen 
it.  PYTHONCASEOK will probably never die -- as the "Import 
on Case-Insensitive Filesystems" PEP explains, it's 
necessary if Python is to work at all on some case-
*destroying* filesystems (which, alas, still exist).

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

Comment By: Brian Kelley (wc2so1)
Date: 2002-04-02 13:50

Message:
Logged In: YES 
user_id=424987

For some reason a lowercase "termios.pyc" ended up in my
python directory.  I removed it and everything worked fine.
 If it happens again, I'll let you all know.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:40

Message:
Logged In: YES 
user_id=6656

Oh good.  Lowering priority on assumption this isn't our 
fault.

Maybe PYTHONCASEOK should die?


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

Comment By: Tim Peters (tim_one)
Date: 2002-04-01 16:09

Message:
Logged In: YES 
user_id=31435

getpass() works fine on Windows:

C:\Python22>python
Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import getpass
>>> getpass.getpass()
Password:
'abc'
>>>

I suspect Brian has set the PYTHONCASEOK envar on Windows, 
in which case any number of insane things can happen (it 
tells Python to ignore case mismatches then).  Brian?

Not shipping TERMIOS.py isn't an option.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 15:45

Message:
Logged In: YES 
user_id=6656

Oops.  That sucks.

Tim, this must be case confusion of some kind.  termios.py 
has never existed, however there's now a placeholder Lib/
TERMIOS.py, deprecated in favour of using the termios 
(lowercase) module.  Is Brian's suggestion of just not 
installing TERMIOS.py feasible?

Brian: thanks!


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

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


From noreply@sourceforge.net  Tue Apr  2 19:44:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 11:44:42 -0800
Subject: [Python-bugs-list] [ python-Bugs-538369 ] time.mktime() doesn't raise exception
Message-ID: <E16sUCw-0001Nd-00@usw-sf-web1.sourceforge.net>

Bugs item #538369, was opened at 2002-04-02 13:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538369&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Mike Carifio (carifio)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: time.mktime() doesn't raise exception

Initial Comment:
RH 6.2/alpha, egcs-2.91 , python 2.2.1c2:

import time
time.mktime((999999,)*9)

should raise and exception. It doesn't.
This is similar to bug 460357, where this
occurs on Sparc64.


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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-02 14:44

Message:
Logged In: YES 
user_id=31435

Assigned to Barry and boosted priority -- please fix this 
in a way you can live with.  Neither C nor POSIX define the 
range of time_t, and test_time's belief that test_mktime() 
*should* raise OverflowError seems pure assumption to me.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:49

Message:
Logged In: YES 
user_id=6656

Well, I don't know what mktime should do either :-/

Yes, there's a bug here.  Tests shouldn't fail on 64bit 
platforms (the same thing happens on IA64, too).  I don't 
know the issues well enough to fix it myself, though.


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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:45

Message:
Logged In: YES 
user_id=503643

I guess I misunderstood the spec on time.mktime().
I was under the impression that if one of the
slots in the tuple, like seconds, was out of range,
then it should raise an exception. It doesn't and
it doesn't do it on RH7.1/i386/python 2.2 or
Win2k/i386/python 2.2.

But, in my defense, test_time says it *should* raise
an exception. Which is where I started. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:36

Message:
Logged In: YES 
user_id=6656

Why should it?  Isn't this just a bug in the test?  (Not 
rhetorical questions!)


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

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


From noreply@sourceforge.net  Tue Apr  2 21:24:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 13:24:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16sVlP-0002sG-00@usw-sf-web2.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-02 16:24

Message:
Logged In: YES 
user_id=31435

Can you show what's in s?  As is, it's impossible to guess 
whether the problem is in pack() or unpack().  Life would 
be simpler if you started with a simpler float too (like, 
say, 1.0).

Something random that might help:  recompile structmodule.c 
with optimization turned off.

One other:  is this Alpha configured to run in big-endian 
or little-endian mode?

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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:59

Message:
Logged In: YES 
user_id=503643

EV6 I think. Can I run a command to find out?


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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:51

Message:
Logged In: YES 
user_id=6656

Oh.  That means it might be our fault.  Damn.

Erm, clutching at straws: what flavour of alpha is this?  I'm 
guessing this is some kind of alignment problem.



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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:48

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:47

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:33

Message:
Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?


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

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


From noreply@sourceforge.net  Tue Apr  2 21:27:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 13:27:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-535444 ] super() broken with classmethods
Message-ID: <E16sVoH-0002uf-00@usw-sf-web2.sourceforge.net>

Bugs item #535444, was opened at 2002-03-26 17:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535444&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Guido van Rossum (gvanrossum)
Summary: super() broken with classmethods

Initial Comment:
Using super() in a classmethod breaks in Python 2.2. 
Apparently, when super looks up an attribute from the
__mro__ sequence, it calls the found descriptor's
__get__ with the descriptor itself as the 'type'
argument, which breaks horribly with class methods
(which always binds to the type argument).

Presumably, the fix is to pass a NULL type argument,
which should work with the recent fixes to the
classmethod's __get__ logic.  In other words, this code
in the super_getattro function Objects/typeobject.c:

tmp = f(res, su->obj, res);

should probably actually read:

tmp = f(res, su->obj, NULL);



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-02 16:27

Message:
Logged In: YES 
user_id=6380

I should probably mention that I checked in Phillip's patch
537536, closing this issue.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 15:50

Message:
Logged In: YES 
user_id=6656

OK, you've found the right place, good.

The bug/patch guidlines are probably confusing because, 
unless you're part of the Python project I think you can't 
attach a file to a report you didn't submit.  Generally I 
prefer patches to be attached to bugs, but that's just my 
opinion, I don't know what other developers think.  I also 
think the whole bug/patch division is misguided, but that's 
another rant entirely.

I think you're doing fine!  Now we just wait for Guido to 
stop changing nappies :)


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

Comment By: Phillip J. Eby (pje)
Date: 2002-04-01 14:46

Message:
Logged In: YES 
user_id=56214

I was indeed just asking where to put it, and how to
*insert* the test.  Anyway, I found that most of what was
needed for the test was already in
test_descr.classmethods(), there were just a few conditions
using super() that needed adding.  I've uploaded the patch
for test_descr to the patch #537536 for this bug.

By the way, the bug/patch submission guidelines were a
little unclear to me; specifically whether I was supposed to
put the patch with the bug or the bug with the patch or
upload everything to both or what.  Hope my ignorance hasn't
inconvenienced anyone; this is my first time submitting
Python bugs and fixes.  Also, I hadn't worked with the test
framework used in Python's test suite before, although I've
done quite a bit with unittest in my own code.


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

Comment By: Michael Hudson (mwh)
Date: 2002-04-01 04:36

Message:
Logged In: YES 
user_id=6656

Assign to Guido.

Bearing in mind that I haven't even tried to understand this 
bug, the fact that you can't come up with a test case stands 
against you... if you're just asking where to put it, stick 
it in test_descr.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-31 18:17

Message:
Logged In: YES 
user_id=56214

Patch #537536 submitted to fix this.  "make test" output is
same as before the patch.  If someone can give me an idea of
where/how to insert a regression test for the bug being
fixed, I'll submit a patch for that, too.  Thanks.


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

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 15:19

Message:
Logged In: YES 
user_id=6656

Unless someone can come up with a obviously correct patch 
(and convince Guido that it's obviously correct) very soon, 
this isn't going to go into 2.2.1.


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 08:38

Message:
Logged In: YES 
user_id=56214

Ugh.  I just realized that my "presumable fix" is actually
wrong.  I checked back on my "Python super" workaround, and
realized I modified Guido's example slightly, to call
__get__(self.__obj__,starttype), instead of
__get__(self.__obj__).  This implies that the fix to
super_getattro is a little more complicated, since
super_getattro doesn't have a C variable equivalent to
starttype in the Python version of super.  :(


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

Comment By: Phillip J. Eby (pje)
Date: 2002-03-27 08:06

Message:
Logged In: YES 
user_id=56214

class cm1(object):
    def cmm(klass):
        print klass
    cmm = classmethod(cmm)

class cm2(cm1):
    def cmm(klass):
        super(cm2,klass).cmm()
    cmm = classmethod(cmm)

cm2.cmm()

The above code prints "<classmethod object at 0x00A9B930>",
demonstrating that super(cm2,klass).cmm is bound improperly.
 (It should print <class '__main__.cm2'>, analagous to how
calling cm1.cmm() directly prints <class '__main__.cm1'>.) 
You can more specifically verify this like so:

>>> cm1.cmm.im_self
<class '__main__.cm1'>
>>> cm2.cmm.im_self
<class '__main__.cm2'>
>>> super(cm2,cm2).cmm.im_self
<classmethod object at 0x00A9B930>
>>> 

The last item's im_self should of course be <class
'__main__.cm2'>.  As I said, the problem is that
super_getattro incorrectly asks the classmethod descriptor
to bind to *itself*, rather than to a type.

Note that if you use the pure Python example version of
"super" defined in the python.org/2.2/descrintro.html
document, the above examples work correctly as long as you
use a version of Python that has the "classmethod core dump"
problem fixed.  However, the builtin super() never works
correctly for classmethods, whether the "classmethod core
dump" is fixed or not.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:26

Message:
Logged In: YES 
user_id=21627

Can you give an example of how to break it? Please also
report what your example does when you run it.

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

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


From noreply@sourceforge.net  Wed Apr  3 01:33:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 17:33:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-524600 ] posixmodule.c fails Tru64 (stat macro)
Message-ID: <E16sZe5-0008W4-00@usw-sf-web3.sourceforge.net>

Bugs item #524600, was opened at 2002-03-01 17:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524600&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Mike Coleman (mkc)
Assigned to: Nobody/Anonymous (nobody)
Summary: posixmodule.c fails Tru64 (stat macro)

Initial Comment:
posixmodule.c won't compile under Tru64 5.1 (gcc 3.0.3)
because the code assumes that 'stat'/'lstat'/'fstat'
are functions, but under Tru64 5.1 they are macros.



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

>Comment By: Mike Coleman (mkc)
Date: 2002-04-02 19:33

Message:
Logged In: YES 
user_id=555

It sounds like a gcc guy is working on a fix for this,
probably for 3.1.  (It's an implementation of that pragma
plus a fixincludes change.)

This fix should work around the underlying Compaq bug.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-02 11:30

Message:
Logged In: YES 
user_id=21627

So what is the difference between the old and the new stat
structure? Defining __V40_OBJ_COMPAT seems wrong to me; I
assume you want to use the new stat structure, and you do
want to call the F64 functions. If the compiler does not
support that scenario, it's a compiler bug.

patmiller's comment offers a work-around, though: putting
__V40_OBJ_COMPAT into CFLAGS (and probably OPT as well)
should allow compilation to succeed.

Closing as 'won't fix'.

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

Comment By: Patrick Miller (patmiller)
Date: 2002-04-02 11:14

Message:
Logged In: YES 
user_id=30074

>From my reading of the header, we need to

#ifdef STUPID_TRU64_STAT_MACROS
#define __V40_OBJ_COMPAT
#endif
#include "sys/stat.h"

When you do that, the include looks like....
% cpp  -D__V40_OBJ_COMPAT /usr/include/sys/stat.h | fgrep
stat
  struct stat {
  extern int stat ();
  extern int fstat ();
    extern int lstat ();
(some of above lines removed for readability)


Here's the scoop from stat.h

/*
 * Define the function prototypes for stat, fstat and
lstat.  The __(())
 * MACRO is use to control whether ANSI C or K&R style
function prototypes
 * are declared.
 *
 * The normal path will have __EXTERN_PREFIX defined, no
wrapper function
 * MACROs for stat, fstat, or lstat will exist, and the
__F64_XXX__() MACROs
 * will all be no-ops.  This will result in declaring
function prototypes
 * for _F64_stat, _F64_fstat, and _F64_lstat, and all
function calls to
 * stat, fstat, and lstat in the module will be
transparently renamed to the
 * _F64_xxx variant.
 *
 * If a compiler other than DECC is being used then, the
__F64_XXX__()
 * MACROs will perform the function renaming.
 *
 * If the program has created its own wrapper function
MACROs to rename one
 * of the stat, fstat, or lstat functions, then that
function will be
 * declared using the name provided by the program's MACRO. 
The wrapper
 * function prototypes are declared using the new stat
structure (Wrappers
 * that want the old stat structure should be compiled with
 * __V40_OBJ_COMPAT).
 *
 * Finally if either __V40_OBJ_COMPAT is defined, XPG4
standard compliance
 * has been requested, or ISO C or ANSI C standard
compliance has been
 * requested, then the function prototypes will be declared
using the names
 * stat, fstat, and lstat (no function renaming will
occur).  Calls to these
 * functions will return the old stat structure.
 *
 * Again, please do not write programs that directly call
_F64_xxx named
 * fucntions.  Use the standard stat, fstat, and lstat
function names and
 * allow this header file to perform the necessary renaming
as part of the
 * compile.  That way the program will remain portable.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-31 05:31

Message:
Logged In: YES 
user_id=21627

Then this *is* a gcc issue. First, gcc does not implement
the pragma, but should (I just added support for the SunPRO
pragma redefine_extname to gcc for precisely the same
reason: Sun also renames LFS functions). If the #ifdef
really is for DECC, then it is doubtful, though, whether gcc
should define DECC even if it supports the pragma.

It is questionable whose problem this is, but I doubt Compaq
will care much about breakage occurring only with a
third-party compiler. GCC has a strategy for this, so it is
a gcc bug that this strategy is not applied: fixincludes.
GCC produces shadow copies of the system headers to correct
all kinds of problems. It should apply such fixing also to
these headers.

For the specific case, it would probably be sufficient to
change the #define line to

#define stat __F64_stat

Then, taking an address of stat will take the address of
__F64_stat. Better yet, the fixed header files should use
the GCC equivalent of the DECC pragma:

int stat(char*, struct stat*)
  __attribute__((alias("__F64_stat");

Adding this to fixincludes will be a challenge, though; for
Sun, we decided that it is easier to implement the Sun
pragma (especially as it was protected with an #ifdef
__PRAGMA_REDEFINE_EXTNAME, so gcc does not need to claim
being SUNC).

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-30 23:38

Message:
Logged In: YES 
user_id=555

I don't have the code at hand, but it looks something like this:

#ifdef DECC
#pragma something_that_maps_stat_to__F64_stat
#else
#define stat(...) __F64_stat(...)
#endif

I'm quite confident it's not a gcc issue, except in that any
merely standards-compliant compiler would fail here.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-30 02:47

Message:
Logged In: YES 
user_id=21627

So where is the magic that redirects stat to _F64_stat? It
would be ok if there was no stat prototype, under the
'as-if' rule: If that magic behaved as if there was a stat
prototype (i.e. allowing to take the address of stat), then
there would be no problem.

Could it be that this is gcc related? I know that users have
successfully built Python 2.x on Tru64 5.x, probably using
the system compiler. So it might be that gcc has bogus
headers, or is missing a feature that it needs to work
correctly on that machine.

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

Comment By: Mike Coleman (mkc)
Date: 2002-03-29 21:28

Message:
Logged In: YES 
user_id=555

re patmiller: so, that means the Compaq behavior definitely
violates the standard, correct?

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

Comment By: Patrick Miller (patmiller)
Date: 2002-03-29 16:58

Message:
Logged In: YES 
user_id=30074

% cpp /usr/include/sys/stat.h | grep stat
if you look at what is REALLY defined in stat.h in tru64 5.1
you see that there isn't a "extern int stat(...)", just
the bogusified versions of "extern int _F64_stat()"

% cpp /usr/include/sys/stat.h | grep stat
# 1 "/usr/include/sys/stat.h"
# 53 "/usr/include/sys/stat.h"
    unsigned int        __state;
    long        __state;
# 54 "/usr/include/sys/stat.h"
# 55 "/usr/include/sys/stat.h"
  struct stat {
  extern int _F64_stat ();
  extern int _F64_fstat ();
    extern int _F64_lstat ();

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-29 03:19

Message:
Logged In: YES 
user_id=21627

Section 7.1.4 (use of library functions) of the C standard
(C99) says

#  Each  of  the  following  statements  applies   unless 
# explicitly  stated  otherwise  in  the detailed 
# descriptions that follow: ...
# Any function declared in a header may be additionally
# implemented as a function-like  macro  defined in the
# header, so if a library function is declared explicitly
# when its header is included, one  of the techniques shown
# below can be used to ensure the declaration is not
# affected by  such  a  macro.   Any  macro definition of
# a function can be suppressed locally by enclosing the
# name of the function in parentheses, because the name is
# then not followed by the left parenthesis that indicates
# expansion of a macro function name.  For the same
# syntactic reason, it is permitted to take the address of
# a library function even if it is also defined as a macro.
Posix extends the C standard to additional functions, so the
same rule applies to stat as well (sorry, I don't have the
precise wording for that). Therefore, taking the address of
stat is clearly supported.


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

Comment By: Mike Coleman (mkc)
Date: 2002-03-27 18:02

Message:
Logged In: YES 
user_id=555

The precise error is

Modules/posixmodule.c: In function `posix_stat':
Modules/posixmodule.c:1310: `stat' undeclared (first use in this function)

According to the contents and comments in /usr/include/sys/stat.h,
DEC is playing some #pragma trick in the case that the DEC C
compiler is in use, which maps stat to __F64_stat, and apparently defining only the macros
when a non-DEC compiler is in use.

I don't have a POSIX standard--can you give me a cite I can
take to DEC?


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-03 15:47

Message:
Logged In: YES 
user_id=21627

Can you report how precisely this fails?

The Posix and C standards give the system permission to
define library functions as macros (and Python has no
problem with that) as long as the library *also* defines
them as functions, so you can their address. I doubt that
the Tru64 authors are unaware of this rule, or knowingly
ignore it, so the tru cause must be something else.

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

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


From noreply@sourceforge.net  Wed Apr  3 01:53:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 17:53:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-226766 ] popen('python -c"...."') tends to hang
Message-ID: <E16sZxv-0005yA-00@usw-sf-web2.sourceforge.net>

Bugs item #226766, was opened at 2000-12-25 03:08
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=226766&group_id=5470

Category: Windows
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: michal wallace (sabren)
Assigned to: Mark Hammond (mhammond)
>Summary: popen('python -c"...."') tends to hang

Initial Comment:
eg:

import os
os.popen('python -c"x=1;print x"').readlines()


.. On my machine, using popen to call a second instance of python almost always causes python to freeze. No window pops up, but if I press alt-tab, there's an icon for w9xpopen.exe

oddly:


>>> os.popen('python -c"print"').readlines()

and

>> os.popen('python -c""').readlines()

both work fine.


... This bug is different from #114780 in that it is repeatable and consistent.

It happens on open, so is different from #125891. Eg:

>>> proc = os.popen('python -c"x=1; print x"')

will cause the crash.

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

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-03 11:53

Message:
Logged In: YES 
user_id=14198

Dupe of bug 457466.

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

Comment By: Robert Amesz (rcamesz)
Date: 2001-09-25 09:20

Message:
Logged In: YES 
user_id=313190

Ah, well, it would seem that this is in fact the same bug I 
reported much later as #457466: "popenx() argument mangling 
hangs python". For some reason I overlooked it when posting 
my report, otherwise I'd have added my comments here. Sorry 
to add to the confusion. If you need to work around this bug 
(it's basically a bug in the commandline parsing), my report 
has information on that, as wel as a possible way of fixing 
it.

My patched version of popen9x.exe does not hang on Win98, 
but 
'reports' the error (reformatted to fit the margins):

Python 2.1.1 (#20, Jul 20 2001, 01:19:29) [MSC 32 bit 
(Intel)] on win32 Type "copyright", "credits" or "license" 
for more information.
>>> import os
>>> os.popen('python -c"x=1;print x"').read()
"ARGUMENT PARSE ERROR\nThe way double quotes and spaces were 
used\ncaused popenx () to split the commandline.\n\nArgument 
count = 3\nArgument 0 = 
'C:\PYTHON21\w9xpopen.exe'\nArgument 1 = 'C:\COMMAND.COM 
/c python -cx=1;print'\nArgument 2 = 'x'\n"
>>>

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

Comment By: Nobody/Anonymous (nobody)
Date: 2000-12-29 22:29

Message:
um.....

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

Comment By: Mark Hammond (mhammond)
Date: 2000-12-29 10:34

Message:
I have done lots of playing with this over the last month or so.  The problem appears to be something to do with "python.exe" used as the target of such a popen command.  (Ironically, we tried to use popen to capture remote Python invocations for Komodo - as I guess you are for IDLE)

I have experimented with 3 "different" popen implementations: Python's, one written in Python using the win32 API directly, and one using the Netscape NSPR libraries.  They all, however, end up doing the same basic thing with the same basic Windows API functions.  They all behace the same WRT reading input.

Python.exe (and one or 2 other exes) appear to hang when they are in an "interactive loop", and the spawning process is trying to read the input pipe.  My experiements at breaking into the debugger shows Windows blocked inside the ReadFile() function.

Note that Perl.exe does _not_ appear to provoke this (but Perl doesnt have a builtin interactive loop, so is harder to prove).  Also note that "cmd.exe" also does _not_ provoke this - ie, both Perl.exe and cmd.exe both work fine, correctly reading and writing either pipe when the process is "interactive"

So - after all this, my best guess was that there is something weird in the stdio Python uses to read stdin, and that Perl and cmd.exe both avoid this.  Random, 100% speculative guess is that the "/MD" stdio is broken, but others wont be.

This is as far as I got - I was going to experiment with /MD, other input techniques etc, but never got to it.  It should be simple to reproduce with a simple test .exe, but alas never got to that either.  I should have more time over the next few weeks.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-29 02:47

Message:
Any chance you have Norton AntiVirus 2000 running?

See http://sourceforge.net/bugs/?group_id=5470&func=detailbug&bug_id=114598

I've basically given up on popen for windows. :-(

os.spawn*() works great though -- if you don't need to read the output. :-)

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

Comment By: Tim Peters (tim_one)
Date: 2000-12-25 04:40

Message:
Mark, any idea?  The first example also appears to hang for me consistently (W98SE).  In a debug build under the debugger, breaking during the hang yields a gibberish disassembly window (i.e., it's not showing code!), so I didn't get anywhere after 5 minutes of thrashing.

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

Comment By: michal wallace (sabren)
Date: 2000-12-25 03:11

Message:
.. er.. whoops.. It hangs/freezes, not crashes. And in fact, it occasionally returns control to python after several minutes.

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

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


From noreply@sourceforge.net  Wed Apr  3 02:06:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 18:06:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-228685 ] popen on Win9x isnt smart enough about finding w9xpopen.exe
Message-ID: <E16saAq-0000LU-00@usw-sf-web4.sourceforge.net>

Bugs item #228685, was opened at 2001-01-14 06:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=228685&group_id=5470

Category: Extension Modules
Group: Platform-specific
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: popen on Win9x isnt smart enough about finding w9xpopen.exe

Initial Comment:
The code in posixmodule that emulates popen*() isnt very smart about locating the .exe for the Win9x popen hacks.  It assumes that w9xpopen.exe can be located in the directory of the main executable, which fails in may embedding situations.

A reasonable fix would be to also attempt to locate the file in the "sys.prefix" directory - typically this will be set correctly.

Im not at my main dev machine, hence I am submitting a bug rather than a patch.  I will submit a patch ASAP.

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

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-03 12:06

Message:
Logged In: YES 
user_id=14198

I am fairly certain that this bug is correctly fixed.  
test_popen and test_popen2 both now correctly work in 
embedded situations (such as pythonwin) - they always did 
work from python.exe (as python.exe and w9xpopen.exe were 
in the same directory)

Closing (hopefully for good :)

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

Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-11 05:50

Message:
Logged In: NO 

I discovered something related to this bug yesterday, while 
experimenting with popen using ActivePython 2.1.1.212 on a 
Win98SE box.

The test code was this (I'm new to python, please forgive 
any silly things you can find in it :-))

from os import popen2

def getoutput(cmd):
	i,o=popen2(cmd)
	result=[]
	l=o.readline()
	while l:
		result.append(l)
		l=o.readline()
	return "\n".join(result)
	o.close()
	i.close()

If I start python from a directory other than install dir 
(e:\python21\ on my box) then:
- the test code hangs on "l=o.readline"
- A short sound is played when the code is run
- a w9xpopen task is shown in task list, after I quit the 
hanged python using CTRL-BREAK
- the system hangs after trying to run test code several 
times (5 to 7)

If I start python from its install dir, everything works 
fine.

It must be noted that if I start python from its install 
dir, run the test code, quit python, change the working 
dir, restart python and run test code, then it works fine. 
Looks like w9xpopen remains in memory even if python is 
quit and then restarted from a different dir: well, I don't 
think it really stays in memory, but it looks like it stays 
there :-)



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

Comment By: Mark Hammond (mhammond)
Date: 2001-09-12 08:41

Message:
Logged In: YES 
user_id=14198

You will see the problem if w9xpopen.exe can not be found 
either in:
* the directory of the executable
* the sys.prefix directory.

In a build environment, you will have problems if you run 
an executable from *outside* the pcbuild directory (eg 
pythonwin.exe, or a copy of python.exe copied elsewhere)

In a pre-installed Python, this scenario ('external' .exe) 
should work correctly.

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

Comment By: Tim Peters (tim_one)
Date: 2001-09-12 02:22

Message:
Logged In: YES 
user_id=31435

Mark, I haven't noticed any differences in the behavior of 
test_popen2 on Win98SE, whether from an installed Python or 
from PCBuild.  Did you expect something to break in the 
latter case?  It doesn't for me.  You can test it yourself 
on Win2K by setting COMSPEC to point to command.com (in 
which case a recent patch makes Python use w9xpopen.exe 
even on NT/2000).

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

Comment By: Mark Hammond (mhammond)
Date: 2001-09-11 22:37

Message:
Logged In: YES 
user_id=14198

oops - meant "now that sys.prefix is always set 
correctly." in the last entry.

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

Comment By: Mark Hammond (mhammond)
Date: 2001-09-11 22:26

Message:
Logged In: YES 
user_id=14198

I consider this bug fixed, now that sys.path is always set 
correctly.  Code already in the popen() implementation will 
attempt to locate w9xopen.exe in sys.prefix, which will be 
correct in all "installed" Pythons.

Note that this does not work in a build python - sys.prefix 
points to the top-level Python source directory, while the 
executables are in ".\pcbuild".  I don't care enough to fix 
this, as I never test on win9x, and it can't bother Tim too 
much as he would have just screamed louder before now.

Leaving open until I test some more on a on installed 
versions on my w98 box.

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

Comment By: Mark Hammond (mhammond)
Date: 2001-09-11 22:25

Message:
Logged In: YES 
user_id=14198

I consider this bug fixed, now that sys.path is always set 
correctly.  Code already in the popen() implementation will 
attempt to locate w9xopen.exe in sys.prefix, which will be 
correct in all "installed" Pythons.

Note that this does not work in a build python - sys.prefix 
points to the top-level Python source directory, while the 
executables are in ".\pcbuild".  I don't care enough to fix 
this, as I never test on win9x, and it can't bother Tim too 
much as he would have just screamed louder before now.

Leaving open until I test some more on a on installed 
versions on my w98 box.

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

Comment By: Mark Hammond (mhammond)
Date: 2001-01-31 18:32

Message:
Partial fix checked in Rev 2.183 of Modules/posixmodule.c

As per the comments in that checkin, the code now tries sys.prefix, but in many embedded situations this is still NULL/empty.  As soon as source-force is accepting new bugs I will close this and open a new one for sys.prefix being empty in some conditions.

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

Comment By: Mark Hammond (mhammond)
Date: 2001-01-14 06:39

Message:
Giving to me!

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

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


From noreply@sourceforge.net  Wed Apr  3 06:04:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 02 Apr 2002 22:04:36 -0800
Subject: [Python-bugs-list] [ python-Bugs-538582 ] NTLM Authentication Using httplib
Message-ID: <E16sdsq-00032w-00@usw-sf-web4.sourceforge.net>

Bugs item #538582, was opened at 2002-04-03 01:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538582&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: NTLM Authentication Using httplib

Initial Comment:
Is there a way to use httplib to do NTLM 
authentication using the following URL format:

http://username:password@www.mydomain.com:80/start.py

???

If you attempt to do this it errors out (trying to 
make everything from ":password" over the port number).

Thank you in advance.

Keyton

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

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


From noreply@sourceforge.net  Wed Apr  3 09:34:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 01:34:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-460357 ] test_time fails on Sparc64
Message-ID: <E16sh9v-0002sh-00@usw-sf-web2.sourceforge.net>

Bugs item #460357, was opened at 2001-09-10 17:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L�wis (loewis)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_time fails on Sparc64

Initial Comment:
On Solaris8, with the WS6U1 compiler, after setting CC
to 'cc -xarch=v9', test_time.py fails with

  File "Lib/test/test_time.py", line 46, in test_mktime
    time.mktime, (999999, 999999, 999999, 999999,
  File
"/vol/marvin-vol8/loewis/python/dist/src/Lib/unittest.py",
line 273, in failUnlessRaises
    raise self.failureException, excName
AssertionError: OverflowError

The problem is that the test doesn't overflow. Instead,
it gives the value 34214554704339.0.

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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:34

Message:
Logged In: YES 
user_id=21627

This was reported for alpha as well, as #538369.

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

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


From noreply@sourceforge.net  Wed Apr  3 09:39:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 01:39:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-460357 ] test_time fails on Sparc64
Message-ID: <E16shEk-0002hY-00@usw-sf-web1.sourceforge.net>

Bugs item #460357, was opened at 2001-09-10 17:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L�wis (loewis)
>Assigned to: Barry Warsaw (bwarsaw)
Summary: test_time fails on Sparc64

Initial Comment:
On Solaris8, with the WS6U1 compiler, after setting CC
to 'cc -xarch=v9', test_time.py fails with

  File "Lib/test/test_time.py", line 46, in test_mktime
    time.mktime, (999999, 999999, 999999, 999999,
  File
"/vol/marvin-vol8/loewis/python/dist/src/Lib/unittest.py",
line 273, in failUnlessRaises
    raise self.failureException, excName
AssertionError: OverflowError

The problem is that the test doesn't overflow. Instead,
it gives the value 34214554704339.0.

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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:39

Message:
Logged In: YES 
user_id=21627

Assigned to Barry, since Tim assigned #538369 to Barry.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:34

Message:
Logged In: YES 
user_id=21627

This was reported for alpha as well, as #538369.

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

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


From noreply@sourceforge.net  Wed Apr  3 09:39:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 01:39:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-538369 ] time.mktime() doesn't raise exception
Message-ID: <E16shEs-0002he-00@usw-sf-web1.sourceforge.net>

Bugs item #538369, was opened at 2002-04-02 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538369&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Duplicate
Priority: 7
Submitted By: Mike Carifio (carifio)
Assigned to: Barry Warsaw (bwarsaw)
Summary: time.mktime() doesn't raise exception

Initial Comment:
RH 6.2/alpha, egcs-2.91 , python 2.2.1c2:

import time
time.mktime((999999,)*9)

should raise and exception. It doesn't.
This is similar to bug 460357, where this
occurs on Sparc64.


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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:39

Message:
Logged In: YES 
user_id=21627

This is a duplicate of #460357, so closing it as such.

This is not a serious problem; the test verifies that mktime
does not attempt to represent a date that is unrepresentable
(in a time_t). It turns out that the date selected is indeed
representable in a time_t on 64bit architectures, but not on
32-bit architectures.

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

Comment By: Tim Peters (tim_one)
Date: 2002-04-02 21:44

Message:
Logged In: YES 
user_id=31435

Assigned to Barry and boosted priority -- please fix this 
in a way you can live with.  Neither C nor POSIX define the 
range of time_t, and test_time's belief that test_mktime() 
*should* raise OverflowError seems pure assumption to me.

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 20:49

Message:
Logged In: YES 
user_id=6656

Well, I don't know what mktime should do either :-/

Yes, there's a bug here.  Tests shouldn't fail on 64bit 
platforms (the same thing happens on IA64, too).  I don't 
know the issues well enough to fix it myself, though.


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

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 20:45

Message:
Logged In: YES 
user_id=503643

I guess I misunderstood the spec on time.mktime().
I was under the impression that if one of the
slots in the tuple, like seconds, was out of range,
then it should raise an exception. It doesn't and
it doesn't do it on RH7.1/i386/python 2.2 or
Win2k/i386/python 2.2.

But, in my defense, test_time says it *should* raise
an exception. Which is where I started. 

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

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 20:36

Message:
Logged In: YES 
user_id=6656

Why should it?  Isn't this just a bug in the test?  (Not 
rhetorical questions!)


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

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


From noreply@sourceforge.net  Wed Apr  3 09:41:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 01:41:37 -0800
Subject: [Python-bugs-list] [ python-Bugs-538582 ] NTLM Authentication Using httplib
Message-ID: <E16shGr-0005j7-00@usw-sf-web3.sourceforge.net>

Bugs item #538582, was opened at 2002-04-03 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538582&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: NTLM Authentication Using httplib

Initial Comment:
Is there a way to use httplib to do NTLM 
authentication using the following URL format:

http://username:password@www.mydomain.com:80/start.py

???

If you attempt to do this it errors out (trying to 
make everything from ":password" over the port number).

Thank you in advance.

Keyton

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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:41

Message:
Logged In: YES 
user_id=21627

What is NTLM? What is the bug you are reporting?

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

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


From noreply@sourceforge.net  Wed Apr  3 12:39:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 04:39:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-538582 ] NTLM Authentication Using httplib
Message-ID: <E16sk3P-00058Y-00@usw-sf-web2.sourceforge.net>

Bugs item #538582, was opened at 2002-04-03 01:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538582&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: NTLM Authentication Using httplib

Initial Comment:
Is there a way to use httplib to do NTLM 
authentication using the following URL format:

http://username:password@www.mydomain.com:80/start.py

???

If you attempt to do this it errors out (trying to 
make everything from ":password" over the port number).

Thank you in advance.

Keyton

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

>Comment By: Keyton Weissinger (keytonw)
Date: 2002-04-03 07:39

Message:
Logged In: YES 
user_id=396481

NTLM is the Windows NT authentication scheme for web 
applications. It is what triggers the 
domain/username/password input box that springs up on 
secure NT-based web applications.

To avoid the pop-up, people use a URL in the following 
format:

http://username:password@www.mydomain.com:80/myPage.htm

The bug:

When I enter a host string that looks like the above, the 
httplib code tries to make:

:password@www.mydomain.com:80/myPage.htm

into a port number and fails because it cannot convert the 
above to an integer.

That is the bug, but my guess is that there is more to it 
than that. 

The bigger question may be: Can I use httplib to 
authenticate into a secure NT-based web application?

Thank you!

Keyton

P.S. Here is a link to some more information. If it turns 
out to be a feature request and one you are interested in, 
I would be happy to help:

http://squid.sourceforge.net/ntlm/faq.html

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 04:41

Message:
Logged In: YES 
user_id=21627

What is NTLM? What is the bug you are reporting?

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

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


From noreply@sourceforge.net  Wed Apr  3 17:01:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 09:01:55 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-538582 ] NTLM Authentication Using httplib
Message-ID: <E16so8x-0008Np-00@usw-sf-web2.sourceforge.net>

Feature Requests item #538582, was opened at 2002-04-03 08:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=538582&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Keyton Weissinger (keytonw)
Assigned to: Nobody/Anonymous (nobody)
Summary: NTLM Authentication Using httplib

Initial Comment:
Is there a way to use httplib to do NTLM 
authentication using the following URL format:

http://username:password@www.mydomain.com:80/start.py

???

If you attempt to do this it errors out (trying to 
make everything from ":password" over the port number).

Thank you in advance.

Keyton

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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 19:01

Message:
Logged In: YES 
user_id=21627

Python does not support NTLM authentication; so this sounds
like a feature request (reclassifying it as such). urllib
supports Basic authentication.

I'm still not sure what you did  that was incorrectly
interpreted as a port number. Can you please provide a
precise sequence of Python statements, and report what the
precise error message is that you get?

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

Comment By: Keyton Weissinger (keytonw)
Date: 2002-04-03 14:39

Message:
Logged In: YES 
user_id=396481

NTLM is the Windows NT authentication scheme for web 
applications. It is what triggers the 
domain/username/password input box that springs up on 
secure NT-based web applications.

To avoid the pop-up, people use a URL in the following 
format:

http://username:password@www.mydomain.com:80/myPage.htm

The bug:

When I enter a host string that looks like the above, the 
httplib code tries to make:

:password@www.mydomain.com:80/myPage.htm

into a port number and fails because it cannot convert the 
above to an integer.

That is the bug, but my guess is that there is more to it 
than that. 

The bigger question may be: Can I use httplib to 
authenticate into a secure NT-based web application?

Thank you!

Keyton

P.S. Here is a link to some more information. If it turns 
out to be a feature request and one you are interested in, 
I would be happy to help:

http://squid.sourceforge.net/ntlm/faq.html

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:41

Message:
Logged In: YES 
user_id=21627

What is NTLM? What is the bug you are reporting?

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

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



From noreply@sourceforge.net  Wed Apr  3 17:10:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 09:10:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-538827 ] Python open w/ MSVC6: bad error msgs
Message-ID: <E16soHd-0002hN-00@usw-sf-web4.sourceforge.net>

Bugs item #538827, was opened at 2002-04-03 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python open w/ MSVC6: bad error msgs

Initial Comment:
With the current Win32 build (actually, 2.2.1c1), you 
get the following behavior when feeding bad filenames 
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error 
ERROR_INVALID_NAME to EINVAL, and Python always treats 
this error as being related to the mode string.  It 
appears (from bug report 476593) that VC6 disagrees 
with GCC here; I don't know which compiler is right 
(actually, looking at the VC documentation for _open, 
it appears GCC is right).  At any rate, it appears 
Python cannot rely on EINVAL referring only to the 
mode string under Windows.

Interestingly, the current Python Win32 build also 
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen 
fails, but it does not set errno.  (You can see this 
in the openfile function in _OPEN.C in the VC6 CRT 
source).  It might be possible to use this behavior to 
produce more accurate error messages under Windows.



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

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



From noreply@sourceforge.net  Wed Apr  3 17:15:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 09:15:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-538827 ] Python open w/ MSVC6: bad error msgs
Message-ID: <E16soLf-0008HZ-00@usw-sf-web1.sourceforge.net>

Bugs item #538827, was opened at 2002-04-03 17:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Tim Peters (tim_one)
Summary: Python open w/ MSVC6: bad error msgs

Initial Comment:
With the current Win32 build (actually, 2.2.1c1), you 
get the following behavior when feeding bad filenames 
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error 
ERROR_INVALID_NAME to EINVAL, and Python always treats 
this error as being related to the mode string.  It 
appears (from bug report 476593) that VC6 disagrees 
with GCC here; I don't know which compiler is right 
(actually, looking at the VC documentation for _open, 
it appears GCC is right).  At any rate, it appears 
Python cannot rely on EINVAL referring only to the 
mode string under Windows.

Interestingly, the current Python Win32 build also 
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen 
fails, but it does not set errno.  (You can see this 
in the openfile function in _OPEN.C in the VC6 CRT 
source).  It might be possible to use this behavior to 
produce more accurate error messages under Windows.



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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-03 17:15

Message:
Logged In: YES 
user_id=6656

Guess who gets to look at this one.


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

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



From noreply@sourceforge.net  Wed Apr  3 19:27:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 11:27:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-460357 ] test_time fails on Sparc64
Message-ID: <E16sqPz-0004XC-00@usw-sf-web3.sourceforge.net>

Bugs item #460357, was opened at 2001-09-10 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470

Category: Extension Modules
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Martin v. L�wis (loewis)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_time fails on Sparc64

Initial Comment:
On Solaris8, with the WS6U1 compiler, after setting CC
to 'cc -xarch=v9', test_time.py fails with

  File "Lib/test/test_time.py", line 46, in test_mktime
    time.mktime, (999999, 999999, 999999, 999999,
  File
"/vol/marvin-vol8/loewis/python/dist/src/Lib/unittest.py",
line 273, in failUnlessRaises
    raise self.failureException, excName
AssertionError: OverflowError

The problem is that the test doesn't overflow. Instead,
it gives the value 34214554704339.0.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-03 14:27

Message:
Logged In: YES 
user_id=31435

Raised priority and changed Group to 2.2.1 candidate.  We 
can't assume that time_t is too feeble to represent the 
date being tested, and Barry should rework the test so that 
it doesn't fail on 64-bit boxes (I recall that he wanted to 
test *something* here for Mailman's purposes, so it's up to 
him to figure out what he really wants -- testing that the 
platform has a feeble time_t ain't it).

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 04:39

Message:
Logged In: YES 
user_id=21627

Assigned to Barry, since Tim assigned #538369 to Barry.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 04:34

Message:
Logged In: YES 
user_id=21627

This was reported for alpha as well, as #538369.

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

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



From noreply@sourceforge.net  Wed Apr  3 22:02:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 14:02:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-538961 ] Using the lib index mechanically
Message-ID: <E16sspl-0003PB-00@usw-sf-web1.sourceforge.net>

Bugs item #538961, was opened at 2002-04-04 00:02
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538961&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Using the lib index mechanically

Initial Comment:
If the HTML version of the index to the library documentation (http://www.python.org/doc/current/lib/genindex.html in the online version) would contain <A NAME="foo"> anchors at the first entry for the word "foo" in the index this would allow a really nice feature in the IDE (and IDLE, and other ide's): a command "lookup in documentation" that takes the current selection and sends your webbrowser to genindex.html#foo.

Or is there already another way to do this?

An alternative (more work, but would allow more features) would be to dump the information that is in the index in an XML file. During the index generation process there's probably more interesting info available too. And it would allow to search the indexes of multiple docsets at once (library, refmanual, etc).

I'm posting this as a feature request because I haven't even the beginning of an idea how to implement this (in all those years I haven't even succeeded in _building_ the documentation:-).

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

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



From noreply@sourceforge.net  Wed Apr  3 23:17:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 15:17:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-538991 ] error in turtle.py - module
Message-ID: <E16su0Y-0007Co-00@usw-sf-web4.sourceforge.net>

Bugs item #538991, was opened at 2002-04-04 01:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538991&group_id=5470

Category: Tkinter
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in turtle.py - module

Initial Comment:
When trying to use the RawPen-class of turtle.py,
the following error occurs:

Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license" for more
information.
IDLE 0.8 -- press F1 for help
>>> from Tkinter import *
>>> import turtle
>>> root = Tk()
>>> c = Canvas(root)
>>> c.pack()
>>> t = turtle.RawPen(c)
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    t = turtle.RawPen(c)
  File "C:\Python221c\lib\lib-tk\turtle.py", line 16,
in __init__
    self.reset()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 42,
in reset
    self.clear()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 53,
in clear
    self._draw_turtle()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 262,
in _draw_turtle
    self._arrow = _canvas.create_line(x-dx,y+dy,x,y,
AttributeError: 'NoneType' object has no attribute
'create_line'
>>> 

This can be fixed - I suppose - by correcting  line 262:

    self._arrow = self._canvas.create_line(x-dx, ...etc.



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

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



From noreply@sourceforge.net  Thu Apr  4 00:36:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 16:36:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-539024 ] broken link in array module doc
Message-ID: <E16svF8-00085A-00@usw-sf-web4.sourceforge.net>

Bugs item #539024, was opened at 2002-04-04 00:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539024&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken link in array module doc

Initial Comment:
The link to "The Numerical Python Manual" on the
2.2 doc page for the array module, pointing to
http://numpy.sourceforge.net/numdoc/HTML/numdoc.html
gets a 404 not found error.  The correct url is
http://numpy.sourceforge.net/numdoc/HTML/numdoc.htm
i.e. it has .htm instead of .html.

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

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



From noreply@sourceforge.net  Thu Apr  4 02:23:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 18:23:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-448351 ] coredump in selectmodule.c on Solaris 8
Message-ID: <E16swuU-0006HH-00@usw-sf-web1.sourceforge.net>

Bugs item #448351, was opened at 2001-08-06 04:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=448351&group_id=5470

Category: Extension Modules
>Group: 3rd Party
>Status: Closed
>Resolution: Works For Me
Priority: 7
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Tim Peters (tim_one)
Summary: coredump in selectmodule.c on Solaris 8

Initial Comment:
I get coredump if I run a small script with Python 2.0
on Solaris 8, compiled with Sun CC Forte 6.1 compiler
(64 bits). I suggest to run it more than once to
produce the error. Purify showed me that there are
reading and writings outside the stack boundary.  

The interesting part of the source:

Modules/selectmodule.c
.
.
static PyObject *
select_select(PyObject *self, PyObject *args)
{
#ifdef MS_WINDOWS
        /* This would be an awful lot of stack space on
Windows! */
        pylist *rfd2obj, *wfd2obj, *efd2obj;
#else
        pylist rfd2obj[FD_SETSIZE + 3];
        pylist wfd2obj[FD_SETSIZE + 3];
        pylist efd2obj[FD_SETSIZE + 3];
#endif
.
.
.
}

In our environment FD_SETSIZE is 65536 as defined in
sys/select.h (see
below). The allocated stack space in select_select is
3*sizeof(rfd2obj)*(FD_SETSIZE+3). It is more than
3Mbytes. The difference between the addresses of the
same variable in two
seperate threads is about 2Mbytes. Lets suppose char
*p1 = (char *)rfd2obj
in thread N and char *p2 = (char *)rfd2obj in thread N
+ 1, abs(p1-p2)
is about 2MB (dbx showed this). The stack is
overwritten between the threads. Is it possible that
the stack size is limited to 2 Mbytes per thread? We
fixed it as solved on Windows allocating these
variables on the heap.

Select.h from Solaris 8.

/usr/include/sys/select.h:
.
.
#ifndef FD_SETSIZE
#ifdef _LP64
#define FD_SETSIZE      65536
#else
#define FD_SETSIZE      1024
#endif  /* _LP64 */
.


From noreply@sourceforge.net  Thu Apr  4 03:53:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 19:53:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-539081 ] PyObject_AsReadBuffer doc error
Message-ID: <E16syJT-0001q5-00@usw-sf-web3.sourceforge.net>

Bugs item #539081, was opened at 2002-04-03 20:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539081&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Cazabon (madcow42)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyObject_AsReadBuffer doc error

Initial Comment:
The documentation for PyObject_AsReadBuffer (and 
others in that group, I suspect) seems to be incorrect.

It notes that PyObject_AsReadBuffer returns 1 on 
success, 0 on failure.  However, it returns 0 on 
success and -1 on failure.  

This is true for the current documentation on 
Python.org, as well as older versions.

Thanks!

(or, this could be treated as a bug in 
PyObject_AsReadBuffer itself, returning the wrong 
values... which is probably more accurate, so it is 
consistent with other functions in the C API.  
However, changing it's return value at this point 
would break a LOT of software)

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

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



From noreply@sourceforge.net  Thu Apr  4 04:23:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 20:23:00 -0800
Subject: [Python-bugs-list] [ python-Bugs-539081 ] PyObject_AsReadBuffer doc error
Message-ID: <E16sym4-00029P-00@usw-sf-web3.sourceforge.net>

Bugs item #539081, was opened at 2002-04-03 22:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539081&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kevin Cazabon (madcow42)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: PyObject_AsReadBuffer doc error

Initial Comment:
The documentation for PyObject_AsReadBuffer (and 
others in that group, I suspect) seems to be incorrect.

It notes that PyObject_AsReadBuffer returns 1 on 
success, 0 on failure.  However, it returns 0 on 
success and -1 on failure.  

This is true for the current documentation on 
Python.org, as well as older versions.

Thanks!

(or, this could be treated as a bug in 
PyObject_AsReadBuffer itself, returning the wrong 
values... which is probably more accurate, so it is 
consistent with other functions in the C API.  
However, changing it's return value at this point 
would break a LOT of software)

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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-03 23:23

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/api/abstract.tex revisions 1.11 and 1.8.6.3. 
Added the relevant PyObject_As*Buffer() descriptions to
Doc/api/api.tex revision 1.117.2.13 (for Python 2.1.3) as
well, since I'm making changes for these functions anyway.

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

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



From noreply@sourceforge.net  Thu Apr  4 04:50:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 20:50:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16szD4-0002TM-00@usw-sf-web3.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-03 23:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 17:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 05:07:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 21:07:03 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16szSh-0007yj-00@usw-sf-web1.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:07

Message:
Logged In: YES 
user_id=3066

Looking at the code, it's not quite so trivial as I'd
thought, but not entirely difficult either.  I started by
creating a locator that had a reference to the parser object
from xml.parser.expat, but that of course has references to
the ExpatParser, so the cycle still exists.

As long as we're trying to solve the problem for Python 2.1
and newer, though, we can use a locator object that has a
weakref to the ExpatParser object, thereby breaking the
cycle.  I like that.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-03 23:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 17:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 05:25:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 21:25:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16szkH-0002gL-00@usw-sf-web4.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:25

Message:
Logged In: YES 
user_id=3066

I've attached a patch.  I think this meets all the backward
compatibility requirements and is low-risk, and it removes
the circular reference.  So far I've only tested it against
the standard tests for Python 2.1.*; I'll try it tomorrow
with the sample test code, and think about a test that can
be added to the test suite.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:07

Message:
Logged In: YES 
user_id=3066

Looking at the code, it's not quite so trivial as I'd
thought, but not entirely difficult either.  I started by
creating a locator that had a reference to the parser object
from xml.parser.expat, but that of course has references to
the ExpatParser, so the cycle still exists.

As long as we're trying to solve the problem for Python 2.1
and newer, though, we can use a locator object that has a
weakref to the ExpatParser object, thereby breaking the
cycle.  I like that.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-03 23:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 17:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 05:35:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 21:35:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16sztq-0008UW-00@usw-sf-web2.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:35

Message:
Logged In: YES 
user_id=3066

I'll note that the patch is against the release21-maint
branch of Python, and I've only tried it there.  It may need
changes for more recent versions of Python, but that branch
appears most critical since we're looking at a 2.1.3 release
next week.

OK, enough.  I'm heading to bed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:25

Message:
Logged In: YES 
user_id=3066

I've attached a patch.  I think this meets all the backward
compatibility requirements and is low-risk, and it removes
the circular reference.  So far I've only tested it against
the standard tests for Python 2.1.*; I'll try it tomorrow
with the sample test code, and think about a test that can
be added to the test suite.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:07

Message:
Logged In: YES 
user_id=3066

Looking at the code, it's not quite so trivial as I'd
thought, but not entirely difficult either.  I started by
creating a locator that had a reference to the parser object
from xml.parser.expat, but that of course has references to
the ExpatParser, so the cycle still exists.

As long as we're trying to solve the problem for Python 2.1
and newer, though, we can use a locator object that has a
weakref to the ExpatParser object, thereby breaking the
cycle.  I like that.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-03 23:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 17:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 06:21:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 22:21:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16t0cT-0003Gm-00@usw-sf-web4.sourceforge.net>

Bugs item #535474, was opened at 2002-03-27 00:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 08:21

Message:
Logged In: YES 
user_id=21627

I think the problem is elsewhere. Danny's demo script
clearly is buggy; if you use the IncrementalParser
interface, you *must* invoke .close() at the end of the
parse run; else you get cyclic garbage.

The cyclic garbage collector will pick up that garbage; just
invoke gc.collect() after test1 and test2 to see all
TestParsers destroyed.

So I don't think any action on Python code is necessary as a
bug fix; if there are remaining problems, then they must be
in pyexpat.c. I'll investigate 2.52 and 2.54 as candidates
for backporting.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 07:35

Message:
Logged In: YES 
user_id=3066

I'll note that the patch is against the release21-maint
branch of Python, and I've only tried it there.  It may need
changes for more recent versions of Python, but that branch
appears most critical since we're looking at a 2.1.3 release
next week.

OK, enough.  I'm heading to bed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 07:25

Message:
Logged In: YES 
user_id=3066

I've attached a patch.  I think this meets all the backward
compatibility requirements and is low-risk, and it removes
the circular reference.  So far I've only tested it against
the standard tests for Python 2.1.*; I'll try it tomorrow
with the sample test code, and think about a test that can
be added to the test suite.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 07:07

Message:
Logged In: YES 
user_id=3066

Looking at the code, it's not quite so trivial as I'd
thought, but not entirely difficult either.  I started by
creating a locator that had a reference to the parser object
from xml.parser.expat, but that of course has references to
the ExpatParser, so the cycle still exists.

As long as we're trying to solve the problem for Python 2.1
and newer, though, we can use a locator object that has a
weakref to the ExpatParser object, thereby breaking the
cycle.  I like that.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 06:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 23:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 23:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 13:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 13:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 07:05:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 23:05:14 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16t1J4-0000rP-00@usw-sf-web1.sourceforge.net>

Bugs item #535474, was opened at 2002-03-27 00:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 09:05

Message:
Logged In: YES 
user_id=21627

Also, when parsing the large xml file: if you invoke
gc.collect() after each iteration, memory consumption will
go down, and not grow over time. The reason that GC does not
trigger automatically is that you allocate all the space
through strings. GC will be invoked after 1000 new container
objects have been allocated, but you exhaust the memory
before that - so either set the GC threshold down, or invoke
GC on your own.

For the specific application, it would be sufficient if
xml.sax.__init__.parse would invoke
parser.setContentHandler(None) after parsing has completed;
this should already break the cycle.

To solve the general problem, I like your suggestion of
using a separate locator.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 08:21

Message:
Logged In: YES 
user_id=21627

I think the problem is elsewhere. Danny's demo script
clearly is buggy; if you use the IncrementalParser
interface, you *must* invoke .close() at the end of the
parse run; else you get cyclic garbage.

The cyclic garbage collector will pick up that garbage; just
invoke gc.collect() after test1 and test2 to see all
TestParsers destroyed.

So I don't think any action on Python code is necessary as a
bug fix; if there are remaining problems, then they must be
in pyexpat.c. I'll investigate 2.52 and 2.54 as candidates
for backporting.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 07:35

Message:
Logged In: YES 
user_id=3066

I'll note that the patch is against the release21-maint
branch of Python, and I've only tried it there.  It may need
changes for more recent versions of Python, but that branch
appears most critical since we're looking at a 2.1.3 release
next week.

OK, enough.  I'm heading to bed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 07:25

Message:
Logged In: YES 
user_id=3066

I've attached a patch.  I think this meets all the backward
compatibility requirements and is low-risk, and it removes
the circular reference.  So far I've only tested it against
the standard tests for Python 2.1.*; I'll try it tomorrow
with the sample test code, and think about a test that can
be added to the test suite.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 07:07

Message:
Logged In: YES 
user_id=3066

Looking at the code, it's not quite so trivial as I'd
thought, but not entirely difficult either.  I started by
creating a locator that had a reference to the parser object
from xml.parser.expat, but that of course has references to
the ExpatParser, so the cycle still exists.

As long as we're trying to solve the problem for Python 2.1
and newer, though, we can use a locator object that has a
weakref to the ExpatParser object, thereby breaking the
cycle.  I like that.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 06:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 23:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 23:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 13:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 13:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 07:07:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 23:07:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-538991 ] error in turtle.py - module
Message-ID: <E16t1Ks-0000sz-00@usw-sf-web1.sourceforge.net>

Bugs item #538991, was opened at 2002-04-04 01:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538991&group_id=5470

Category: Tkinter
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in turtle.py - module

Initial Comment:
When trying to use the RawPen-class of turtle.py,
the following error occurs:

Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license" for more
information.
IDLE 0.8 -- press F1 for help
>>> from Tkinter import *
>>> import turtle
>>> root = Tk()
>>> c = Canvas(root)
>>> c.pack()
>>> t = turtle.RawPen(c)
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    t = turtle.RawPen(c)
  File "C:\Python221c\lib\lib-tk\turtle.py", line 16,
in __init__
    self.reset()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 42,
in reset
    self.clear()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 53,
in clear
    self._draw_turtle()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 262,
in _draw_turtle
    self._arrow = _canvas.create_line(x-dx,y+dy,x,y,
AttributeError: 'NoneType' object has no attribute
'create_line'
>>> 

This can be fixed - I suppose - by correcting  line 262:

    self._arrow = self._canvas.create_line(x-dx, ...etc.



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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 09:07

Message:
Logged In: YES 
user_id=21627

This was fixed through patch #536117.

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

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



From noreply@sourceforge.net  Thu Apr  4 07:14:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 03 Apr 2002 23:14:06 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16t1Re-0000yJ-00@usw-sf-web1.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 23:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Danny Yoo (dyoo)
Date: 2002-04-04 07:14

Message:
Logged In: YES 
user_id=49843

Martin is right: I need to retract part of my bug-report: I
just remembered that any classes that have a __del__ method
aren't automatically cleaned  by a gc.collect().  I
triggered a pseudo-Heisenbug during my testing.

After removing the __del__ method from my test class and by
using parseString() instead of feed(), I've verified that
the XML parsing isn't the source of my memory leak.  (Test
file test_memory_leak_2.py included.)

However, after further investigation, I did find the true
source of my problems.. in MySQLdb:

http://sourceforge.net/tracker/index.php?func=detail&aid=536624&group_id=22307&atid=374932

Thank you again for looking into this.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 07:05

Message:
Logged In: YES 
user_id=21627

Also, when parsing the large xml file: if you invoke
gc.collect() after each iteration, memory consumption will
go down, and not grow over time. The reason that GC does not
trigger automatically is that you allocate all the space
through strings. GC will be invoked after 1000 new container
objects have been allocated, but you exhaust the memory
before that - so either set the GC threshold down, or invoke
GC on your own.

For the specific application, it would be sufficient if
xml.sax.__init__.parse would invoke
parser.setContentHandler(None) after parsing has completed;
this should already break the cycle.

To solve the general problem, I like your suggestion of
using a separate locator.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 06:21

Message:
Logged In: YES 
user_id=21627

I think the problem is elsewhere. Danny's demo script
clearly is buggy; if you use the IncrementalParser
interface, you *must* invoke .close() at the end of the
parse run; else you get cyclic garbage.

The cyclic garbage collector will pick up that garbage; just
invoke gc.collect() after test1 and test2 to see all
TestParsers destroyed.

So I don't think any action on Python code is necessary as a
bug fix; if there are remaining problems, then they must be
in pyexpat.c. I'll investigate 2.52 and 2.54 as candidates
for backporting.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 05:35

Message:
Logged In: YES 
user_id=3066

I'll note that the patch is against the release21-maint
branch of Python, and I've only tried it there.  It may need
changes for more recent versions of Python, but that branch
appears most critical since we're looking at a 2.1.3 release
next week.

OK, enough.  I'm heading to bed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 05:25

Message:
Logged In: YES 
user_id=3066

I've attached a patch.  I think this meets all the backward
compatibility requirements and is low-risk, and it removes
the circular reference.  So far I've only tested it against
the standard tests for Python 2.1.*; I'll try it tomorrow
with the sample test code, and think about a test that can
be added to the test suite.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 05:07

Message:
Logged In: YES 
user_id=3066

Looking at the code, it's not quite so trivial as I'd
thought, but not entirely difficult either.  I started by
creating a locator that had a reference to the parser object
from xml.parser.expat, but that of course has references to
the ExpatParser, so the cycle still exists.

As long as we're trying to solve the problem for Python 2.1
and newer, though, we can use a locator object that has a
weakref to the ExpatParser object, thereby breaking the
cycle.  I like that.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 04:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 22:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 22:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 12:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 12:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 09:54:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 01:54:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E16t3wd-0002sv-00@usw-sf-web2.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 01:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


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

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



From noreply@sourceforge.net  Thu Apr  4 10:58:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 02:58:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-538991 ] error in turtle.py - module
Message-ID: <E16t4ws-0006MS-00@usw-sf-web4.sourceforge.net>

Bugs item #538991, was opened at 2002-04-04 01:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538991&group_id=5470

Category: Tkinter
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in turtle.py - module

Initial Comment:
When trying to use the RawPen-class of turtle.py,
the following error occurs:

Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license" for more
information.
IDLE 0.8 -- press F1 for help
>>> from Tkinter import *
>>> import turtle
>>> root = Tk()
>>> c = Canvas(root)
>>> c.pack()
>>> t = turtle.RawPen(c)
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    t = turtle.RawPen(c)
  File "C:\Python221c\lib\lib-tk\turtle.py", line 16,
in __init__
    self.reset()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 42,
in reset
    self.clear()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 53,
in clear
    self._draw_turtle()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 262,
in _draw_turtle
    self._arrow = _canvas.create_line(x-dx,y+dy,x,y,
AttributeError: 'NoneType' object has no attribute
'create_line'
>>> 

This can be fixed - I suppose - by correcting  line 262:

    self._arrow = self._canvas.create_line(x-dx, ...etc.



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

>Comment By: Gregor Lingl (glingl)
Date: 2002-04-04 12:58

Message:
Logged In: YES 
user_id=505031

Cannot find patch #536117
When was it fixed?

In python2.2.1c2 it's definitely not fixed

Gregor Lingl

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 09:07

Message:
Logged In: YES 
user_id=21627

This was fixed through patch #536117.

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

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



From noreply@sourceforge.net  Thu Apr  4 11:18:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 03:18:29 -0800
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E16t5G9-0003ox-00@usw-sf-web2.sourceforge.net>

Bugs item #216388, was opened at 2000-10-08 17:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
Resolution: Later
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


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

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-04 03:18

Message:
Logged In: NO 

9;lo;;99999999999999999999999

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

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 14:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-16 18:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-10 08:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-07 19:56

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 13:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 01:34

Message:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).


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

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



From noreply@sourceforge.net  Thu Apr  4 14:06:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 06:06:34 -0800
Subject: [Python-bugs-list] [ python-Bugs-539024 ] broken link in array module doc
Message-ID: <E16t7so-0000Bm-00@usw-sf-web4.sourceforge.net>

Bugs item #539024, was opened at 2002-04-03 19:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539024&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: broken link in array module doc

Initial Comment:
The link to "The Numerical Python Manual" on the
2.2 doc page for the array module, pointing to
http://numpy.sourceforge.net/numdoc/HTML/numdoc.html
gets a 404 not found error.  The correct url is
http://numpy.sourceforge.net/numdoc/HTML/numdoc.htm
i.e. it has .htm instead of .html.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-04 09:06

Message:
Logged In: YES 
user_id=33168

Checked in as libarray.tex 1.31.8.2, 1.34.

Sorry if I wasn't supposed to check in on 2.2 branch.
I figured it was easier to beg forgiveness than ask permission.

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

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



From noreply@sourceforge.net  Thu Apr  4 15:57:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 07:57:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-538991 ] error in turtle.py - module
Message-ID: <E16t9br-0001el-00@usw-sf-web3.sourceforge.net>

Bugs item #538991, was opened at 2002-04-04 01:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538991&group_id=5470

Category: Tkinter
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Duplicate
Priority: 5
Submitted By: Gregor Lingl (glingl)
Assigned to: Nobody/Anonymous (nobody)
Summary: error in turtle.py - module

Initial Comment:
When trying to use the RawPen-class of turtle.py,
the following error occurs:

Python 2.2.1c2 (#33, Mar 26 2002, 13:04:18) [MSC 32 bit
(Intel)] on win32
Type "copyright", "credits" or "license" for more
information.
IDLE 0.8 -- press F1 for help
>>> from Tkinter import *
>>> import turtle
>>> root = Tk()
>>> c = Canvas(root)
>>> c.pack()
>>> t = turtle.RawPen(c)
Traceback (most recent call last):
  File "<pyshell#5>", line 1, in ?
    t = turtle.RawPen(c)
  File "C:\Python221c\lib\lib-tk\turtle.py", line 16,
in __init__
    self.reset()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 42,
in reset
    self.clear()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 53,
in clear
    self._draw_turtle()
  File "C:\Python221c\lib\lib-tk\turtle.py", line 262,
in _draw_turtle
    self._arrow = _canvas.create_line(x-dx,y+dy,x,y,
AttributeError: 'NoneType' object has no attribute
'create_line'
>>> 

This can be fixed - I suppose - by correcting  line 262:

    self._arrow = self._canvas.create_line(x-dx, ...etc.



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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 17:57

Message:
Logged In: YES 
user_id=21627

You can find the patch at http://python.org/sf/536117
As you can see from the patch discussion, it was committed
as turtle.py 1.6, so the fix will be released with Python 2.3.

The patch might be considered for inclusion in Python 2.2.2
as well.

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

Comment By: Gregor Lingl (glingl)
Date: 2002-04-04 12:58

Message:
Logged In: YES 
user_id=505031

Cannot find patch #536117
When was it fixed?

In python2.2.1c2 it's definitely not fixed

Gregor Lingl

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 09:07

Message:
Logged In: YES 
user_id=21627

This was fixed through patch #536117.

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

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



From noreply@sourceforge.net  Thu Apr  4 16:27:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 08:27:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-534347 ] Potential AV in vgetargskeywords
Message-ID: <E16tA56-00021s-00@usw-sf-web3.sourceforge.net>

Bugs item #534347, was opened at 2002-03-24 11:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534347&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Greg Chapman (glchapman)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Potential AV in vgetargskeywords

Initial Comment:
If you are dumb enough to do what I just did, pass a 
dictionary with non-string keys to 
PyEval_CallObjectWithKeyWords, you may cause an access 
violation in Python (if the call ends up going through 
PyArg_ParseTupleAndKeywords).  The problem is in the 
section of vgetargskeywords which checks for 
extraneous keyword arguments: it does not check to 
make sure PyString_AsString(key) succeeded.  Attached 
is a simple patch.


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-04 11:27

Message:
Logged In: YES 
user_id=6380

Fixed in CVS.  Thanks!

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

Comment By: Greg Chapman (glchapman)
Date: 2002-03-27 12:20

Message:
Logged In: YES 
user_id=86307

On second thought, perhaps I didn't follow 
PyEval_EvalCodeEx closely enough.  PyString_AsString can 
succeed for some non-string types (unicode, etc.), but 
these keys would not work if passed to PyEval_EvalCodeEx.  
So attached is a second version of the patch which calls 
PyString_Check before calling PyString_AsString. 

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

Comment By: Greg Chapman (glchapman)
Date: 2002-03-27 11:55

Message:
Logged In: YES 
user_id=86307

I don't think calling PyErr_Clear is necessary given the 
current implementation; both PyErr_Clear and 
PyErr_SetString ultimately call PyErr_Restore, which clears 
the old error.

As for passing the error through, that might be a better 
choice.  I put in the PyErr_SetString to try to follow the 
behavior of PyEval_EvalCodeEx when it gets non-string keys 
in a keyword dict.


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:40

Message:
Logged In: YES 
user_id=21627

I think you need to clear the previous exception which is
indicated by the NULL return value (or just let it trough as
is).

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

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



From noreply@sourceforge.net  Thu Apr  4 16:38:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 08:38:27 -0800
Subject: [Python-bugs-list] [ python-Bugs-539319 ] sys.argv only works with python exe
Message-ID: <E16tAFn-0007dS-00@usw-sf-web1.sourceforge.net>

Bugs item #539319, was opened at 2002-04-04 10:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539319&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Hostetler (thehaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.argv only works with python exe

Initial Comment:
This is a weird one, and I've know it works on other
Win2000 installations, but it doesn't work on mine.

sys.argv only works when I put "python" in front of it
in the cmd command line.  However, the script does run
if I just type in it's name, but it ignores all command
line arguments.

Version: 2.2
Platform: Win2000

Example:

C:\stuff>type test.py
import sys
print sys.argv

C:\stuff>test.py arg1 arg2
['C:\stuff\test.py']

C:\stuff>python test.py arg1 arg2
['test.py', 'arg1', 'arg2']

Is this something with my setup, or something else??




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

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



From noreply@sourceforge.net  Thu Apr  4 17:01:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 09:01:57 -0800
Subject: [Python-bugs-list] [ python-Bugs-534669 ] remember to sync trees
Message-ID: <E16tAcX-0007v1-00@usw-sf-web1.sourceforge.net>

Bugs item #534669, was opened at 2002-03-25 08:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: remember to sync trees

Initial Comment:
There are various fixes hitting the trunk that I'm not
considering for 2.2.1 that should probably be
considered for 2.2.2 if that ever happens.

Conversely there may be a few things I've fixed in the
22-maint branch that haven't been fixed on the trunk.

Don't forget these.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-04 12:01

Message:
Logged In: YES 
user_id=6380

How do I know what you fixed on the branch that should be
moved to the trunk?

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

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



From noreply@sourceforge.net  Thu Apr  4 17:08:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 09:08:11 -0800
Subject: [Python-bugs-list] [ python-Bugs-535170 ] new.instance() breaks with new classes
Message-ID: <E16tAiZ-00086f-00@usw-sf-web2.sourceforge.net>

Bugs item #535170, was opened at 2002-03-26 07:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535170&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: new.instance() breaks with new classes

Initial Comment:
>>> class a1: pass
... 
>>> a2 = type('a2', (), {})
>>> class a3(object): pass
... 
>>> a1
<class __main__.a1 at 0x815111c>
>>> a2
<class '__main__.a2'>
>>> a3
<class '__main__.a3'>
>>> import new
>>> new.instance(a1)
<__main__.a1 instance at 0x8148a04>
>>> new.instance(a2)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: instance() argument 1 must be class, not type
>>> new.instance(a3)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: instance() argument 1 must be class, not type

2.2 branch and current CVS...  _so_ not a 2.2 bugfix
necessity, tho :)

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-04 12:08

Message:
Logged In: YES 
user_id=6380

There's no need to use new.instance() for new-style classes.

You should be able to do this using the __new__ method of
the new-style class.

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

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



From noreply@sourceforge.net  Thu Apr  4 17:13:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 09:13:54 -0800
Subject: [Python-bugs-list] [ python-Bugs-539319 ] sys.argv only works with python exe
Message-ID: <E16tAo6-000843-00@usw-sf-web1.sourceforge.net>

Bugs item #539319, was opened at 2002-04-04 18:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539319&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Hostetler (thehaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.argv only works with python exe

Initial Comment:
This is a weird one, and I've know it works on other
Win2000 installations, but it doesn't work on mine.

sys.argv only works when I put "python" in front of it
in the cmd command line.  However, the script does run
if I just type in it's name, but it ignores all command
line arguments.

Version: 2.2
Platform: Win2000

Example:

C:\stuff>type test.py
import sys
print sys.argv

C:\stuff>test.py arg1 arg2
['C:\stuff\test.py']

C:\stuff>python test.py arg1 arg2
['test.py', 'arg1', 'arg2']

Is this something with my setup, or something else??




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

>Comment By: Thomas Heller (theller)
Date: 2002-04-04 19:13

Message:
Logged In: YES 
user_id=11105

I can reproduce this behaviour if I change the association 
for Python files from the default entry
'C:\python22\python.exe "%1" %*'
into
'C:\python22\python.exe "%1"'.
You can find this entry from Windows Explorer,
Tools->Folder Options->File Types.
Select the 'PY Python File' entry, press advanced, select 
the 'open' entry, press edit, and look at the "Appplication 
used to perform action" entry.

Probably something wrong with your setup.

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

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



From noreply@sourceforge.net  Thu Apr  4 17:22:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 09:22:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-462783 ] mmap bus error on linux
Message-ID: <E16tAwp-0008B1-00@usw-sf-web1.sourceforge.net>

Bugs item #462783, was opened at 2001-09-19 03:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=462783&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap bus error on linux

Initial Comment:
Not using the mmap module correctly can cause a
bus error under Linux.  This is a DEC, err, Compaq,
err, HP Alpha.

Here's a reproducible.  The problem appears to
be trying to mmap past the end of the file,
since putting in a "seek(0)" at the indicated
spot fixes things.


[dalke@pw600a src]$ ./python
Python 2.2a3+ (#6, Sep 17 2001, 05:05:24)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> file = open("test.dat", "w+")
>>> file.write("12345")
>>> import mmap
>>> # Forgot to do "file.seek(0)" here
>>> s = mmap.mmap(file.fileno(), 5)
>>> s[:5]
Bus error
[dalke@pw600a src]$ gdb ./python core
GNU gdb 19991004
Copyright 1998 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 "alpha-redhat-linux"...

warning: "/home/dalke/cvses/python/dist/src/core": 
ambiguous core format, 2 handle
rs match

warning: core file may not match specified executable 
file.
Core was generated by `perl'.
Program terminated with signal 8, Floating point 
exception.
#0  0x12004d7b8 in com_assert_stmt (c=0x0, n=0x0) at 
Python/compile.c:717
717             PyString_AsString(c->c_code)[c-
>c_nexti++] = byte;
(gdb) where
#0  0x12004d7b8 in com_assert_stmt (c=0x0, n=0x0) at 
Python/compile.c:717
(gdb)

                     Andrew
                     dalke@dalkescientific.com


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-04 12:22

Message:
Logged In: YES 
user_id=6380

Note that Greg Green has uploaded a fix for this, patch
536578.

Andrew, can you test that patch?

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

Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-22 19:37

Message:
Logged In: YES 
user_id=31392

I can reproduce the problem just fine on Intel Linux, but
I'm not really sure what we can do about it.  When I run the
test, I get a bus error when it tries to dereference
self->data in mmap_slice().  I don't see how we can prevent
the bus error short of checking the length of the file
before we map it.


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

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



From noreply@sourceforge.net  Thu Apr  4 17:26:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 09:26:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-539319 ] sys.argv only works with python exe
Message-ID: <E16tB0E-0002aY-00@usw-sf-web4.sourceforge.net>

Bugs item #539319, was opened at 2002-04-04 10:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539319&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mike Hostetler (thehaas)
Assigned to: Nobody/Anonymous (nobody)
Summary: sys.argv only works with python exe

Initial Comment:
This is a weird one, and I've know it works on other
Win2000 installations, but it doesn't work on mine.

sys.argv only works when I put "python" in front of it
in the cmd command line.  However, the script does run
if I just type in it's name, but it ignores all command
line arguments.

Version: 2.2
Platform: Win2000

Example:

C:\stuff>type test.py
import sys
print sys.argv

C:\stuff>test.py arg1 arg2
['C:\stuff\test.py']

C:\stuff>python test.py arg1 arg2
['test.py', 'arg1', 'arg2']

Is this something with my setup, or something else??




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

>Comment By: Mike Hostetler (thehaas)
Date: 2002-04-04 11:26

Message:
Logged In: YES 
user_id=116274

I went into that, I had got the PY option, but instead it
sais "PY File".  And instead of an advanced button, it had
"Change", with the text beside it saying "Change to Default
'Python File""  I hit that button, which than turned to
"Advanced" and the PY option turned into "Python File". 
When I hit "Advanced" the option was 'C:\python22\python.exe
"%1" %*', it it now works from the command line:


C:\stuff>test.py arg1
['C:\stuff\test.py', 'arg1']

I'm not sure what caused it to change (perhaps Vim??) but it
works now.

Closing it myself.  Thanks for the help




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

Comment By: Thomas Heller (theller)
Date: 2002-04-04 11:13

Message:
Logged In: YES 
user_id=11105

I can reproduce this behaviour if I change the association 
for Python files from the default entry
'C:\python22\python.exe "%1" %*'
into
'C:\python22\python.exe "%1"'.
You can find this entry from Windows Explorer,
Tools->Folder Options->File Types.
Select the 'PY Python File' entry, press advanced, select 
the 'open' entry, press edit, and look at the "Appplication 
used to perform action" entry.

Probably something wrong with your setup.

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

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



From noreply@sourceforge.net  Thu Apr  4 18:00:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 10:00:38 -0800
Subject: [Python-bugs-list] [ python-Bugs-539319 ] sys.argv only works with python exe
Message-ID: <E16tBXK-00030B-00@usw-sf-web4.sourceforge.net>

Bugs item #539319, was opened at 2002-04-04 18:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539319&group_id=5470

>Category: Windows
Group: Platform-specific
Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Mike Hostetler (thehaas)
>Assigned to: Thomas Heller (theller)
Summary: sys.argv only works with python exe

Initial Comment:
This is a weird one, and I've know it works on other
Win2000 installations, but it doesn't work on mine.

sys.argv only works when I put "python" in front of it
in the cmd command line.  However, the script does run
if I just type in it's name, but it ignores all command
line arguments.

Version: 2.2
Platform: Win2000

Example:

C:\stuff>type test.py
import sys
print sys.argv

C:\stuff>test.py arg1 arg2
['C:\stuff\test.py']

C:\stuff>python test.py arg1 arg2
['test.py', 'arg1', 'arg2']

Is this something with my setup, or something else??




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

>Comment By: Thomas Heller (theller)
Date: 2002-04-04 20:00

Message:
Logged In: YES 
user_id=11105

Fine. Assigning the bug to myself, and changing the 
resolution to 'works for me'.

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

Comment By: Mike Hostetler (thehaas)
Date: 2002-04-04 19:26

Message:
Logged In: YES 
user_id=116274

I went into that, I had got the PY option, but instead it
sais "PY File".  And instead of an advanced button, it had
"Change", with the text beside it saying "Change to Default
'Python File""  I hit that button, which than turned to
"Advanced" and the PY option turned into "Python File". 
When I hit "Advanced" the option was 'C:\python22\python.exe
"%1" %*', it it now works from the command line:


C:\stuff>test.py arg1
['C:\stuff\test.py', 'arg1']

I'm not sure what caused it to change (perhaps Vim??) but it
works now.

Closing it myself.  Thanks for the help




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

Comment By: Thomas Heller (theller)
Date: 2002-04-04 19:13

Message:
Logged In: YES 
user_id=11105

I can reproduce this behaviour if I change the association 
for Python files from the default entry
'C:\python22\python.exe "%1" %*'
into
'C:\python22\python.exe "%1"'.
You can find this entry from Windows Explorer,
Tools->Folder Options->File Types.
Select the 'PY Python File' entry, press advanced, select 
the 'open' entry, press edit, and look at the "Appplication 
used to perform action" entry.

Probably something wrong with your setup.

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

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



From noreply@sourceforge.net  Thu Apr  4 18:00:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 10:00:50 -0800
Subject: [Python-bugs-list] [ python-Bugs-535474 ] xml.sax memory leak with ExpatParser
Message-ID: <E16tBXW-0000Iu-00@usw-sf-web2.sourceforge.net>

Bugs item #535474, was opened at 2002-03-26 18:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=535474&group_id=5470

Category: XML
Group: Python 2.1.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xml.sax memory leak with ExpatParser

Initial Comment:
I've isolated a memory leak in the ExpatParser that
deals with the destruction of ContentHandlers.  I'm
including my test program test_memory_leak.py that
tests the behavior --- I generate a bunch of
ContentParsers, and see if they get destroyed reliably.


This appears to affect Python 2.1.1 and 2.1.2. 
Thankfully, the leak appears to be fixed in 2.2.1c. 
Here's some of the test runs:

### Python 2.1.1:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.1/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###



### Python 2.1.2:
[dyoo@tesuque dyoo]$ /opt/Python-2.1.2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.



Test2:
###


### Python 2.2.1c
[dyoo@tesuque dyoo]$ /opt/Python-2.2.1c2/bin/python
test_memory_leak.py
This is a test of an apparent XML memory leak.
Test1:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.



Test2:
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
TestParser destructed.
###





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

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 13:00

Message:
Logged In: YES 
user_id=3066

Checked in the fixed version as Lib/xml/sax/expatreader.py
revisions 1.26, 1.25.16.1, and 1.22.4.1 (this last means
it'll be in Python 2.1.3).

This or a similar change should be added to PyXML.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-04-04 02:14

Message:
Logged In: YES 
user_id=49843

Martin is right: I need to retract part of my bug-report: I
just remembered that any classes that have a __del__ method
aren't automatically cleaned  by a gc.collect().  I
triggered a pseudo-Heisenbug during my testing.

After removing the __del__ method from my test class and by
using parseString() instead of feed(), I've verified that
the XML parsing isn't the source of my memory leak.  (Test
file test_memory_leak_2.py included.)

However, after further investigation, I did find the true
source of my problems.. in MySQLdb:

http://sourceforge.net/tracker/index.php?func=detail&aid=536624&group_id=22307&atid=374932

Thank you again for looking into this.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 02:05

Message:
Logged In: YES 
user_id=21627

Also, when parsing the large xml file: if you invoke
gc.collect() after each iteration, memory consumption will
go down, and not grow over time. The reason that GC does not
trigger automatically is that you allocate all the space
through strings. GC will be invoked after 1000 new container
objects have been allocated, but you exhaust the memory
before that - so either set the GC threshold down, or invoke
GC on your own.

For the specific application, it would be sufficient if
xml.sax.__init__.parse would invoke
parser.setContentHandler(None) after parsing has completed;
this should already break the cycle.

To solve the general problem, I like your suggestion of
using a separate locator.

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 01:21

Message:
Logged In: YES 
user_id=21627

I think the problem is elsewhere. Danny's demo script
clearly is buggy; if you use the IncrementalParser
interface, you *must* invoke .close() at the end of the
parse run; else you get cyclic garbage.

The cyclic garbage collector will pick up that garbage; just
invoke gc.collect() after test1 and test2 to see all
TestParsers destroyed.

So I don't think any action on Python code is necessary as a
bug fix; if there are remaining problems, then they must be
in pyexpat.c. I'll investigate 2.52 and 2.54 as candidates
for backporting.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:35

Message:
Logged In: YES 
user_id=3066

I'll note that the patch is against the release21-maint
branch of Python, and I've only tried it there.  It may need
changes for more recent versions of Python, but that branch
appears most critical since we're looking at a 2.1.3 release
next week.

OK, enough.  I'm heading to bed.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:25

Message:
Logged In: YES 
user_id=3066

I've attached a patch.  I think this meets all the backward
compatibility requirements and is low-risk, and it removes
the circular reference.  So far I've only tested it against
the standard tests for Python 2.1.*; I'll try it tomorrow
with the sample test code, and think about a test that can
be added to the test suite.

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-04 00:07

Message:
Logged In: YES 
user_id=3066

Looking at the code, it's not quite so trivial as I'd
thought, but not entirely difficult either.  I started by
creating a locator that had a reference to the parser object
from xml.parser.expat, but that of course has references to
the ExpatParser, so the cycle still exists.

As long as we're trying to solve the problem for Python 2.1
and newer, though, we can use a locator object that has a
weakref to the ExpatParser object, thereby breaking the
cycle.  I like that.  ;-)

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

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-03 23:50

Message:
Logged In: YES 
user_id=3066

I don't remember if the cycle detector was enabled by
default in 2.1.* -- that all seems so long ago!

The content handler ends up being part of a circular
reference cycle, with the ExpatParser acting as it's own
locator object.  This happens because the parser references
the content handler, and hands a reference to itself for the
content handler to squirrel away as the locator.

I see two approaches to removing this dependency.  The first
is simply to call setDocumentLocator(None) after calling
endDocument(), but that's fragile; it assumes the parse gets
that far.  The second is to use a separate object to provide
the locator to the content handler; this seems more robust
as it doesn't assume that the parse succeeds.

I'll start on a patch that uses the second approach.

Martin, do you see any other alternatives?  There will be a
2.1.3 release for other reasons, BTW, so this might make it in.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-28 17:48

Message:
Logged In: YES 
user_id=31435

Assigned to Fred, after he begged me to <wink>.

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

Comment By: Danny Yoo (dyoo)
Date: 2002-03-28 17:37

Message:
Logged In: YES 
user_id=49843

Hi Martin,

Yikes; Sorry about that.  I've attached the file.

---


I did some more experimentation with xml.sax, and there does
appear to be a serious problem with object destruction, even
with Python 2.2.1c.

I'm working with a fairly large XML file located on the TIGR
(The Institute for Genomic Research) ftp site.  A sample
file would be something like:

ftp://ftp.tigr.org/pub/data/a_thaliana/ath1/PSEUDOCHROMOSOMES/chr1.xml

(60 MBs)

and I noticed that my scripts were leaking memory.  I've
isolated the problem to what looks like a garbage collection
problem: it looks like my ContentHandlers are not getting
recycled.  Here's a simplified program:

###
import xml.sax
import glob
from cStringIO import StringIO


class FooParser(xml.sax.ContentHandler):
    def __init__(self):
        self.bigcontent = StringIO()

    def startElement(self, name, attrs):
        pass

    def endElement(self, name):
        pass

    def characters(self, chars):
        self.bigcontent.write(chars)


filename =
'/home/arabidopsis/bacs/20020107/PSEUDOCHROMOSOME/chr1.xml'
i = 0
while 1:
    print "Iteration %d" % i
    xml.sax.parse(open(filename), FooParser())
    i = i + 1
###

I've watched 'top', and the memory usage continues growing.
 Any suggestions?  Thanks!

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:24

Message:
Logged In: YES 
user_id=21627

Also, what kind of action do you expect. Chances are minimal
that there will be a 2.1.3 release, so why bother?

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

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:23

Message:
Logged In: YES 
user_id=21627

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

Please try again.

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

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

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



From noreply@sourceforge.net  Thu Apr  4 18:08:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 10:08:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-513572 ] isdir behavior getting odder on UNC path
Message-ID: <E16tBef-0000OK-00@usw-sf-web2.sourceforge.net>

Bugs item #513572, was opened at 2002-02-06 02:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Nobody/Anonymous (nobody)
Summary: isdir behavior getting odder on UNC path

Initial Comment:
It's been documented in earlier version of Python on 
windows that os.path.isdir returns true on a UNC 
directory only if there was an extra backslash at the 
end of the argument.  In Python2.2 (at least on 
windows 2000) it appears that *TWO* extra backslashes 
are needed.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>>
>>> import os
>>> os.path.isdir('\\trainer\island')
0
>>> os.path.isdir('\\trainer\island\')
0
>>> os.path.isdir('\\trainer\island\\')
1
>>>

In a perfect world, the first call should return 1, 
but never has.  In older versions of python, the 
second returned 1, but no longer.

In limited tests, appending 2 or more backslashes to 
the end of any pathname returns the correct answer in 
both isfile and isdir.


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

>Comment By: Trent Mick (tmick)
Date: 2002-04-04 18:08

Message:
Logged In: YES 
user_id=34892

I have struggled with this too. Currently I tend to use 
this _isdir(). Hopefully this is helpful.

def _isdir(dirname):
    """os.path.isdir() doesn't work for UNC mount points. 
Fake it.
    
    # For an existing mount point
    # (want: _isdir() == 1)
    os.path.ismount(r"\crimper\apps") -> 1
    os.path.exists(r"\crimper\apps") -> 0
    os.path.isdir(r"\crimper\apps") -> 0
    os.listdir(r"\crimper\apps") -> [...contents...]
    # For a non-existant mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\foo") -> 1
    os.path.exists(r"\crimper\foo") -> 0
    os.path.isdir(r"\crimper\foo") -> 0
    os.listdir(r"\crimper\foo") -> WindowsError
    # For an existing dir under a mount point
    # (want: _isdir() == 1)
    os.path.mount(r"\crimper\apps\Komodo") -> 0
    os.path.exists(r"\crimper\apps\Komodo") -> 1
    os.path.isdir(r"\crimper\apps\Komodo") -> 1
    os.listdir(r"\crimper\apps\Komodo") -> [...contents...]
    # For a non-existant dir/file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\foo") -> 0
    os.path.exists(r"\crimper\apps\foo") -> 0
    os.path.isdir(r"\crimper\apps\foo") -> 0
    os.listdir(r"\crimper\apps\foo") -> []  # as if empty 
contents
    # For an existing file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\Komodo\exists.txt") -> 
0
    os.path.exists(r"\crimper\apps\Komodo\exists.txt") -> 1
    os.path.isdir(r"\crimper\apps\Komodo\exists.txt") -> 0
    os.listdir(r"\crimper\apps\Komodo\exists.txt") -> 
WindowsError
    """
    if sys.platform[:3] == 'win' and dirname[:2] == r'\':
        if os.path.exists(dirname):
            return os.path.isdir(dirname)
        try:
            os.listdir(dirname)
        except WindowsError:
            return 0
        else:
            return os.path.ismount(dirname)
    else:
        return os.path.isdir(dirname)



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

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 09:03

Message:
Logged In: YES 
user_id=31435

Gordon, none of those are UNC roots -- they follow the 
rules exactly as stated for non-UNC paths:  MS stat() 
recognizes \ME\E\java if and only if there's no trailing 
backslash.  That's why your first example succeeds.  The 
complication is that Python removes one trailing 
backslash "by magic" unless the path "looks like a root", 
and none of these do.  That's why your third example 
works.  Your second and fourth examples fail because you 
specified two trailing backslashes in those, and Python 
only removes one of them by magic.

An example of "a UNC root" would be \ME\E.  The MS stat() 
recognizes a root directory if and only if it *does* have a 
trailing backslash, and Python's magical backslash removal 
doesn't know UNC roots from a Euro symbol.  So the only way 
to get Python's isdir() (etc) to recognize \ME\E is to 
follow it with two backslashes, one because Python strips 
one away (due to not realizing "it looks like a root"), and 
another else MS stat() refuses to recognize it.

Anyway, I'm unassigning this now, cuz MarkH isn't paying 
any attentino.  If someone wants to write a pile of tedious 
code to "recognize a UNC root when it sees one", I'd accept 
the patch.  I doubt I'll get it to it myself in this 
lifetime.

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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 15:31

Message:
Logged In: YES 
user_id=4923

Data point:
 run on a win2k box, where \ME is an NT box
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.isdir(r"\ME\E\java")
1
>>> os.path.isdir(r"\ME\E\java\")
0
>>> os.path.isdir("\\ME\E\java\")
1
>>> os.path.isdir("\\ME\E\java\\")
0


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 08:28

Message:
Logged In: YES 
user_id=31435

Mark, what do you think about a different approach here?

1. Leave the string alone and *try* stat.  If it   
succeeds, great, we're done.

2. Else if the string doesn't have a trailing (back)slash, 
append one and try again.  Win or lose, that's the end.

3. Else the string does have a trailing (back)slash.  If 
the string has more than one character, strip a trailing 
(back)slash and try again.  Win or lose, that's the end.

4. Else the string is a single (back)slash, yet stat() 
failed.  This shouldn't be possible.

It doubles the number of stats in cases where the file path 
doesn't correspond to anything that exists.  OTOH, MS's 
(back)slash rules are undocumented and incomprehensible 
(read their implementation of stat() for the whole truth -- 
we're not out-thinking lots of it now, and the gimmick 
added after 1.5.2 to out-think part of it is at least 
breaking Gary's thoroughly sensible use).

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

Comment By: Gary Herron (herron)
Date: 2002-02-11 08:03

Message:
Logged In: YES 
user_id=395736

Sorry, but I don't have much of an idea which versions I 
was refering to.  I picked up the idea of an extra 
backslashes in a faq from a web site, the search for which 
I can't seem to reproduce.  It claimed one backslash was 
enough, but did not specify a python version.  It *might* 
have been old enough to be pre 1.5.2.
 
The two versions I can test are 1.5.1 (where one backslash 
is enough) and 2.2 (where two are required).  This seems 
to me to support (or at least not contradict) Tim's 
hypothesis.

Gary


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-10 18:57

Message:
Logged In: YES 
user_id=31435

Gary, exactly what do you mean by "older versions of 
Python"?  That is, specifically which versions?

The Microsoft stat() function is extremely picky about 
trailing (back)slashes.  For example, if you have a 
directory c:/python, and pass "c:/python/" to the MS stat
(), it claims no such thing exists.  This isn't documented 
by MS, but that's how it works:  a trailing (back)slash is 
required if and only if the path passed in "is a root".  So 
MS stat() doesn't understand "/python/", and doesn't 
understand "d:" either.  The former doesn't tolerate a 
(back)slash, while the latter requires one.

This is impossible for people to keep straight, so after 
1.5.2 Python started removing (back)slashes on its own to 
make MS stat() happy.  The code currently leaves a trailing 
(back)slash alone if and only if one exists, and in 
addition of these obtains:

1) The (back)slash is the only character in the path.
or
2) The path has 3 characters, and the middle one is a colon.

UNC roots don't fit either of those, so do get one (back)
slash chopped off.  However, just as for any other roots, 
the MS stat() refuses to recognize them as valid unless 
they do have a trailing (back)slash.  Indeed, the last time 
I applied a contributed patch to this code, I added a

/* XXX UNC root drives should also be exempted? */

comment there.

However, this explanation doesn't make sense unless by 
"older versions of Python" you mean nothing more recent 
than 1.5.2.  If I'm understanding the source of the 
problem, it should exist in all Pythons after 1.5.2.  So if 
you don't see the same problem in 1.6, 2.0 or 2.1, I'm on 
the wrong track.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 23:33

Message:
Logged In: YES 
user_id=31435

BTW, it occurs to me that this *may* be a consequence of 
whatever was done in 2.2 to encode/decode filename strings 
for system calls on Windows.  I didn't follow that, and 
Mark may be the only one who fully understands the details.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 23:17

Message:
Logged In: YES 
user_id=31435

Here's the implementation of Windows isdir():

def isdir(path):
.    """Test whether a path is a directory"""
.    try:
.        st = os.stat(path)
.    except os.error:
.        return 0
.    return stat.S_ISDIR(st[stat.ST_MODE])

That is, we return whatever Microsoft's stat() tells us, 
and our code is the same in 2.2 as in 2.1.  I don't have 
Win2K here, and my Win98 box isn't on a Windows network so 
I can't even try real UNC paths here.  Reassigning to MarkH 
in case he can do better on either count.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 22:05

Message:
Logged In: YES 
user_id=6380

Tim, I hate to do this to you, but you're the only person I
trust with researching this. (My laptop is currently off the
net again. :-( )


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

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



From noreply@sourceforge.net  Thu Apr  4 19:23:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 11:23:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-525121 ] tty shipped in win32 distribution
Message-ID: <E16tCps-00041f-00@usw-sf-web4.sourceforge.net>

Bugs item #525121, was opened at 2002-03-03 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=525121&group_id=5470

Category: Python Library
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 1
Submitted By: Fredrik Stenberg (fredriks)
>Assigned to: Tim Peters (tim_one)
Summary: tty shipped in win32 distribution

Initial Comment:

Hi,

tty is shipped with the windows distribution..
if one tries to import it (which ofcourse should not
work) you get,

>>> import tty
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Python21\lib\tty.py", line 5, in ?
    from termios import *
ImportError: No module named termios

this is true for the following versions atleast, 

Python 2.1.2 (#31, Jan 15 2002, 17:28:11) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-04 14:23

Message:
Logged In: YES 
user_id=31435

Closed as Not-A-Bug for lack of feedback (it's been a 
month, and, as Guido said, it's not a bug).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-03 14:34

Message:
Logged In: YES 
user_id=6380

I'm not sure I understand your complaint.  We ship all .py
modules with Windows.  The "import tty" *does* fail, doesn't
it?  So what's the bug?

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

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



From noreply@sourceforge.net  Thu Apr  4 19:26:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 11:26:56 -0800
Subject: [Python-bugs-list] [ python-Bugs-497854 ] Short-cuts missing for All Users
Message-ID: <E16tCsq-00044I-00@usw-sf-web4.sourceforge.net>

Bugs item #497854, was opened at 2001-12-30 09:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470

>Category: Windows
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 7
Submitted By: Martin v. L�wis (loewis)
>Assigned to: Tim Peters (tim_one)
Summary: Short-cuts missing for All Users

Initial Comment:
Using the Windows installer of Python 2.2 on Windows XP
Professional, as a user "root" who is member of the
Administrator's group, performing an admin
installation, the Python 2.2 program group does not
show up in the start menu of other users.

The cause for this problem is that the installer puts
the shortcuts into \Documents and Settings\root\Start
Menu, not into \Documents and Settings\All Users\Start
Menu.

Notice that it is difficult to login as Administrator
on XP, since the Administrator account is not displayed
on the welcome screen (only if the old-style login
screen is selected). Even if installing Python as
Administrator, the shortcuts still end up in \Documents
and Settings\Administrator\Start Menu.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-04 14:26

Message:
Logged In: YES 
user_id=31435

Changed to Windows/2.2.1 candidate, assigned to me, and 
boosted priority.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 15:55

Message:
Logged In: YES 
user_id=6380

Then at least let's remember to fix this in 2.3.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:02

Message:
Logged In: YES 
user_id=31435

Yes, the installer hasn't changed, and won't for 2.2.1 
unless somebody other than me can make time to do it.  That 
seems unlikely to the point of fantasy, alas.

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

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-03-22 13:29

Message:
Logged In: YES 
user_id=283405

The Python 2.2.1c1 installer for Windows still has this 
shortcoming: Even when doing an administrative install, 
shortcuts for Python are created in "Administrator"s 
profile, not "All Users".  However, various extensions, 
like wxpython, win32all, etc. seem to get this right.

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

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-02-22 12:19

Message:
Logged In: YES 
user_id=283405

This is also a problem under Windows 2000 Professional,
where I am actually logged in as "Administrator" and have
made sure it is a full administrative install I'm doing. 
Registry settings are properly made for everyone; it is just
the short cuts that don't appear.

I've been working around this by manually moving the program
group folder to "All Users" and changing the ACLs.  This
should be done before installing win32all, which will create
the program group under "All Users".

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

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



From noreply@sourceforge.net  Thu Apr  4 19:58:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 11:58:46 -0800
Subject: [Python-bugs-list] [ python-Bugs-497854 ] Short-cuts missing for All Users
Message-ID: <E16tDNe-0001et-00@usw-sf-web1.sourceforge.net>

Bugs item #497854, was opened at 2001-12-30 09:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Martin v. L�wis (loewis)
Assigned to: Tim Peters (tim_one)
Summary: Short-cuts missing for All Users

Initial Comment:
Using the Windows installer of Python 2.2 on Windows XP
Professional, as a user "root" who is member of the
Administrator's group, performing an admin
installation, the Python 2.2 program group does not
show up in the start menu of other users.

The cause for this problem is that the installer puts
the shortcuts into \Documents and Settings\root\Start
Menu, not into \Documents and Settings\All Users\Start
Menu.

Notice that it is difficult to login as Administrator
on XP, since the Administrator account is not displayed
on the welcome screen (only if the old-style login
screen is selected). Even if installing Python as
Administrator, the shortcuts still end up in \Documents
and Settings\Administrator\Start Menu.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-04 14:58

Message:
Logged In: YES 
user_id=31435

The install script had gotten lost in the maze of Wise 
system vrbls, so the same (or similar) problem was evident 
on Win2K.  The release22-maint branch contains a putative 
fix now, which works OK on Win2K, but I don't have access 
to an XP box and don't know whether "the rules" changed 
there.

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

Comment By: Tim Peters (tim_one)
Date: 2002-04-04 14:26

Message:
Logged In: YES 
user_id=31435

Changed to Windows/2.2.1 candidate, assigned to me, and 
boosted priority.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 15:55

Message:
Logged In: YES 
user_id=6380

Then at least let's remember to fix this in 2.3.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:02

Message:
Logged In: YES 
user_id=31435

Yes, the installer hasn't changed, and won't for 2.2.1 
unless somebody other than me can make time to do it.  That 
seems unlikely to the point of fantasy, alas.

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

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-03-22 13:29

Message:
Logged In: YES 
user_id=283405

The Python 2.2.1c1 installer for Windows still has this 
shortcoming: Even when doing an administrative install, 
shortcuts for Python are created in "Administrator"s 
profile, not "All Users".  However, various extensions, 
like wxpython, win32all, etc. seem to get this right.

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

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-02-22 12:19

Message:
Logged In: YES 
user_id=283405

This is also a problem under Windows 2000 Professional,
where I am actually logged in as "Administrator" and have
made sure it is a full administrative install I'm doing. 
Registry settings are properly made for everyone; it is just
the short cuts that don't appear.

I've been working around this by manually moving the program
group folder to "All Users" and changing the ACLs.  This
should be done before installing win32all, which will create
the program group under "All Users".

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

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



From noreply@sourceforge.net  Thu Apr  4 20:06:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 12:06:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E16tDV9-0001oe-00@usw-sf-web2.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 11:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 22:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

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

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



From noreply@sourceforge.net  Thu Apr  4 20:02:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 12:02:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-497854 ] Short-cuts missing for All Users
Message-ID: <E16tDRH-0001i7-00@usw-sf-web1.sourceforge.net>

Bugs item #497854, was opened at 2001-12-30 09:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=497854&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Martin v. L�wis (loewis)
Assigned to: Tim Peters (tim_one)
Summary: Short-cuts missing for All Users

Initial Comment:
Using the Windows installer of Python 2.2 on Windows XP
Professional, as a user "root" who is member of the
Administrator's group, performing an admin
installation, the Python 2.2 program group does not
show up in the start menu of other users.

The cause for this problem is that the installer puts
the shortcuts into \Documents and Settings\root\Start
Menu, not into \Documents and Settings\All Users\Start
Menu.

Notice that it is difficult to login as Administrator
on XP, since the Administrator account is not displayed
on the welcome screen (only if the old-style login
screen is selected). Even if installing Python as
Administrator, the shortcuts still end up in \Documents
and Settings\Administrator\Start Menu.

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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-04 15:02

Message:
Logged In: YES 
user_id=31435

Checked in on the trunk too.  Did all I can do here, so 
closing it.

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

Comment By: Tim Peters (tim_one)
Date: 2002-04-04 14:58

Message:
Logged In: YES 
user_id=31435

The install script had gotten lost in the maze of Wise 
system vrbls, so the same (or similar) problem was evident 
on Win2K.  The release22-maint branch contains a putative 
fix now, which works OK on Win2K, but I don't have access 
to an XP box and don't know whether "the rules" changed 
there.

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

Comment By: Tim Peters (tim_one)
Date: 2002-04-04 14:26

Message:
Logged In: YES 
user_id=31435

Changed to Windows/2.2.1 candidate, assigned to me, and 
boosted priority.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 15:55

Message:
Logged In: YES 
user_id=6380

Then at least let's remember to fix this in 2.3.

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

Comment By: Tim Peters (tim_one)
Date: 2002-03-22 14:02

Message:
Logged In: YES 
user_id=31435

Yes, the installer hasn't changed, and won't for 2.2.1 
unless somebody other than me can make time to do it.  That 
seems unlikely to the point of fantasy, alas.

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

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-03-22 13:29

Message:
Logged In: YES 
user_id=283405

The Python 2.2.1c1 installer for Windows still has this 
shortcoming: Even when doing an administrative install, 
shortcuts for Python are created in "Administrator"s 
profile, not "All Users".  However, various extensions, 
like wxpython, win32all, etc. seem to get this right.

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

Comment By: R. Lindsay Todd (rltodd)
Date: 2002-02-22 12:19

Message:
Logged In: YES 
user_id=283405

This is also a problem under Windows 2000 Professional,
where I am actually logged in as "Administrator" and have
made sure it is a full administrative install I'm doing. 
Registry settings are properly made for everyone; it is just
the short cuts that don't appear.

I've been working around this by manually moving the program
group folder to "All Users" and changing the ACLs.  This
should be done before installing win32all, which will create
the program group under "All Users".

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

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



From noreply@sourceforge.net  Thu Apr  4 20:57:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 12:57:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-539444 ] asyncore file wrapper & os.error
Message-ID: <E16tEIQ-0002Pi-00@usw-sf-web2.sourceforge.net>

Bugs item #539444, was opened at 2002-04-04 20:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore file wrapper & os.error

Initial Comment:
The file wrapper makes a file descriptor look like an
asycnore socket.  When its recv() method is invoked, it
calls os.read().

I use this in an application where os.read()
occasionally raises os.error (11, 'Resource temporarily
unavailable').  I think that asyncore should catch this
error and treat it just like EWOULDBLOCK.

But I'd like a second opinion.


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

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



From noreply@sourceforge.net  Thu Apr  4 21:08:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 13:08:10 -0800
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E16tESo-0005KJ-00@usw-sf-web3.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 01:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


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

>Comment By: dustin sallings (dustin)
Date: 2002-04-04 13:08

Message:
Logged In: YES 
user_id=43919

The XMLRPC request is clearly being logged as coming from my
cisco switch when it was, in fact, coming from localhost.

I can't find any clear documentation, but it seems that on
at least some systems gethostbyname and gethostbyaddr
reference the same static variable, so having separate locks
for each one (as seen in socketmodule.c) doesn't help
anything.  It's not so much that they're not reentrant, but
you can't call any combination of the two of them at the
same time.  Here's some test code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <assert.h>

int main(int argc, char **argv) {
    struct hostent *byaddr, *byname;
    unsigned int addr;
    struct sockaddr *sa = (struct sockaddr *)&addr;

    addr=1117120483;

    byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET);
    assert(byaddr);
    printf("byaddr:  %s\n", byaddr->h_name);

    byname=gethostbyname("mail.west.spy.net");
    assert(byname);
    printf("byname:  %s\n", byname->h_name);

    printf("\nReprinting:\n\n");

    printf("byaddr:  %s\n", byaddr->h_name);
    printf("byname:  %s\n", byname->h_name);
}


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 12:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

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

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



From noreply@sourceforge.net  Thu Apr  4 22:21:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 14:21:30 -0800
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E16tFbm-0006Ak-00@usw-sf-web4.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 01:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


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

>Comment By: dustin sallings (dustin)
Date: 2002-04-04 14:21

Message:
Logged In: YES 
user_id=43919

Looking over the code a bit more, I see that my last message
wasn't entirely accurate.  There does seem to be only one
lock for both gethostbyname and gethostbyaddr
(gethostbyname_lock is used for both).

This is a pretty simple test that illustrates the problem
I'm seeing.  My previous work was on my OS X machine, but
this is Python 2.2 (#3, Mar  6 2002, 18:30:37) [C] on irix6.

#!/usr/bin/env python
#
# Copyright (c) 2002  Dustin Sallings <dustin@spy.net>
# $Id$

import threading
import socket
import time

class ResolveMe(threading.Thread):

    hosts=['propaganda.spy.net', 'bleu.west.spy.net',
'mail.west.spy.net']

    def __init__(self):
        threading.Thread.__init__(self)
        self.setDaemon(1)

    def run(self):
        # Run 100 times
        for i in range(100):
            for h in self.hosts:
                nrv=socket.gethostbyname_ex(h)
                arv=socket.gethostbyaddr(nrv[2][0])

                try:
                    # Verify the hostname is correct
                    assert(h==nrv[0])
                    # Verify the two hostnames match
                    assert(nrv[0]==arv[0])
                    # Verify the two addresses match
                    assert(nrv[2]==arv[2])
                except AssertionError:
                    print "Failed!  Checking " + `h` + "
got, " \
                        + `nrv` + " and " + `arv`

if __name__=='__main__':
    for i in range(1,10):
        print "Starting " + `i` + " threads."
        threads=[]
        for n in range(i):
            rm=ResolveMe()
            rm.start()
            threads.append(rm)
        for t in threads:
            t.join()
        print `i` + " threads complete."
    time.sleep(60)

The output looks like this:

verde:/tmp 190> ./pytest.py
Starting 1 threads.
1 threads complete.
Starting 2 threads.
Failed!  Checking 'propaganda.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])
Failed!  Checking 'bleu.west.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])

[...]

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

Comment By: dustin sallings (dustin)
Date: 2002-04-04 13:08

Message:
Logged In: YES 
user_id=43919

The XMLRPC request is clearly being logged as coming from my
cisco switch when it was, in fact, coming from localhost.

I can't find any clear documentation, but it seems that on
at least some systems gethostbyname and gethostbyaddr
reference the same static variable, so having separate locks
for each one (as seen in socketmodule.c) doesn't help
anything.  It's not so much that they're not reentrant, but
you can't call any combination of the two of them at the
same time.  Here's some test code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <assert.h>

int main(int argc, char **argv) {
    struct hostent *byaddr, *byname;
    unsigned int addr;
    struct sockaddr *sa = (struct sockaddr *)&addr;

    addr=1117120483;

    byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET);
    assert(byaddr);
    printf("byaddr:  %s\n", byaddr->h_name);

    byname=gethostbyname("mail.west.spy.net");
    assert(byname);
    printf("byname:  %s\n", byname->h_name);

    printf("\nReprinting:\n\n");

    printf("byaddr:  %s\n", byaddr->h_name);
    printf("byname:  %s\n", byname->h_name);
}


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 12:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

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

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



From noreply@sourceforge.net  Fri Apr  5 00:46:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 16:46:31 -0800
Subject: [Python-bugs-list] [ python-Bugs-513572 ] isdir behavior getting odder on UNC path
Message-ID: <E16tHs7-0007kZ-00@usw-sf-web3.sourceforge.net>

Bugs item #513572, was opened at 2002-02-06 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
>Assigned to: Mark Hammond (mhammond)
Summary: isdir behavior getting odder on UNC path

Initial Comment:
It's been documented in earlier version of Python on 
windows that os.path.isdir returns true on a UNC 
directory only if there was an extra backslash at the 
end of the argument.  In Python2.2 (at least on 
windows 2000) it appears that *TWO* extra backslashes 
are needed.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>>
>>> import os
>>> os.path.isdir('\\trainer\island')
0
>>> os.path.isdir('\\trainer\island\')
0
>>> os.path.isdir('\\trainer\island\\')
1
>>>

In a perfect world, the first call should return 1, 
but never has.  In older versions of python, the 
second returned 1, but no longer.

In limited tests, appending 2 or more backslashes to 
the end of any pathname returns the correct answer in 
both isfile and isdir.


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

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-05 10:46

Message:
Logged In: YES 
user_id=14198

Sorry - I missed this bug.  It is not that I wasn't paying
attention, but rather that SF's Tracker didn't get my
attention :(  Have I mentioned how much I have SF and love
Bugzilla yet? :)

I quite like Tim's algorithm.  One extra stat in that case
is OK IMO.  I can't imagine too many speed sensitive bits of
code that continuously check for a non-existent directory.

Everyone still OK with that?

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

Comment By: Trent Mick (tmick)
Date: 2002-04-05 04:08

Message:
Logged In: YES 
user_id=34892

I have struggled with this too. Currently I tend to use 
this _isdir(). Hopefully this is helpful.

def _isdir(dirname):
    """os.path.isdir() doesn't work for UNC mount points. 
Fake it.
    
    # For an existing mount point
    # (want: _isdir() == 1)
    os.path.ismount(r"\crimper\apps") -> 1
    os.path.exists(r"\crimper\apps") -> 0
    os.path.isdir(r"\crimper\apps") -> 0
    os.listdir(r"\crimper\apps") -> [...contents...]
    # For a non-existant mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\foo") -> 1
    os.path.exists(r"\crimper\foo") -> 0
    os.path.isdir(r"\crimper\foo") -> 0
    os.listdir(r"\crimper\foo") -> WindowsError
    # For an existing dir under a mount point
    # (want: _isdir() == 1)
    os.path.mount(r"\crimper\apps\Komodo") -> 0
    os.path.exists(r"\crimper\apps\Komodo") -> 1
    os.path.isdir(r"\crimper\apps\Komodo") -> 1
    os.listdir(r"\crimper\apps\Komodo") -> [...contents...]
    # For a non-existant dir/file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\foo") -> 0
    os.path.exists(r"\crimper\apps\foo") -> 0
    os.path.isdir(r"\crimper\apps\foo") -> 0
    os.listdir(r"\crimper\apps\foo") -> []  # as if empty 
contents
    # For an existing file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\Komodo\exists.txt") -> 
0
    os.path.exists(r"\crimper\apps\Komodo\exists.txt") -> 1
    os.path.isdir(r"\crimper\apps\Komodo\exists.txt") -> 0
    os.listdir(r"\crimper\apps\Komodo\exists.txt") -> 
WindowsError
    """
    if sys.platform[:3] == 'win' and dirname[:2] == r'\':
        if os.path.exists(dirname):
            return os.path.isdir(dirname)
        try:
            os.listdir(dirname)
        except WindowsError:
            return 0
        else:
            return os.path.ismount(dirname)
    else:
        return os.path.isdir(dirname)



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

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 20:03

Message:
Logged In: YES 
user_id=31435

Gordon, none of those are UNC roots -- they follow the 
rules exactly as stated for non-UNC paths:  MS stat() 
recognizes \ME\E\java if and only if there's no trailing 
backslash.  That's why your first example succeeds.  The 
complication is that Python removes one trailing 
backslash "by magic" unless the path "looks like a root", 
and none of these do.  That's why your third example 
works.  Your second and fourth examples fail because you 
specified two trailing backslashes in those, and Python 
only removes one of them by magic.

An example of "a UNC root" would be \ME\E.  The MS stat() 
recognizes a root directory if and only if it *does* have a 
trailing backslash, and Python's magical backslash removal 
doesn't know UNC roots from a Euro symbol.  So the only way 
to get Python's isdir() (etc) to recognize \ME\E is to 
follow it with two backslashes, one because Python strips 
one away (due to not realizing "it looks like a root"), and 
another else MS stat() refuses to recognize it.

Anyway, I'm unassigning this now, cuz MarkH isn't paying 
any attentino.  If someone wants to write a pile of tedious 
code to "recognize a UNC root when it sees one", I'd accept 
the patch.  I doubt I'll get it to it myself in this 
lifetime.

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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-08 02:31

Message:
Logged In: YES 
user_id=4923

Data point:
 run on a win2k box, where \ME is an NT box
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.isdir(r"\ME\E\java")
1
>>> os.path.isdir(r"\ME\E\java\")
0
>>> os.path.isdir("\\ME\E\java\")
1
>>> os.path.isdir("\\ME\E\java\\")
0


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 19:28

Message:
Logged In: YES 
user_id=31435

Mark, what do you think about a different approach here?

1. Leave the string alone and *try* stat.  If it   
succeeds, great, we're done.

2. Else if the string doesn't have a trailing (back)slash, 
append one and try again.  Win or lose, that's the end.

3. Else the string does have a trailing (back)slash.  If 
the string has more than one character, strip a trailing 
(back)slash and try again.  Win or lose, that's the end.

4. Else the string is a single (back)slash, yet stat() 
failed.  This shouldn't be possible.

It doubles the number of stats in cases where the file path 
doesn't correspond to anything that exists.  OTOH, MS's 
(back)slash rules are undocumented and incomprehensible 
(read their implementation of stat() for the whole truth -- 
we're not out-thinking lots of it now, and the gimmick 
added after 1.5.2 to out-think part of it is at least 
breaking Gary's thoroughly sensible use).

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

Comment By: Gary Herron (herron)
Date: 2002-02-11 19:03

Message:
Logged In: YES 
user_id=395736

Sorry, but I don't have much of an idea which versions I 
was refering to.  I picked up the idea of an extra 
backslashes in a faq from a web site, the search for which 
I can't seem to reproduce.  It claimed one backslash was 
enough, but did not specify a python version.  It *might* 
have been old enough to be pre 1.5.2.
 
The two versions I can test are 1.5.1 (where one backslash 
is enough) and 2.2 (where two are required).  This seems 
to me to support (or at least not contradict) Tim's 
hypothesis.

Gary


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 05:57

Message:
Logged In: YES 
user_id=31435

Gary, exactly what do you mean by "older versions of 
Python"?  That is, specifically which versions?

The Microsoft stat() function is extremely picky about 
trailing (back)slashes.  For example, if you have a 
directory c:/python, and pass "c:/python/" to the MS stat
(), it claims no such thing exists.  This isn't documented 
by MS, but that's how it works:  a trailing (back)slash is 
required if and only if the path passed in "is a root".  So 
MS stat() doesn't understand "/python/", and doesn't 
understand "d:" either.  The former doesn't tolerate a 
(back)slash, while the latter requires one.

This is impossible for people to keep straight, so after 
1.5.2 Python started removing (back)slashes on its own to 
make MS stat() happy.  The code currently leaves a trailing 
(back)slash alone if and only if one exists, and in 
addition of these obtains:

1) The (back)slash is the only character in the path.
or
2) The path has 3 characters, and the middle one is a colon.

UNC roots don't fit either of those, so do get one (back)
slash chopped off.  However, just as for any other roots, 
the MS stat() refuses to recognize them as valid unless 
they do have a trailing (back)slash.  Indeed, the last time 
I applied a contributed patch to this code, I added a

/* XXX UNC root drives should also be exempted? */

comment there.

However, this explanation doesn't make sense unless by 
"older versions of Python" you mean nothing more recent 
than 1.5.2.  If I'm understanding the source of the 
problem, it should exist in all Pythons after 1.5.2.  So if 
you don't see the same problem in 1.6, 2.0 or 2.1, I'm on 
the wrong track.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-09 10:33

Message:
Logged In: YES 
user_id=31435

BTW, it occurs to me that this *may* be a consequence of 
whatever was done in 2.2 to encode/decode filename strings 
for system calls on Windows.  I didn't follow that, and 
Mark may be the only one who fully understands the details.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-09 10:17

Message:
Logged In: YES 
user_id=31435

Here's the implementation of Windows isdir():

def isdir(path):
.    """Test whether a path is a directory"""
.    try:
.        st = os.stat(path)
.    except os.error:
.        return 0
.    return stat.S_ISDIR(st[stat.ST_MODE])

That is, we return whatever Microsoft's stat() tells us, 
and our code is the same in 2.2 as in 2.1.  I don't have 
Win2K here, and my Win98 box isn't on a Windows network so 
I can't even try real UNC paths here.  Reassigning to MarkH 
in case he can do better on either count.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-09 09:05

Message:
Logged In: YES 
user_id=6380

Tim, I hate to do this to you, but you're the only person I
trust with researching this. (My laptop is currently off the
net again. :-( )


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

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



From noreply@sourceforge.net  Fri Apr  5 01:51:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 04 Apr 2002 17:51:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-513572 ] isdir behavior getting odder on UNC path
Message-ID: <E16tItM-0005h8-00@usw-sf-web1.sourceforge.net>

Bugs item #513572, was opened at 2002-02-05 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Mark Hammond (mhammond)
Summary: isdir behavior getting odder on UNC path

Initial Comment:
It's been documented in earlier version of Python on 
windows that os.path.isdir returns true on a UNC 
directory only if there was an extra backslash at the 
end of the argument.  In Python2.2 (at least on 
windows 2000) it appears that *TWO* extra backslashes 
are needed.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>>
>>> import os
>>> os.path.isdir('\\trainer\island')
0
>>> os.path.isdir('\\trainer\island\')
0
>>> os.path.isdir('\\trainer\island\\')
1
>>>

In a perfect world, the first call should return 1, 
but never has.  In older versions of python, the 
second returned 1, but no longer.

In limited tests, appending 2 or more backslashes to 
the end of any pathname returns the correct answer in 
both isfile and isdir.


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

>Comment By: Tim Peters (tim_one)
Date: 2002-04-04 20:51

Message:
Logged In: YES 
user_id=31435

Nice to see you, Mark!  If you want to pursue this, the 
caution I had about my idea, but forgot to write down, is 
that Python does lots of stats during imports, and 
especially stats on things that usually don't exist (is it 
there with a .pyd suffix?  a .dll suffix?  a .py suffix?  
a .pyw suffix?  a .pyc suffix?).  If the idea has a bad 
effect on startup time, that may kill it; startup time is 
already a sore point for some.  OTOH, on Windows we should 
really, say, be using FindFirstFile() with a wildcard 
extension for that purpose anyway.

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

Comment By: Mark Hammond (mhammond)
Date: 2002-04-04 19:46

Message:
Logged In: YES 
user_id=14198

Sorry - I missed this bug.  It is not that I wasn't paying
attention, but rather that SF's Tracker didn't get my
attention :(  Have I mentioned how much I have SF and love
Bugzilla yet? :)

I quite like Tim's algorithm.  One extra stat in that case
is OK IMO.  I can't imagine too many speed sensitive bits of
code that continuously check for a non-existent directory.

Everyone still OK with that?

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

Comment By: Trent Mick (tmick)
Date: 2002-04-04 13:08

Message:
Logged In: YES 
user_id=34892

I have struggled with this too. Currently I tend to use 
this _isdir(). Hopefully this is helpful.

def _isdir(dirname):
    """os.path.isdir() doesn't work for UNC mount points. 
Fake it.
    
    # For an existing mount point
    # (want: _isdir() == 1)
    os.path.ismount(r"\crimper\apps") -> 1
    os.path.exists(r"\crimper\apps") -> 0
    os.path.isdir(r"\crimper\apps") -> 0
    os.listdir(r"\crimper\apps") -> [...contents...]
    # For a non-existant mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\foo") -> 1
    os.path.exists(r"\crimper\foo") -> 0
    os.path.isdir(r"\crimper\foo") -> 0
    os.listdir(r"\crimper\foo") -> WindowsError
    # For an existing dir under a mount point
    # (want: _isdir() == 1)
    os.path.mount(r"\crimper\apps\Komodo") -> 0
    os.path.exists(r"\crimper\apps\Komodo") -> 1
    os.path.isdir(r"\crimper\apps\Komodo") -> 1
    os.listdir(r"\crimper\apps\Komodo") -> [...contents...]
    # For a non-existant dir/file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\foo") -> 0
    os.path.exists(r"\crimper\apps\foo") -> 0
    os.path.isdir(r"\crimper\apps\foo") -> 0
    os.listdir(r"\crimper\apps\foo") -> []  # as if empty 
contents
    # For an existing file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\Komodo\exists.txt") -> 
0
    os.path.exists(r"\crimper\apps\Komodo\exists.txt") -> 1
    os.path.isdir(r"\crimper\apps\Komodo\exists.txt") -> 0
    os.listdir(r"\crimper\apps\Komodo\exists.txt") -> 
WindowsError
    """
    if sys.platform[:3] == 'win' and dirname[:2] == r'\':
        if os.path.exists(dirname):
            return os.path.isdir(dirname)
        try:
            os.listdir(dirname)
        except WindowsError:
            return 0
        else:
            return os.path.ismount(dirname)
    else:
        return os.path.isdir(dirname)



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

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 04:03

Message:
Logged In: YES 
user_id=31435

Gordon, none of those are UNC roots -- they follow the 
rules exactly as stated for non-UNC paths:  MS stat() 
recognizes \ME\E\java if and only if there's no trailing 
backslash.  That's why your first example succeeds.  The 
complication is that Python removes one trailing 
backslash "by magic" unless the path "looks like a root", 
and none of these do.  That's why your third example 
works.  Your second and fourth examples fail because you 
specified two trailing backslashes in those, and Python 
only removes one of them by magic.

An example of "a UNC root" would be \ME\E.  The MS stat() 
recognizes a root directory if and only if it *does* have a 
trailing backslash, and Python's magical backslash removal 
doesn't know UNC roots from a Euro symbol.  So the only way 
to get Python's isdir() (etc) to recognize \ME\E is to 
follow it with two backslashes, one because Python strips 
one away (due to not realizing "it looks like a root"), and 
another else MS stat() refuses to recognize it.

Anyway, I'm unassigning this now, cuz MarkH isn't paying 
any attentino.  If someone wants to write a pile of tedious 
code to "recognize a UNC root when it sees one", I'd accept 
the patch.  I doubt I'll get it to it myself in this 
lifetime.

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

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 10:31

Message:
Logged In: YES 
user_id=4923

Data point:
 run on a win2k box, where \ME is an NT box
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.isdir(r"\ME\E\java")
1
>>> os.path.isdir(r"\ME\E\java\")
0
>>> os.path.isdir("\\ME\E\java\")
1
>>> os.path.isdir("\\ME\E\java\\")
0


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 03:28

Message:
Logged In: YES 
user_id=31435

Mark, what do you think about a different approach here?

1. Leave the string alone and *try* stat.  If it   
succeeds, great, we're done.

2. Else if the string doesn't have a trailing (back)slash, 
append one and try again.  Win or lose, that's the end.

3. Else the string does have a trailing (back)slash.  If 
the string has more than one character, strip a trailing 
(back)slash and try again.  Win or lose, that's the end.

4. Else the string is a single (back)slash, yet stat() 
failed.  This shouldn't be possible.

It doubles the number of stats in cases where the file path 
doesn't correspond to anything that exists.  OTOH, MS's 
(back)slash rules are undocumented and incomprehensible 
(read their implementation of stat() for the whole truth -- 
we're not out-thinking lots of it now, and the gimmick 
added after 1.5.2 to out-think part of it is at least 
breaking Gary's thoroughly sensible use).

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

Comment By: Gary Herron (herron)
Date: 2002-02-11 03:03

Message:
Logged In: YES 
user_id=395736

Sorry, but I don't have much of an idea which versions I 
was refering to.  I picked up the idea of an extra 
backslashes in a faq from a web site, the search for which 
I can't seem to reproduce.  It claimed one backslash was 
enough, but did not specify a python version.  It *might* 
have been old enough to be pre 1.5.2.
 
The two versions I can test are 1.5.1 (where one backslash 
is enough) and 2.2 (where two are required).  This seems 
to me to support (or at least not contradict) Tim's 
hypothesis.

Gary


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

Comment By: Tim Peters (tim_one)
Date: 2002-02-10 13:57

Message:
Logged In: YES 
user_id=31435

Gary, exactly what do you mean by "older versions of 
Python"?  That is, specifically which versions?

The Microsoft stat() function is extremely picky about 
trailing (back)slashes.  For example, if you have a 
directory c:/python, and pass "c:/python/" to the MS stat
(), it claims no such thing exists.  This isn't documented 
by MS, but that's how it works:  a trailing (back)slash is 
required if and only if the path passed in "is a root".  So 
MS stat() doesn't understand "/python/", and doesn't 
understand "d:" either.  The former doesn't tolerate a 
(back)slash, while the latter requires one.

This is impossible for people to keep straight, so after 
1.5.2 Python started removing (back)slashes on its own to 
make MS stat() happy.  The code currently leaves a trailing 
(back)slash alone if and only if one exists, and in 
addition of these obtains:

1) The (back)slash is the only character in the path.
or
2) The path has 3 characters, and the middle one is a colon.

UNC roots don't fit either of those, so do get one (back)
slash chopped off.  However, just as for any other roots, 
the MS stat() refuses to recognize them as valid unless 
they do have a trailing (back)slash.  Indeed, the last time 
I applied a contributed patch to this code, I added a

/* XXX UNC root drives should also be exempted? */

comment there.

However, this explanation doesn't make sense unless by 
"older versions of Python" you mean nothing more recent 
than 1.5.2.  If I'm understanding the source of the 
problem, it should exist in all Pythons after 1.5.2.  So if 
you don't see the same problem in 1.6, 2.0 or 2.1, I'm on 
the wrong track.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 18:33

Message:
Logged In: YES 
user_id=31435

BTW, it occurs to me that this *may* be a consequence of 
whatever was done in 2.2 to encode/decode filename strings 
for system calls on Windows.  I didn't follow that, and 
Mark may be the only one who fully understands the details.

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

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 18:17

Message:
Logged In: YES 
user_id=31435

Here's the implementation of Windows isdir():

def isdir(path):
.    """Test whether a path is a directory"""
.    try:
.        st = os.stat(path)
.    except os.error:
.        return 0
.    return stat.S_ISDIR(st[stat.ST_MODE])

That is, we return whatever Microsoft's stat() tells us, 
and our code is the same in 2.2 as in 2.1.  I don't have 
Win2K here, and my Win98 box isn't on a Windows network so 
I can't even try real UNC paths here.  Reassigning to MarkH 
in case he can do better on either count.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 17:05

Message:
Logged In: YES 
user_id=6380

Tim, I hate to do this to you, but you're the only person I
trust with researching this. (My laptop is currently off the
net again. :-( )


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

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



From noreply@sourceforge.net  Fri Apr  5 08:56:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 00:56:48 -0800
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E16tPWa-0001mg-00@usw-sf-web1.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 11:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 10:56

Message:
Logged In: YES 
user_id=21627

Can you spot the error in the Python socket module? I still
fail to see our bug, and I would assume it is a C library
bug; I also cannot reproduce the problem on any of my machines.

Can you please report the settings of the various HAVE_
defines for irix?

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

Comment By: dustin sallings (dustin)
Date: 2002-04-05 00:21

Message:
Logged In: YES 
user_id=43919

Looking over the code a bit more, I see that my last message
wasn't entirely accurate.  There does seem to be only one
lock for both gethostbyname and gethostbyaddr
(gethostbyname_lock is used for both).

This is a pretty simple test that illustrates the problem
I'm seeing.  My previous work was on my OS X machine, but
this is Python 2.2 (#3, Mar  6 2002, 18:30:37) [C] on irix6.

#!/usr/bin/env python
#
# Copyright (c) 2002  Dustin Sallings <dustin@spy.net>
# $Id$

import threading
import socket
import time

class ResolveMe(threading.Thread):

    hosts=['propaganda.spy.net', 'bleu.west.spy.net',
'mail.west.spy.net']

    def __init__(self):
        threading.Thread.__init__(self)
        self.setDaemon(1)

    def run(self):
        # Run 100 times
        for i in range(100):
            for h in self.hosts:
                nrv=socket.gethostbyname_ex(h)
                arv=socket.gethostbyaddr(nrv[2][0])

                try:
                    # Verify the hostname is correct
                    assert(h==nrv[0])
                    # Verify the two hostnames match
                    assert(nrv[0]==arv[0])
                    # Verify the two addresses match
                    assert(nrv[2]==arv[2])
                except AssertionError:
                    print "Failed!  Checking " + `h` + "
got, " \
                        + `nrv` + " and " + `arv`

if __name__=='__main__':
    for i in range(1,10):
        print "Starting " + `i` + " threads."
        threads=[]
        for n in range(i):
            rm=ResolveMe()
            rm.start()
            threads.append(rm)
        for t in threads:
            t.join()
        print `i` + " threads complete."
    time.sleep(60)

The output looks like this:

verde:/tmp 190> ./pytest.py
Starting 1 threads.
1 threads complete.
Starting 2 threads.
Failed!  Checking 'propaganda.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])
Failed!  Checking 'bleu.west.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])

[...]

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

Comment By: dustin sallings (dustin)
Date: 2002-04-04 23:08

Message:
Logged In: YES 
user_id=43919

The XMLRPC request is clearly being logged as coming from my
cisco switch when it was, in fact, coming from localhost.

I can't find any clear documentation, but it seems that on
at least some systems gethostbyname and gethostbyaddr
reference the same static variable, so having separate locks
for each one (as seen in socketmodule.c) doesn't help
anything.  It's not so much that they're not reentrant, but
you can't call any combination of the two of them at the
same time.  Here's some test code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <assert.h>

int main(int argc, char **argv) {
    struct hostent *byaddr, *byname;
    unsigned int addr;
    struct sockaddr *sa = (struct sockaddr *)&addr;

    addr=1117120483;

    byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET);
    assert(byaddr);
    printf("byaddr:  %s\n", byaddr->h_name);

    byname=gethostbyname("mail.west.spy.net");
    assert(byname);
    printf("byname:  %s\n", byname->h_name);

    printf("\nReprinting:\n\n");

    printf("byaddr:  %s\n", byaddr->h_name);
    printf("byname:  %s\n", byname->h_name);
}


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

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 22:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

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

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



From noreply@sourceforge.net  Fri Apr  5 09:00:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 01:00:13 -0800
Subject: [Python-bugs-list] [ python-Bugs-539444 ] asyncore file wrapper & os.error
Message-ID: <E16tPZt-0001p7-00@usw-sf-web1.sourceforge.net>

Bugs item #539444, was opened at 2002-04-04 22:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore file wrapper & os.error

Initial Comment:
The file wrapper makes a file descriptor look like an
asycnore socket.  When its recv() method is invoked, it
calls os.read().

I use this in an application where os.read()
occasionally raises os.error (11, 'Resource temporarily
unavailable').  I think that asyncore should catch this
error and treat it just like EWOULDBLOCK.

But I'd like a second opinion.


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

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 11:00

Message:
Logged In: YES 
user_id=21627

Can you report details of the file that returns EWOULDBLOCK?
This is not supposed to happen in applications of the
file_wrapper.

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

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



From noreply@sourceforge.net  Fri Apr  5 09:58:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 01:58:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-534669 ] remember to sync trees
Message-ID: <E16tQUK-0002UW-00@usw-sf-web1.sourceforge.net>

Bugs item #534669, was opened at 2002-03-25 13:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Michael Hudson (mwh)
Assigned to: Michael Hudson (mwh)
Summary: remember to sync trees

Initial Comment:
There are various fixes hitting the trunk that I'm not
considering for 2.2.1 that should probably be
considered for 2.2.2 if that ever happens.

Conversely there may be a few things I've fixed in the
22-maint branch that haven't been fixed on the trunk.

Don't forget these.

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

>Comment By: Michael Hudson (mwh)
Date: 2002-04-05 09:58

Message:
Logged In: YES 
user_id=6656

By looking at CVS logs?  I don't think there were very many
in fact (making StringIO work in --disable-unicode builds is
the only one I can actually remember).

I wasn't actually expecting *you* to do it at all -- I was
going to do a log scan after 2.2.1 was done with (there's a
reason I assigned this to myself).

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-04 17:01

Message:
Logged In: YES 
user_id=6380

How do I know what you fixed on the branch that should be
moved to the trunk?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534669&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 12:04:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 04:04:19 -0800
Subject: [Python-bugs-list] [ python-Bugs-462783 ] mmap bus error on linux
Message-ID: <E16tSS3-000404-00@usw-sf-web1.sourceforge.net>

Bugs item #462783, was opened at 2001-09-19 01:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=462783&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Dalke (dalke)
Assigned to: Nobody/Anonymous (nobody)
Summary: mmap bus error on linux

Initial Comment:
Not using the mmap module correctly can cause a
bus error under Linux.  This is a DEC, err, Compaq,
err, HP Alpha.

Here's a reproducible.  The problem appears to
be trying to mmap past the end of the file,
since putting in a "seek(0)" at the indicated
spot fixes things.


[dalke@pw600a src]$ ./python
Python 2.2a3+ (#6, Sep 17 2001, 05:05:24)
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] 
on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> file = open("test.dat", "w+")
>>> file.write("12345")
>>> import mmap
>>> # Forgot to do "file.seek(0)" here
>>> s = mmap.mmap(file.fileno(), 5)
>>> s[:5]
Bus error
[dalke@pw600a src]$ gdb ./python core
GNU gdb 19991004
Copyright 1998 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 "alpha-redhat-linux"...

warning: "/home/dalke/cvses/python/dist/src/core": 
ambiguous core format, 2 handle
rs match

warning: core file may not match specified executable 
file.
Core was generated by `perl'.
Program terminated with signal 8, Floating point 
exception.
#0  0x12004d7b8 in com_assert_stmt (c=0x0, n=0x0) at 
Python/compile.c:717
717             PyString_AsString(c->c_code)[c-
>c_nexti++] = byte;
(gdb) where
#0  0x12004d7b8 in com_assert_stmt (c=0x0, n=0x0) at 
Python/compile.c:717
(gdb)

                     Andrew
                     dalke@dalkescientific.com


----------------------------------------------------------------------

>Comment By: Andrew Dalke (dalke)
Date: 2002-04-05 05:04

Message:
Logged In: YES 
user_id=190903

The patch (against current CVS as of 2002 April 05)
passes the regression above, by raising an OSError
exception instead of giving a bus error, which is
the case without the patch.

I don't know enough about mmap, but the code and
explanation looks reasonable.  The exception text given
is good enough that I could figure out how to fix
my problem/misunderstanding.


The regression test tests this bug.  However, there
is a small typo in the patch to test_mmap.py.  Line
277 says

  ... not in ('win32'):
when it should say
  ... not in ('win32', ):


+1 on accepting the gist of this patch (with this fix).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-04 10:22

Message:
Logged In: YES 
user_id=6380

Note that Greg Green has uploaded a fix for this, patch
536578.

Andrew, can you test that patch?

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-10-22 17:37

Message:
Logged In: YES 
user_id=31392

I can reproduce the problem just fine on Intel Linux, but
I'm not really sure what we can do about it.  When I run the
test, I get a bus error when it tries to dereference
self->data in mmap_slice().  I don't see how we can prevent
the bus error short of checking the length of the file
before we map it.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=462783&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 12:15:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 04:15:49 -0800
Subject: [Python-bugs-list] [ python-Bugs-222395 ] readline() of codecs.StreamReader doesn't work for"utf-16le"
Message-ID: <E16tSdB-0006qX-00@usw-sf-web4.sourceforge.net>

Bugs item #222395, was opened at 2000-11-14 13:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=222395&group_id=5470

Category: Unicode
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: M.-A. Lemburg (lemburg)
>Summary: readline() of codecs.StreamReader doesn't work for"utf-16le"

Initial Comment:
I tried that in
BOTH Python 1.6 and Python 2.0
(operating system: Windows NT)

I wrote :

import codecs

fileName1 = "d:\sveta\unicode\try.txt"
(UTF16LE_encode, UTF16LE_decode,
 UTF16LE_streamreader, UTF16LE_streamwriter) = codecs.lookup('UTF-16LE')

output = UTF16LE_streamwriter( open(fileName1, 'wb') )
output.write(unicode('abc\n'))
output.write(unicode('def\n'))
output.close()

input = UTF16LE_streamreader( open(fileName1, 'rb') )
rl = input.readline()
print rl
input.close()

After I run it I got:

Traceback (most recent call last):
  File "d:\sveta\unicode\unicodecheck.py", line 13, in ?
    rl = input.readline()
  File "D:\Program Files\Python16\lib\codecs.py", line 250, in readline
    return self.decode(line)[0]
UnicodeError: UTF-16 decoding error: truncated data

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-05 12:15

Message:
Logged In: YES 
user_id=38388

I've checked in a patch which raises a NotImplementedError for 
.readline() on UTF-16, -LE, -BE.

This is not ideal, but more accurate than what was in place
before.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-05 16:45

Message:
Logged In: YES 
user_id=38388

Uhm... it does raise an exception ;-)

It is hard to fix this bug, since Unicode line breaking
is much more elaborate than standard C lib type
line breaking. The only way I see to handle this
properly is by introducing line buffering. However,
this can slow down the codec considerably.

Perhaps we should simply have the .readline()
method raise a NotImplementedError ?!

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 22:37

Message:
Logged In: YES 
user_id=31392

What should be done to fix this?  It sounds like things are 
plain broken.  If readline() doesn't work, it should raise 
an exception at the very least.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-11-14 14:43

Message:
Some background:

.readline() is implemented in the way it is because all other
techniques would require adding real buffering to the codec (AFAIK.
at least) and this is currently out of scope.

Besides, there is another problem:  line breaking in Unicode is much
more difficult to get right than for plain ASCII, since there are a lot
more line break characters to watch out for.

.readline() is currently relying on the underlying stream to do the
line breaking. Since this doesn't know anything about encodings
it will break lines at single bytes. As a result, the input data for the
codec is broken.

To correct the problem, one would have to write a true UTF-16 codec
which implements buffering. This should be doable in Python, e.g. see
how StringIO does it. The codec would then have to read the
input data in chunks of say 1024 bytes (must be even), then
pass the data through the codec and use the .splitlines() method on
the Unicode output. Data which is not on  the current line would
have to be buffered until the next call to .read() or .readline().

Unfortunately, this technique will also break .tell(), .truncate() and friends...
it's a mess.

An easy work-around is reading in the file as a whole and then
using .splitlines() to get at the lines.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-14 14:09

Message:
A little bit of debugging suggests that the StreamReader.readline() method is naive: it calls the underlying stream's readline() method. Since in the example code the underlying stream is a regular 8-bit file, this will return an odd number of byte in the example. Because of the little-endian encoding; the file contains these hex bytes: 61 00 62 00 63 00 0a 00 ... (0a being '\n').

I'm not familiar enough with this class to tell whether this is simply inappropriate use of StreamReader, or that this should be fixed. Maybe Marc-Andre can answer t least that question?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-11-14 14:02

Message:
One for Marc-Andre. (Unfortunately he's announced he'll be too busy to look at bugs this year, so if someone else has a smart idea, feel free to butt in!)

This was originally classified as a Windows bug, but it's platform independent (I can reproduce it on Linux as well).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=222395&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 12:21:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 04:21:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-539719 ] IBM's xlc compiler needs extra option
Message-ID: <E16tSiZ-0006uI-00@usw-sf-web4.sourceforge.net>

Bugs item #539719, was opened at 2002-04-05 12:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Martin v. L�wis (loewis)
Summary: IBM's xlc compiler needs extra option

Initial Comment:
An mx user complained to me about the xlc compiler
not handling forward declarations of static variables
correctly.

He found that with the added compiler option '-qlanglvl=ansi'
things work as expected. I currently don't have access to AIX,
but the option suggests that xlc then behaves in an ANSI
compatible way, which can't be that bad :-)

I'd suggest to add that option as default to Python builds,
so that all distutils based extensions automatically
pick it up for compilation (distutils reads the Python
Makefile for compiler settings).

Hope this one is right for you, Martin.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 15:24:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 07:24:39 -0800
Subject: [Python-bugs-list] [ python-Bugs-539719 ] IBM's xlc compiler needs extra option
Message-ID: <E16tVZv-0000Sz-00@usw-sf-web4.sourceforge.net>

Bugs item #539719, was opened at 2002-04-05 14:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Martin v. L�wis (loewis)
Summary: IBM's xlc compiler needs extra option

Initial Comment:
An mx user complained to me about the xlc compiler
not handling forward declarations of static variables
correctly.

He found that with the added compiler option '-qlanglvl=ansi'
things work as expected. I currently don't have access to AIX,
but the option suggests that xlc then behaves in an ANSI
compatible way, which can't be that bad :-)

I'd suggest to add that option as default to Python builds,
so that all distutils based extensions automatically
pick it up for compilation (distutils reads the Python
Makefile for compiler settings).

Hope this one is right for you, Martin.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 17:24

Message:
Logged In: YES 
user_id=21627

I don't want to change this, as I don't have access to an
AIX system, either; I might consider accepting a well-tested
patch, though. However,

http://usgibm.nersc.gov/vac/ref/compopts/ruoptlvl.htm

suggests that the default langlevel is ANSI, so I don't
trust the recommendation that adding it helps. Furthermore,
I'm concerned that something else may break, since the ANSI
settings of the compilers tend to disable a lot of useful
functions (which are merely POSIX instead of being even ANSI).

For your specific problem: Python.h offers the staticforward
define, which ought to correctly use static for each each
compiler.

If you think you need a platform-specific work-around, you
can add a pragma langlvl (see URL).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 16:44:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 08:44:23 -0800
Subject: [Python-bugs-list] [ python-Bugs-539444 ] asyncore file wrapper & os.error
Message-ID: <E16tWp5-00079b-00@usw-sf-web2.sourceforge.net>

Bugs item #539444, was opened at 2002-04-04 20:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore file wrapper & os.error

Initial Comment:
The file wrapper makes a file descriptor look like an
asycnore socket.  When its recv() method is invoked, it
calls os.read().

I use this in an application where os.read()
occasionally raises os.error (11, 'Resource temporarily
unavailable').  I think that asyncore should catch this
error and treat it just like EWOULDBLOCK.

But I'd like a second opinion.


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 16:44

Message:
Logged In: YES 
user_id=31392

It happens when the file is a pipe.

For details, see the ZEO bug report at
https://sourceforge.net/tracker/index.php?
func=detail&aid=536416&group_id=15628&atid=115628

I've included the traceback from that bug report, too.

error: uncaptured python exception, closing channel 
<select-trigger (pipe) at 81059cc> 
(exceptions.OSError:[Errno 11] Resource temporarily 
unavailable 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|poll|92] 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|handle_read_event|386] 
[/home/zope/opt/Python-2.1.2/lib/python2.1/site-
packages/ZEO/trigger.py|handle_read|95] 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|recv|338] 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|recv|520]) 
Exception exceptions.OSError: (9, 'Bad file 
descriptor') in <method trigger.__del__ of trigger 
instance at 0x81059cc> ignored 


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 09:00

Message:
Logged In: YES 
user_id=21627

Can you report details of the file that returns EWOULDBLOCK?
This is not supposed to happen in applications of the
file_wrapper.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 16:48:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 08:48:16 -0800
Subject: [Python-bugs-list] [ python-Bugs-539719 ] IBM's xlc compiler needs extra option
Message-ID: <E16tWsq-0007DJ-00@usw-sf-web1.sourceforge.net>

Bugs item #539719, was opened at 2002-04-05 12:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Martin v. L�wis (loewis)
Summary: IBM's xlc compiler needs extra option

Initial Comment:
An mx user complained to me about the xlc compiler
not handling forward declarations of static variables
correctly.

He found that with the added compiler option '-qlanglvl=ansi'
things work as expected. I currently don't have access to AIX,
but the option suggests that xlc then behaves in an ANSI
compatible way, which can't be that bad :-)

I'd suggest to add that option as default to Python builds,
so that all distutils based extensions automatically
pick it up for compilation (distutils reads the Python
Makefile for compiler settings).

Hope this one is right for you, Martin.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-05 16:48

Message:
Logged In: YES 
user_id=38388

Thanks for the URL.

I am already using the work-around in Python's header file,
but whether you define it or not doesn't make any difference
without the langlvl setting -- both ways turn out as error
with the compiler according to the user.

I'll forward the URL to the user and see whether he can make 
something of it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 15:24

Message:
Logged In: YES 
user_id=21627

I don't want to change this, as I don't have access to an
AIX system, either; I might consider accepting a well-tested
patch, though. However,

http://usgibm.nersc.gov/vac/ref/compopts/ruoptlvl.htm

suggests that the default langlevel is ANSI, so I don't
trust the recommendation that adding it helps. Furthermore,
I'm concerned that something else may break, since the ANSI
settings of the compilers tend to disable a lot of useful
functions (which are merely POSIX instead of being even ANSI).

For your specific problem: Python.h offers the staticforward
define, which ought to correctly use static for each each
compiler.

If you think you need a platform-specific work-around, you
can add a pragma langlvl (see URL).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 17:54:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 09:54:44 -0800
Subject: [Python-bugs-list] [ python-Bugs-539719 ] IBM's xlc compiler needs extra option
Message-ID: <E16tXvA-0002FK-00@usw-sf-web4.sourceforge.net>

Bugs item #539719, was opened at 2002-04-05 14:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Martin v. L�wis (loewis)
Summary: IBM's xlc compiler needs extra option

Initial Comment:
An mx user complained to me about the xlc compiler
not handling forward declarations of static variables
correctly.

He found that with the added compiler option '-qlanglvl=ansi'
things work as expected. I currently don't have access to AIX,
but the option suggests that xlc then behaves in an ANSI
compatible way, which can't be that bad :-)

I'd suggest to add that option as default to Python builds,
so that all distutils based extensions automatically
pick it up for compilation (distutils reads the Python
Makefile for compiler settings).

Hope this one is right for you, Martin.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 19:54

Message:
Logged In: YES 
user_id=21627

I would be curious then as to why the staticforward thing
fails for you. Can you please have your user produce
preprocessor out to see what it expands to? If it does not
expand to "extern", it would be interesting to find out
whether pyconfig.h detected BAD_STATIC_FORWARD. Perhaps this
is a version of Python where Python's config.h conflicts
with  the one in your package (i.e. pre-pyconfig.h?) 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-05 18:48

Message:
Logged In: YES 
user_id=38388

Thanks for the URL.

I am already using the work-around in Python's header file,
but whether you define it or not doesn't make any difference
without the langlvl setting -- both ways turn out as error
with the compiler according to the user.

I'll forward the URL to the user and see whether he can make 
something of it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 17:24

Message:
Logged In: YES 
user_id=21627

I don't want to change this, as I don't have access to an
AIX system, either; I might consider accepting a well-tested
patch, though. However,

http://usgibm.nersc.gov/vac/ref/compopts/ruoptlvl.htm

suggests that the default langlevel is ANSI, so I don't
trust the recommendation that adding it helps. Furthermore,
I'm concerned that something else may break, since the ANSI
settings of the compilers tend to disable a lot of useful
functions (which are merely POSIX instead of being even ANSI).

For your specific problem: Python.h offers the staticforward
define, which ought to correctly use static for each each
compiler.

If you think you need a platform-specific work-around, you
can add a pragma langlvl (see URL).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 18:11:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 10:11:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-539719 ] IBM's xlc compiler needs extra option
Message-ID: <E16tYBn-0002Ru-00@usw-sf-web4.sourceforge.net>

Bugs item #539719, was opened at 2002-04-05 12:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Martin v. L�wis (loewis)
Summary: IBM's xlc compiler needs extra option

Initial Comment:
An mx user complained to me about the xlc compiler
not handling forward declarations of static variables
correctly.

He found that with the added compiler option '-qlanglvl=ansi'
things work as expected. I currently don't have access to AIX,
but the option suggests that xlc then behaves in an ANSI
compatible way, which can't be that bad :-)

I'd suggest to add that option as default to Python builds,
so that all distutils based extensions automatically
pick it up for compilation (distutils reads the Python
Makefile for compiler settings).

Hope this one is right for you, Martin.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-05 18:11

Message:
Logged In: YES 
user_id=38388

Ok, I had a misunderstanding. What's really needed is not ansi, 
but extended language level, i.e. -qlanglvl=extended.

I'll add a #pragma to the mx extensions to address this.

Feel free to close the bug report.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 17:54

Message:
Logged In: YES 
user_id=21627

I would be curious then as to why the staticforward thing
fails for you. Can you please have your user produce
preprocessor out to see what it expands to? If it does not
expand to "extern", it would be interesting to find out
whether pyconfig.h detected BAD_STATIC_FORWARD. Perhaps this
is a version of Python where Python's config.h conflicts
with  the one in your package (i.e. pre-pyconfig.h?) 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-05 16:48

Message:
Logged In: YES 
user_id=38388

Thanks for the URL.

I am already using the work-around in Python's header file,
but whether you define it or not doesn't make any difference
without the langlvl setting -- both ways turn out as error
with the compiler according to the user.

I'll forward the URL to the user and see whether he can make 
something of it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 15:24

Message:
Logged In: YES 
user_id=21627

I don't want to change this, as I don't have access to an
AIX system, either; I might consider accepting a well-tested
patch, though. However,

http://usgibm.nersc.gov/vac/ref/compopts/ruoptlvl.htm

suggests that the default langlevel is ANSI, so I don't
trust the recommendation that adding it helps. Furthermore,
I'm concerned that something else may break, since the ANSI
settings of the compilers tend to disable a lot of useful
functions (which are merely POSIX instead of being even ANSI).

For your specific problem: Python.h offers the staticforward
define, which ought to correctly use static for each each
compiler.

If you think you need a platform-specific work-around, you
can add a pragma langlvl (see URL).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 18:13:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 10:13:48 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-539907 ] Tkinter lock conflicts extension widgets
Message-ID: <E16tYDc-0002TQ-00@usw-sf-web4.sourceforge.net>

Feature Requests item #539907, was opened at 2002-04-05 21:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=539907&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jyrki Alakuijala (jyrkialakuijala)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tkinter lock conflicts extension widgets

Initial Comment:
I need to access the thread lock in the _tkinter.c.

I have the following callgraph:
1) Python code
2) Tcl/Tk event loop (tkinter mainloop->)
3) Mouse callback to my own Tk extension widget
4) A lot of C++ stuff, which is also called directly
   from python
5) Python
6) Calling tk (which crashes due to the tk lock)

It is be possible to avoid this by creating a
tcl event with a python callback instead of calling
c++ from the tk extension widget. However, in a
painting program this is not ok for performance.
The real time capabilities of Python are pretty
bad and mouse movement becomes stopped for a few
milliseconds every now and then, leaving significant
discontinuities in the mouse tracking.

I have been able to have excellent behavior by
exposing the thread lock of _tkinter.c and release
the tk-lock when the call from the widget enters
the C++ side and lock it again when the C++ side
returns.

However, this is not possible with the standard
_tkinter.c, because the lock is a static member.
There are two possible solutions that would fix
my problems:

1) real-time python mode, that allows for turning
off GC and all other possible delays in the
interpreter. Then I could use the python for
managing tk events without mouse jumps.

2) exposing the thread lock with a simple api that
allows the use of LEAVE_TCL and ENTER_TCL outside
_tkinter.

The 2) is simpler. It consists of removing a keyword
"static" in _tkinter.c, while real-time python
is probably a 3.0 thing? Thus I would vote for a
fix in _tkinter.c for allowing me not to compile
my own python.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=539907&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 18:58:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 10:58:25 -0800
Subject: [Python-bugs-list] [ python-Bugs-539719 ] IBM's xlc compiler needs extra option
Message-ID: <E16tYun-00035n-00@usw-sf-web3.sourceforge.net>

Bugs item #539719, was opened at 2002-04-05 14:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: M.-A. Lemburg (lemburg)
Assigned to: Martin v. L�wis (loewis)
Summary: IBM's xlc compiler needs extra option

Initial Comment:
An mx user complained to me about the xlc compiler
not handling forward declarations of static variables
correctly.

He found that with the added compiler option '-qlanglvl=ansi'
things work as expected. I currently don't have access to AIX,
but the option suggests that xlc then behaves in an ANSI
compatible way, which can't be that bad :-)

I'd suggest to add that option as default to Python builds,
so that all distutils based extensions automatically
pick it up for compilation (distutils reads the Python
Makefile for compiler settings).

Hope this one is right for you, Martin.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 20:58

Message:
Logged In: YES 
user_id=21627

Ok, closing it.

I'm still confused as to why you need to adjust your code,
whereas the Python distribution, which uses the same
construct all over the place, apparently compiles successfully.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-05 20:11

Message:
Logged In: YES 
user_id=38388

Ok, I had a misunderstanding. What's really needed is not ansi, 
but extended language level, i.e. -qlanglvl=extended.

I'll add a #pragma to the mx extensions to address this.

Feel free to close the bug report.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 19:54

Message:
Logged In: YES 
user_id=21627

I would be curious then as to why the staticforward thing
fails for you. Can you please have your user produce
preprocessor out to see what it expands to? If it does not
expand to "extern", it would be interesting to find out
whether pyconfig.h detected BAD_STATIC_FORWARD. Perhaps this
is a version of Python where Python's config.h conflicts
with  the one in your package (i.e. pre-pyconfig.h?) 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-05 18:48

Message:
Logged In: YES 
user_id=38388

Thanks for the URL.

I am already using the work-around in Python's header file,
but whether you define it or not doesn't make any difference
without the langlvl setting -- both ways turn out as error
with the compiler according to the user.

I'll forward the URL to the user and see whether he can make 
something of it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 17:24

Message:
Logged In: YES 
user_id=21627

I don't want to change this, as I don't have access to an
AIX system, either; I might consider accepting a well-tested
patch, though. However,

http://usgibm.nersc.gov/vac/ref/compopts/ruoptlvl.htm

suggests that the default langlevel is ANSI, so I don't
trust the recommendation that adding it helps. Furthermore,
I'm concerned that something else may break, since the ANSI
settings of the compilers tend to disable a lot of useful
functions (which are merely POSIX instead of being even ANSI).

For your specific problem: Python.h offers the staticforward
define, which ought to correctly use static for each each
compiler.

If you think you need a platform-specific work-around, you
can add a pragma langlvl (see URL).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539719&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 19:31:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 11:31:08 -0800
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16tZQS-0003TY-00@usw-sf-web3.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 11:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 19:44:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 11:44:17 -0800
Subject: [Python-bugs-list] [ python-Feature Requests-495086 ] dict.popitem(key=None)
Message-ID: <E16tZdB-0000sU-00@usw-sf-web1.sourceforge.net>

Feature Requests item #495086, was opened at 2001-12-19 16:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Parisien (mathematician)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict.popitem(key=None)

Initial Comment:
Would it be possible to add an extra argument to the 
popitem method of DictionaryType so one can both 
retrieve a dict item and delete it at the same time? 
It would be so handy. Without the optional argument, 
it would work the same way dict.popitem works now

example::

>>> d = dict([(x,x) for x in range(10)])
>>> d
{0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 
8, 9: 9}
>>> d.popitem() # retrieves "random" key->val pair
(0, 0)
>>> d.popitem(4) # val=d[4]; del d[4]; return val
4
>>> d.popitem(6) # val=d[6]; del d[6]; return val 6
>>> d # missing keys [0, 4, 6]
{1: 1, 2: 2, 3: 3, 5: 5, 7: 7, 8: 8, 9: 9}





----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-04-05 19:44

Message:
Logged In: YES 
user_id=80475

A patch implementing this request is at:
http://sourceforge.net/tracker/index.php?
func=detail&aid=539949&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-02-20 08:22

Message:
Logged In: YES 
user_id=80475

Great idea!

The rationale is just like that for .setdefault() in 
providing a fast, simple, single method, single look-up 
replacement for a commonly used sequence of dictionary 
operations.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-17 00:17

Message:
Logged In: YES 
user_id=21627

Also requested as

http://sourceforge.net/tracker/index.php?func=detail&aid=504880&group_id=5470&atid=355470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 21:29:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 13:29:52 -0800
Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads
Message-ID: <E16tbHM-0004ks-00@usw-sf-web4.sourceforge.net>

Bugs item #539990, was opened at 2002-04-05 23:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pieter Claerhout (pclaerhout)
Assigned to: Jack Jansen (jackjansen)
Summary: Framework.mainloop() - multiple threads

Initial Comment:
I tried to use the threading module to start the XML 
RPC server in a different thread (xmlrpcServer itself 
also is a threaded piece of code), but that seems to 
conflict with the mainloop. If you start this 
application, it starts the thread, starts the mainloop 
and stays in there, once you finish the mainloop, the 
thread continues.

You've stumbled on a bug in Framework.mainloop(): it 
doesn't know anything about multiple threads. It gives 
time to other applications (by calling WaitNextEvent) 
but not to other threads within Python.

Also see
http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005416.html

and 

http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005428.html

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 21:31:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 13:31:24 -0800
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E16tbIq-00023J-00@usw-sf-web2.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 04:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-05 16:31

Message:
Logged In: YES 
user_id=31435

Just a reminder that the first thing to try on any SGI box 
is to recompile Python with optimization disabled.  I can't 
remember the last time we had "a Python bug" on SGI that 
wasn't traced to a compiler -O bug.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 03:56

Message:
Logged In: YES 
user_id=21627

Can you spot the error in the Python socket module? I still
fail to see our bug, and I would assume it is a C library
bug; I also cannot reproduce the problem on any of my machines.

Can you please report the settings of the various HAVE_
defines for irix?

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 17:21

Message:
Logged In: YES 
user_id=43919

Looking over the code a bit more, I see that my last message
wasn't entirely accurate.  There does seem to be only one
lock for both gethostbyname and gethostbyaddr
(gethostbyname_lock is used for both).

This is a pretty simple test that illustrates the problem
I'm seeing.  My previous work was on my OS X machine, but
this is Python 2.2 (#3, Mar  6 2002, 18:30:37) [C] on irix6.

#!/usr/bin/env python
#
# Copyright (c) 2002  Dustin Sallings <dustin@spy.net>
# $Id$

import threading
import socket
import time

class ResolveMe(threading.Thread):

    hosts=['propaganda.spy.net', 'bleu.west.spy.net',
'mail.west.spy.net']

    def __init__(self):
        threading.Thread.__init__(self)
        self.setDaemon(1)

    def run(self):
        # Run 100 times
        for i in range(100):
            for h in self.hosts:
                nrv=socket.gethostbyname_ex(h)
                arv=socket.gethostbyaddr(nrv[2][0])

                try:
                    # Verify the hostname is correct
                    assert(h==nrv[0])
                    # Verify the two hostnames match
                    assert(nrv[0]==arv[0])
                    # Verify the two addresses match
                    assert(nrv[2]==arv[2])
                except AssertionError:
                    print "Failed!  Checking " + `h` + "
got, " \
                        + `nrv` + " and " + `arv`

if __name__=='__main__':
    for i in range(1,10):
        print "Starting " + `i` + " threads."
        threads=[]
        for n in range(i):
            rm=ResolveMe()
            rm.start()
            threads.append(rm)
        for t in threads:
            t.join()
        print `i` + " threads complete."
    time.sleep(60)

The output looks like this:

verde:/tmp 190> ./pytest.py
Starting 1 threads.
1 threads complete.
Starting 2 threads.
Failed!  Checking 'propaganda.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])
Failed!  Checking 'bleu.west.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])

[...]

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 16:08

Message:
Logged In: YES 
user_id=43919

The XMLRPC request is clearly being logged as coming from my
cisco switch when it was, in fact, coming from localhost.

I can't find any clear documentation, but it seems that on
at least some systems gethostbyname and gethostbyaddr
reference the same static variable, so having separate locks
for each one (as seen in socketmodule.c) doesn't help
anything.  It's not so much that they're not reentrant, but
you can't call any combination of the two of them at the
same time.  Here's some test code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <assert.h>

int main(int argc, char **argv) {
    struct hostent *byaddr, *byname;
    unsigned int addr;
    struct sockaddr *sa = (struct sockaddr *)&addr;

    addr=1117120483;

    byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET);
    assert(byaddr);
    printf("byaddr:  %s\n", byaddr->h_name);

    byname=gethostbyname("mail.west.spy.net");
    assert(byname);
    printf("byname:  %s\n", byname->h_name);

    printf("\nReprinting:\n\n");

    printf("byaddr:  %s\n", byaddr->h_name);
    printf("byname:  %s\n", byname->h_name);
}


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 15:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 21:44:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 13:44:32 -0800
Subject: [Python-bugs-list] [ python-Bugs-539175 ] resolver not thread safe
Message-ID: <E16tbVY-0002HL-00@usw-sf-web1.sourceforge.net>

Bugs item #539175, was opened at 2002-04-04 01:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: dustin sallings (dustin)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolver not thread safe

Initial Comment:
I've got an application that does SNMP monitoring and
has a thread listening with SimpleXMLRPCServer for
remote control.  I noticed the XMLRPC listener logging
an incorrect address while snmp jobs were processing:

sw1.west.spy.net - - [04/Apr/2002 01:16:37] "POST /RPC2
HTTP/1.0" 200 -
localhost.west.spy.net - - [04/Apr/2002 01:16:43] "POST
/RPC2 HTTP/1.0" 200 -

sw1 is one of the machines that is being queried, but
the XMLRPC requests are happening over localhost.

gethostbyname() and gethostbyaddr() both return static
data, thus they aren't reentrant.

As a workaround, I copied socket.py to my working
directory and added the following to it:

try:
    import threading
except ImportError, ie:
    sys.stderr.write(str(ie) + "\n")

# mutex for DNS lookups
__dns_mutex=None
try:
    __dns_mutex=threading.Lock()
except NameError:
    pass

def __lock():
    if __dns_mutex!=None:
        __dns_mutex.acquire()
    
def __unlock():
    if __dns_mutex!=None:
        __dns_mutex.release()
    
def gethostbyaddr(addr):
    """Override gethostbyaddr to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyaddr(addr)
    finally:
        __unlock()
    return rv

def gethostbyname(name):
    """Override gethostbyname to try to get some thread
safety."""
    rv=None
    try:
        __lock()
        rv=_socket.gethostbyname(name)
    finally:
        __unlock()
    return rv


----------------------------------------------------------------------

>Comment By: dustin sallings (dustin)
Date: 2002-04-05 13:44

Message:
Logged In: YES 
user_id=43919

I first noticed this problem on my OS X box.

Since it's affecting me, it's not obvious to anyone else,
and I'm perfectly capable of fixing it myself, I'll try to
spend some time figuring out what's going on this weekend. 
It seems like it might be making a decision to not use the
lock at compile time.  I will investigate further and submit
a patch.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-05 13:31

Message:
Logged In: YES 
user_id=31435

Just a reminder that the first thing to try on any SGI box 
is to recompile Python with optimization disabled.  I can't 
remember the last time we had "a Python bug" on SGI that 
wasn't traced to a compiler -O bug.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 00:56

Message:
Logged In: YES 
user_id=21627

Can you spot the error in the Python socket module? I still
fail to see our bug, and I would assume it is a C library
bug; I also cannot reproduce the problem on any of my machines.

Can you please report the settings of the various HAVE_
defines for irix?

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 14:21

Message:
Logged In: YES 
user_id=43919

Looking over the code a bit more, I see that my last message
wasn't entirely accurate.  There does seem to be only one
lock for both gethostbyname and gethostbyaddr
(gethostbyname_lock is used for both).

This is a pretty simple test that illustrates the problem
I'm seeing.  My previous work was on my OS X machine, but
this is Python 2.2 (#3, Mar  6 2002, 18:30:37) [C] on irix6.

#!/usr/bin/env python
#
# Copyright (c) 2002  Dustin Sallings <dustin@spy.net>
# $Id$

import threading
import socket
import time

class ResolveMe(threading.Thread):

    hosts=['propaganda.spy.net', 'bleu.west.spy.net',
'mail.west.spy.net']

    def __init__(self):
        threading.Thread.__init__(self)
        self.setDaemon(1)

    def run(self):
        # Run 100 times
        for i in range(100):
            for h in self.hosts:
                nrv=socket.gethostbyname_ex(h)
                arv=socket.gethostbyaddr(nrv[2][0])

                try:
                    # Verify the hostname is correct
                    assert(h==nrv[0])
                    # Verify the two hostnames match
                    assert(nrv[0]==arv[0])
                    # Verify the two addresses match
                    assert(nrv[2]==arv[2])
                except AssertionError:
                    print "Failed!  Checking " + `h` + "
got, " \
                        + `nrv` + " and " + `arv`

if __name__=='__main__':
    for i in range(1,10):
        print "Starting " + `i` + " threads."
        threads=[]
        for n in range(i):
            rm=ResolveMe()
            rm.start()
            threads.append(rm)
        for t in threads:
            t.join()
        print `i` + " threads complete."
    time.sleep(60)

The output looks like this:

verde:/tmp 190> ./pytest.py
Starting 1 threads.
1 threads complete.
Starting 2 threads.
Failed!  Checking 'propaganda.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])
Failed!  Checking 'bleu.west.spy.net' got,
('mail.west.spy.net', [], ['66.149.231.226']) and
('mail.west.spy.net', [], ['66.149.231.226'])

[...]

----------------------------------------------------------------------

Comment By: dustin sallings (dustin)
Date: 2002-04-04 13:08

Message:
Logged In: YES 
user_id=43919

The XMLRPC request is clearly being logged as coming from my
cisco switch when it was, in fact, coming from localhost.

I can't find any clear documentation, but it seems that on
at least some systems gethostbyname and gethostbyaddr
reference the same static variable, so having separate locks
for each one (as seen in socketmodule.c) doesn't help
anything.  It's not so much that they're not reentrant, but
you can't call any combination of the two of them at the
same time.  Here's some test code:

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#include <assert.h>

int main(int argc, char **argv) {
    struct hostent *byaddr, *byname;
    unsigned int addr;
    struct sockaddr *sa = (struct sockaddr *)&addr;

    addr=1117120483;

    byaddr=gethostbyaddr(sa, sizeof(addr), AF_INET);
    assert(byaddr);
    printf("byaddr:  %s\n", byaddr->h_name);

    byname=gethostbyname("mail.west.spy.net");
    assert(byname);
    printf("byname:  %s\n", byname->h_name);

    printf("\nReprinting:\n\n");

    printf("byaddr:  %s\n", byaddr->h_name);
    printf("byname:  %s\n", byname->h_name);
}


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-04 12:06

Message:
Logged In: YES 
user_id=21627

I'm not sure what problem you are reporting. Python does not
attempt to invoke gethostbyname from two threads
simultaneously; this is prevented by the GIL.

On some systems, gethostname is reentrant (in the
gethostname_r incarnation); Python uses that where
available, and releases the GIL before calling it.

So I fail to see the bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539175&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 23:03:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 15:03:01 -0800
Subject: [Python-bugs-list] [ python-Bugs-536516 ] Docs for "es" and "et" confusing
Message-ID: <E16tcjV-000370-00@usw-sf-web2.sourceforge.net>

Bugs item #536516, was opened at 2002-03-28 17:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536516&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: Docs for "es" and "et" confusing

Initial Comment:
The extending/embedding manual seems to contain
confusing docs for the PyArg_Parse* format codes "es"
and "es#". For example, the description for "es" states
that it reads one variable (the encoding) and writes
two variables; but in fact, it appears that it writes
only one variable (the buffer). The number of variables
written is consistently one too large.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-05 18:03

Message:
Logged In: YES 
user_id=3066

Fixed; also moved this documentation from
Doc/ext/extending.tex (rev 1.17) to Doc/api/utilities.tex
(rev 1.4).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=536516&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 23:38:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 15:38:21 -0800
Subject: [Python-bugs-list] [ python-Bugs-518846 ] exception cannot be new-style class
Message-ID: <E16tdHh-0003Vs-00@usw-sf-web1.sourceforge.net>

Bugs item #518846, was opened at 2002-02-17 20:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Heino (magnusheino)
>Assigned to: Martin v. L�wis (loewis)
Summary: exception cannot be new-style class

Initial Comment:
[magnus@gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class foo(object):
...     pass
...
>>> raise foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
>>>


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 23:38

Message:
Logged In: YES 
user_id=31392

Martin, I think the attached patch is sufficient.  It checks
object type's for Py_TPFLAGS_HEAPTYPE.  I believe this is
the current way to spell "new-style class" although the
spelling is odd if that's the meaning <0.2 wink>.

If this patch makes sense to you, I'll flesh it out with
some test cases and check it in.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-17 23:44

Message:
Logged In: YES 
user_id=21627

Interesting. I think we need to deprecate, then remove
string exception before allowing arbitrary objects as
exceptions. Or we could allow strings to be caught either by
__builtin__.str, or by an identical string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 23:44:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 15:44:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-518846 ] exception cannot be new-style class
Message-ID: <E16tdNH-0006LJ-00@usw-sf-web4.sourceforge.net>

Bugs item #518846, was opened at 2002-02-17 21:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Heino (magnusheino)
Assigned to: Martin v. L�wis (loewis)
Summary: exception cannot be new-style class

Initial Comment:
[magnus@gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class foo(object):
...     pass
...
>>> raise foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
>>>


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 01:44

Message:
Logged In: YES 
user_id=21627

I thought the agreement was that this is not a bug: You
cannot really expect exceptions to work unless you inherit
from Exception.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-06 01:38

Message:
Logged In: YES 
user_id=31392

Martin, I think the attached patch is sufficient.  It checks
object type's for Py_TPFLAGS_HEAPTYPE.  I believe this is
the current way to spell "new-style class" although the
spelling is odd if that's the meaning <0.2 wink>.

If this patch makes sense to you, I'll flesh it out with
some test cases and check it in.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-18 00:44

Message:
Logged In: YES 
user_id=21627

Interesting. I think we need to deprecate, then remove
string exception before allowing arbitrary objects as
exceptions. Or we could allow strings to be caught either by
__builtin__.str, or by an identical string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 23:49:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 15:49:15 -0800
Subject: [Python-bugs-list] [ python-Bugs-518846 ] exception cannot be new-style class
Message-ID: <E16tdSF-0006On-00@usw-sf-web4.sourceforge.net>

Bugs item #518846, was opened at 2002-02-17 20:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Heino (magnusheino)
Assigned to: Martin v. L�wis (loewis)
Summary: exception cannot be new-style class

Initial Comment:
[magnus@gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class foo(object):
...     pass
...
>>> raise foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
>>>


----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 23:49

Message:
Logged In: YES 
user_id=31392

I don't realize there was agreement on this.  (I didn't 
follow the discussion closely.)  I don't understand why 
exceptions need to pass an isinstance() test on Exception.  
It didn't used to be this way, and it makes it hard to 
convert a module using __metaclass__ = type.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 23:44

Message:
Logged In: YES 
user_id=21627

I thought the agreement was that this is not a bug: You
cannot really expect exceptions to work unless you inherit
from Exception.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 23:38

Message:
Logged In: YES 
user_id=31392

Martin, I think the attached patch is sufficient.  It checks
object type's for Py_TPFLAGS_HEAPTYPE.  I believe this is
the current way to spell "new-style class" although the
spelling is odd if that's the meaning <0.2 wink>.

If this patch makes sense to you, I'll flesh it out with
some test cases and check it in.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-17 23:44

Message:
Logged In: YES 
user_id=21627

Interesting. I think we need to deprecate, then remove
string exception before allowing arbitrary objects as
exceptions. Or we could allow strings to be caught either by
__builtin__.str, or by an identical string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470



From noreply@sourceforge.net  Fri Apr  5 23:50:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 15:50:05 -0800
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16tdT3-0006PT-00@usw-sf-web4.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 21:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 01:50

Message:
Logged In: YES 
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Sat Apr  6 00:07:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 16:07:04 -0800
Subject: [Python-bugs-list] [ python-Bugs-518846 ] exception cannot be new-style class
Message-ID: <E16tdjU-0006cE-00@usw-sf-web3.sourceforge.net>

Bugs item #518846, was opened at 2002-02-17 15:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470

Category: Type/class unification
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Magnus Heino (magnusheino)
Assigned to: Martin v. L�wis (loewis)
Summary: exception cannot be new-style class

Initial Comment:
[magnus@gills magnus]$ python2.2
Python 2.2 (#1, Jan 26 2002, 14:27:24)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class foo(object):
...     pass
...
>>> raise foo()
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not foo
>>>


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-05 19:07

Message:
Logged In: YES 
user_id=6380

Sorry, HEAPTYPE is not the proper way to check for a
new-style class; it would exclude any new-style classes
defined by C code.  I also think that if you want to do this
it should done properly, and allow "raise C, C()" as well.

At best there's agreement that it's not worth trying to fix
Python to allow new-style classes as exceptions when we're
also trying to encourage that exceptions derive from
Exception.

If your module declares its exceptions as deriving from
Exception, a __metaclass__ = type should not have any effect
on the exceptions you declare.  So I'm not sure what your
problem is?

Here's another idea for a patch: a new-style class is
allowed as long as it also inherits from Exception.  (This
is possible!)

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 18:49

Message:
Logged In: YES 
user_id=31392

I don't realize there was agreement on this.  (I didn't 
follow the discussion closely.)  I don't understand why 
exceptions need to pass an isinstance() test on Exception.  
It didn't used to be this way, and it makes it hard to 
convert a module using __metaclass__ = type.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 18:44

Message:
Logged In: YES 
user_id=21627

I thought the agreement was that this is not a bug: You
cannot really expect exceptions to work unless you inherit
from Exception.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 18:38

Message:
Logged In: YES 
user_id=31392

Martin, I think the attached patch is sufficient.  It checks
object type's for Py_TPFLAGS_HEAPTYPE.  I believe this is
the current way to spell "new-style class" although the
spelling is odd if that's the meaning <0.2 wink>.

If this patch makes sense to you, I'll flesh it out with
some test cases and check it in.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-17 18:44

Message:
Logged In: YES 
user_id=21627

Interesting. I think we need to deprecate, then remove
string exception before allowing arbitrary objects as
exceptions. Or we could allow strings to be caught either by
__builtin__.str, or by an identical string.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518846&group_id=5470



From noreply@sourceforge.net  Sat Apr  6 00:17:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 16:17:35 -0800
Subject: [Python-bugs-list] [ python-Bugs-537450 ] Improper object initialization
Message-ID: <E16tdtf-0003vq-00@usw-sf-web2.sourceforge.net>

Bugs item #537450, was opened at 2002-03-31 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Improper object initialization

Initial Comment:
The descr tutorial specifies this rule:

  __new__ must return an object. There's nothing that
  requires that it return a new object that is an 
  instance of its class argument, although that is the 
  convention. If you return an existing object, the 
  constructor call will still call its __init__ 
  method. If you return an object of a different 
  class, its __init__ method will be called. 

I believe that this rule adds an unnecessary wart to 
the language, since it is not appropriate to call 
__init__, especially with the same arguments as 
__new__ on an 'unexpected' class returned by __new__.
It is simple enough to check that the resulting class 
is an instance of the expected class and to only then 
call __init__.  Otherwise, it should be assumed that 
__new__ is returning a fully constructed instance of 
another class.  In the rare and obscure case that one 
does wish to call __init__ on an object of a different 
class, then it may be done manually from within 
__new__.

So basically, my argument is for explicit versus
implicit semantics.  If __new__(cls) returns an 
instance where type(instance) is not cls, then
__init__ should not be called implicitly.  The
burden should be on the programmer to explicitly
ensure that the object is properly constructed.

Here is an example where the current rule results
in confusing and apparently random behavior
(if one doesn't have initimate knowledge of the
Python implementation, that is):

class Foo(object):
  def __new__(cls, x):
    if x == 0:
      return [1,2,3]
    if x == 1:
      return 1
    if x == 2:
      return (1,2,3)
    if x == 3:
      return '1'
    if x == 4:
      return {1:1,2:2,3:3}
    else:
      return super(cls, Foo).__new__(cls)

for i in range(6):
  try:
    print 'Foo(%d) =' % i,Foo(i)
  except:
    print 'Foo(%d) failed' % i

Which under Python 2.2 results in the following output:
  Foo(0) failed
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) failed
  Foo(5) = <__main__.Foo object at 0x8147f54>

Under the proposed new rule, the output would be
much more sensible:
  Foo(0) = [1,2,3]
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) = {1:1,2:2,3:3}
  Foo(5) = <__main__.Foo object at 0x8147f54>

If there is agreement on this issue, I will submit
a very simple patch to address this.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-05 19:17

Message:
Logged In: YES 
user_id=6380

I think Kevin's suggestion is about right, but I'd like to
add one twist: C.__new__ could return an instance of a
subclass of C, and in that case I think that the __init__
should still be called.  I'll see about a proper fix.

It's a clear semantic change, so I don't want to change this
in 2.2.x.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-01 09:43

Message:
Logged In: YES 
user_id=31435

Thanks, Kevin!  Assigned to Guido, under the theory that it 
lands on his plate sooner or later, and better sooner.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-04-01 09:17

Message:
Logged In: YES 
user_id=459565

Patch attached.  Passes Python descr tests and our 
extremely comprehensive in-house test suite that
tortures new-style classes in fairly gruesome ways.

Note: The ugly test to avoid calling tp_init on
      type(x) calls was intentionally left in the code, 
      to handle the case of calling type(type).
      It is very likely that the test is now unnecessary 
      and can be removed since calling tp_init on type
      objects should be safe, because they do not implement 
      their own tp_init.  However, for the sake of
      simplicity, I'm going to leave this additional 
      cleanup to Guido, or others.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470



From noreply@sourceforge.net  Sat Apr  6 01:07:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 17:07:07 -0800
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16tefb-0007FM-00@usw-sf-web3.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 10:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-25 12:02

Message:
Logged In: YES 
user_id=6380

Thanks. I'll have to think about this some more. I guess
it's easy enough to document that one can get performance
back by adding imp.PY_COMPILED to ok_file_types.

I've added a context diff (1) to make your patch less
suscpetible to going stale (2) to use a list comprehension
instead of filter().

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-25 09:06

Message:
Logged In: YES 
user_id=4771

Ok. This patch prevents the default module loader hooks 
used by RExec to locate any PY_COMPILED file. I added an 
ok_file_types tuple to RExec that lists the file types we 
should allow loading from -- currently only C_EXTENSION and 
PY_SOURCE.

I can add the above comment to the docs as well if the 
patch is acceptable.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-24 16:41

Message:
Logged In: YES 
user_id=6380

Good points, Armin. I guess it's unlikely to have a site
that allows limited read-write for some rexec clients and
read-only for others, but not impossible.

Could I twist your arm and ask for a patch?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-24 10:00

Message:
Logged In: YES 
user_id=4771

This could be defeated by a double attack: one rexec'ed 
code leaves a .pyc file in a temporary directory, and later 
another rexec'ed code in a fully read-only environment 
imports it. Or the buggy .pyc file was put there with some 
other tool (e.g. ftp to /incoming).

To be on the safe side one could completely disable loading 
from .pyc files. This has the advantage of automatically 
fixing the problem in all of the existing applications. I 
don't know if this would be a serious performance problem --
 rexec'ed code might generally don't import too much 
standard modules itself anyway. One could later add 
a "safe_path" list that lists the directories from which 
loading .pyc files is considered to be safe.

Note that the default hooks are such that no .pyc files are 
ever *written* by imports from rexec'ed code. One can thus 
guess that no existing rexec'ed code relies on .pyc file 
performance for anything but the standard library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 12:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-22 12:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470



From noreply@sourceforge.net  Sat Apr  6 01:05:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 17:05:51 -0800
Subject: [Python-bugs-list] [ python-Bugs-537450 ] Improper object initialization
Message-ID: <E16teeN-0007CD-00@usw-sf-web4.sourceforge.net>

Bugs item #537450, was opened at 2002-03-31 12:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Kevin Jacobs (jacobs99)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Improper object initialization

Initial Comment:
The descr tutorial specifies this rule:

  __new__ must return an object. There's nothing that
  requires that it return a new object that is an 
  instance of its class argument, although that is the 
  convention. If you return an existing object, the 
  constructor call will still call its __init__ 
  method. If you return an object of a different 
  class, its __init__ method will be called. 

I believe that this rule adds an unnecessary wart to 
the language, since it is not appropriate to call 
__init__, especially with the same arguments as 
__new__ on an 'unexpected' class returned by __new__.
It is simple enough to check that the resulting class 
is an instance of the expected class and to only then 
call __init__.  Otherwise, it should be assumed that 
__new__ is returning a fully constructed instance of 
another class.  In the rare and obscure case that one 
does wish to call __init__ on an object of a different 
class, then it may be done manually from within 
__new__.

So basically, my argument is for explicit versus
implicit semantics.  If __new__(cls) returns an 
instance where type(instance) is not cls, then
__init__ should not be called implicitly.  The
burden should be on the programmer to explicitly
ensure that the object is properly constructed.

Here is an example where the current rule results
in confusing and apparently random behavior
(if one doesn't have initimate knowledge of the
Python implementation, that is):

class Foo(object):
  def __new__(cls, x):
    if x == 0:
      return [1,2,3]
    if x == 1:
      return 1
    if x == 2:
      return (1,2,3)
    if x == 3:
      return '1'
    if x == 4:
      return {1:1,2:2,3:3}
    else:
      return super(cls, Foo).__new__(cls)

for i in range(6):
  try:
    print 'Foo(%d) =' % i,Foo(i)
  except:
    print 'Foo(%d) failed' % i

Which under Python 2.2 results in the following output:
  Foo(0) failed
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) failed
  Foo(5) = <__main__.Foo object at 0x8147f54>

Under the proposed new rule, the output would be
much more sensible:
  Foo(0) = [1,2,3]
  Foo(1) = 1
  Foo(2) = (1, 2, 3)
  Foo(3) = 1
  Foo(4) = {1:1,2:2,3:3}
  Foo(5) = <__main__.Foo object at 0x8147f54>

If there is agreement on this issue, I will submit
a very simple patch to address this.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-05 20:05

Message:
Logged In: YES 
user_id=6380

Fixed in CVS, using PyType_IsSubtype(obj->type, type).

Note that the exception for type(x) is still needed (the
test suite could have told you that).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-05 19:17

Message:
Logged In: YES 
user_id=6380

I think Kevin's suggestion is about right, but I'd like to
add one twist: C.__new__ could return an instance of a
subclass of C, and in that case I think that the __init__
should still be called.  I'll see about a proper fix.

It's a clear semantic change, so I don't want to change this
in 2.2.x.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-01 09:43

Message:
Logged In: YES 
user_id=31435

Thanks, Kevin!  Assigned to Guido, under the theory that it 
lands on his plate sooner or later, and better sooner.

----------------------------------------------------------------------

Comment By: Kevin Jacobs (jacobs99)
Date: 2002-04-01 09:17

Message:
Logged In: YES 
user_id=459565

Patch attached.  Passes Python descr tests and our 
extremely comprehensive in-house test suite that
tortures new-style classes in fairly gruesome ways.

Note: The ugly test to avoid calling tp_init on
      type(x) calls was intentionally left in the code, 
      to handle the case of calling type(type).
      It is very likely that the test is now unnecessary 
      and can be removed since calling tp_init on type
      objects should be safe, because they do not implement 
      their own tp_init.  However, for the sake of
      simplicity, I'm going to leave this additional 
      cleanup to Guido, or others.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537450&group_id=5470



From noreply@sourceforge.net  Sat Apr  6 07:31:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 05 Apr 2002 23:31:55 -0800
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16tkfz-0008Kf-00@usw-sf-web2.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 20:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 09:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-13 03:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 20:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 01:37:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 06 Apr 2002 17:37:26 -0800
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16u1cU-0005cs-00@usw-sf-web3.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: Rich Salz (rsalz)
Date: 2002-04-06 20:37

Message:
Logged In: YES 
user_id=36737

The original report described a test case; test/t3.py in the
ZSI package.  Following up on this, Dave Wallace has a short
example that crashes.  See his posting in to xml-sig, at
http://mail.python.org/pipermail/xml-sig/2002-April/007553.html


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 02:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-12 21:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 14:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 10:00:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 01:00:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-538827 ] Python open w/ MSVC6: bad error msgs
Message-ID: <E16u8Xd-0007Km-00@usw-sf-web2.sourceforge.net>

Bugs item #538827, was opened at 2002-04-03 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470

>Category: Windows
>Group: Platform-specific
Status: Open
Resolution: None
>Priority: 4
Submitted By: Greg Chapman (glchapman)
Assigned to: Tim Peters (tim_one)
Summary: Python open w/ MSVC6: bad error msgs

Initial Comment:
With the current Win32 build (actually, 2.2.1c1), you 
get the following behavior when feeding bad filenames 
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error 
ERROR_INVALID_NAME to EINVAL, and Python always treats 
this error as being related to the mode string.  It 
appears (from bug report 476593) that VC6 disagrees 
with GCC here; I don't know which compiler is right 
(actually, looking at the VC documentation for _open, 
it appears GCC is right).  At any rate, it appears 
Python cannot rely on EINVAL referring only to the 
mode string under Windows.

Interestingly, the current Python Win32 build also 
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen 
fails, but it does not set errno.  (You can see this 
in the openfile function in _OPEN.C in the VC6 CRT 
source).  It might be possible to use this behavior to 
produce more accurate error messages under Windows.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-07 05:00

Message:
Logged In: YES 
user_id=31435

Which version of Windows are you using?  Here on Win98SE, I 
get

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'
>>>

all the way back through Python 2.0.  Note that MS's error 
translation table (in DOSMAP.C) doesn't contain an entry 
for ERROR_INVALID_NAME, so the logic in _dosmaperr() would 
return EINVAL in that case (it can't dream up anything 
better to return).  The errors CreateFile *can* trigger 
aren't documented, and I expect they vary across Windows 
flavors (and that Win98SE triggers ERROR_FILE_NOT_FOUND in 
this case, which maps to ENOENT).

Note that MS doesn't catch all senseless mode strings 
either.  For example,

>>> open('wtf', 'w hi greg!')
<open file 'wtf', mode 'w hi greg!' at 0x00768F30>
>>>

If you want to create a patch to clean up MS's mess here, 
be my guest.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-03 12:15

Message:
Logged In: YES 
user_id=6656

Guess who gets to look at this one.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 10:03:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 01:03:53 -0800
Subject: [Python-bugs-list] [ python-Bugs-539444 ] asyncore file wrapper & os.error
Message-ID: <E16u8aX-0001mH-00@usw-sf-web4.sourceforge.net>

Bugs item #539444, was opened at 2002-04-04 22:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore file wrapper & os.error

Initial Comment:
The file wrapper makes a file descriptor look like an
asycnore socket.  When its recv() method is invoked, it
calls os.read().

I use this in an application where os.read()
occasionally raises os.error (11, 'Resource temporarily
unavailable').  I think that asyncore should catch this
error and treat it just like EWOULDBLOCK.

But I'd like a second opinion.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-07 11:03

Message:
Logged In: YES 
user_id=21627

I'm still uncertain what precisely was happening here. What
system was this on? On many systems, EAGAIN is EWOULDBLOCK;
if that is the case, adding EAGAIN to the places that
currently handle EWOULDBLOCK won't change anything. 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-05 18:44

Message:
Logged In: YES 
user_id=31392

It happens when the file is a pipe.

For details, see the ZEO bug report at
https://sourceforge.net/tracker/index.php?
func=detail&aid=536416&group_id=15628&atid=115628

I've included the traceback from that bug report, too.

error: uncaptured python exception, closing channel 
<select-trigger (pipe) at 81059cc> 
(exceptions.OSError:[Errno 11] Resource temporarily 
unavailable 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|poll|92] 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|handle_read_event|386] 
[/home/zope/opt/Python-2.1.2/lib/python2.1/site-
packages/ZEO/trigger.py|handle_read|95] 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|recv|338] 
[/home/zope/opt/Python-
2.1.2/lib/python2.1/asyncore.py|recv|520]) 
Exception exceptions.OSError: (9, 'Bad file 
descriptor') in <method trigger.__del__ of trigger 
instance at 0x81059cc> ignored 


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 11:00

Message:
Logged In: YES 
user_id=21627

Can you report details of the file that returns EWOULDBLOCK?
This is not supposed to happen in applications of the
file_wrapper.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539444&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 11:08:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 03:08:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-533625 ] rexec: potential security hole
Message-ID: <E16u9b3-0002IK-00@usw-sf-web3.sourceforge.net>

Bugs item #533625, was opened at 2002-03-22 15:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Guido van Rossum (gvanrossum)
Summary: rexec: potential security hole

Initial Comment:
The documentation of the restricted execution module, 
rexec, should make it clear that it is dangerous to 
allow the restricted code write into a directory that 
is included in sys.path. Indeed, I suspect that is it 
common to allow restricted code to write in the 
current directory (e.g. after a chdir() to a directory 
that contains only the files we want the restricted 
code to work on). But '' is in sys.path by default.

Attached is a script that uses this to perform the 
equivalent of an unmarshal of a code object (which is 
forbidden in restricted mode -- although it is clear 
to me why, it might not be obvious to someone not used 
to Python's internals and should be mentionned 
somewhere). The attached script writes and then import 
a .pyc file that defines a function whose bogus code 
(at least on 32-bit Unix machines with Python 2.2-2.3) 
returns the frame of the caller. This lets the 
restricted code access the original builtins.


----------------------------------------------------------------------

>Comment By: Armin Rigo (arigo)
Date: 2002-04-07 10:08

Message:
Logged In: YES 
user_id=4771

I uploaded a patch for the documentation.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-25 17:02

Message:
Logged In: YES 
user_id=6380

Thanks. I'll have to think about this some more. I guess
it's easy enough to document that one can get performance
back by adding imp.PY_COMPILED to ok_file_types.

I've added a context diff (1) to make your patch less
suscpetible to going stale (2) to use a list comprehension
instead of filter().

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-25 14:06

Message:
Logged In: YES 
user_id=4771

Ok. This patch prevents the default module loader hooks 
used by RExec to locate any PY_COMPILED file. I added an 
ok_file_types tuple to RExec that lists the file types we 
should allow loading from -- currently only C_EXTENSION and 
PY_SOURCE.

I can add the above comment to the docs as well if the 
patch is acceptable.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-24 21:41

Message:
Logged In: YES 
user_id=6380

Good points, Armin. I guess it's unlikely to have a site
that allows limited read-write for some rexec clients and
read-only for others, but not impossible.

Could I twist your arm and ask for a patch?

----------------------------------------------------------------------

Comment By: Armin Rigo (arigo)
Date: 2002-03-24 15:00

Message:
Logged In: YES 
user_id=4771

This could be defeated by a double attack: one rexec'ed 
code leaves a .pyc file in a temporary directory, and later 
another rexec'ed code in a fully read-only environment 
imports it. Or the buggy .pyc file was put there with some 
other tool (e.g. ftp to /incoming).

To be on the safe side one could completely disable loading 
from .pyc files. This has the advantage of automatically 
fixing the problem in all of the existing applications. I 
don't know if this would be a serious performance problem --
 rexec'ed code might generally don't import too much 
standard modules itself anyway. One could later add 
a "safe_path" list that lists the directories from which 
loading .pyc files is considered to be safe.

Note that the default hooks are such that no .pyc files are 
ever *written* by imports from rexec'ed code. One can thus 
guess that no existing rexec'ed code relies on .pyc file 
performance for anything but the standard library.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:53

Message:
Logged In: YES 
user_id=6380

Note that rexec as shipped doesn't allow writing any files,
so it's only a security hole in apps that modify open() to
allow writing in some directory. I guess the rexec import
code could be made aware of which directories are writable
and skip those if they appear on sys.path.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 17:50

Message:
Logged In: YES 
user_id=6380

Martin: I don't think so. Adding range check to the VM would
slow it down considerably, especially since it affects all
the "fast" opcodes. In order to make the VM totally robust,
you would also have to fix the various push and pop opcodes
(or the macros) to check for stack overflow and underflow as
well. For better or for worse, the assumption of the VM is
that the compiler generates "perfect" bytecode, and we do
*not* have a bytecode verifier like Java. For trusted code,
I don't mind. For untrusted code, rexec should disallow any
manipulation of code objects. 

Armin has found a real security hole -- fortunately the
default is not to allow writing at all, but in fact, having
any writable directories at all opens up the hole, since
restricted code can changes its own sys.path!!!

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-22 17:35

Message:
Logged In: YES 
user_id=21627

Isn't that a bug in LOAD_FAST?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533625&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 17:30:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 09:30:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-515745 ] Missing docs for module knee
Message-ID: <E16uFYP-0005Rp-00@usw-sf-web1.sourceforge.net>

Bugs item #515745, was opened at 2002-02-11 06:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470

Category: Demos and Tools
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Martin v. L�wis (loewis)
Summary: Missing docs for module knee

Initial Comment:
3.21.1 in the lib manual sez: "A more complete example 
that implements hierarchical module names and includes 
a reload() function can be found in the standard 
module knee (which is intended as an example only -- 
don't rely on any part of it being a standard 
interface)."

...but knee is not in the module list, though it 
appears to be in the distribution.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-07 18:30

Message:
Logged In: YES 
user_id=21627

knee.py is now moved to Demo/imputil.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 03:41

Message:
Logged In: YES 
user_id=6380

knee.py itself is mostly intended as documentation -- it's
working code that demonstrates how the import process works!

It's fine if it gets moved to the Demo directory.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-16 08:07

Message:
Logged In: YES 
user_id=31435

Sorry, I can't channel Guido here -- AFAICT, this is the 
first time I ever heard about knee!  Reassigned to Guido.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-02-14 18:24

Message:
Logged In: YES 
user_id=52572

If you move it, please change the docs so that it no longer 
says it's a standard module.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-14 18:04

Message:
Logged In: YES 
user_id=3066

Like it says, the knee module is supposed to be an example
only.  I don't think it should be included in the library at
all; it should be somewhere in Demo/.

I think Guido has resisted moving it before, but I don't
recall clearly.  I'll assign this to Tim since Guido's not
available now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 20:09:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 12:09:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-538827 ] Python open w/ MSVC6: bad error msgs
Message-ID: <E16uI2B-0001oy-00@usw-sf-web4.sourceforge.net>

Bugs item #538827, was opened at 2002-04-03 08:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 4
Submitted By: Greg Chapman (glchapman)
Assigned to: Tim Peters (tim_one)
Summary: Python open w/ MSVC6: bad error msgs

Initial Comment:
With the current Win32 build (actually, 2.2.1c1), you 
get the following behavior when feeding bad filenames 
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error 
ERROR_INVALID_NAME to EINVAL, and Python always treats 
this error as being related to the mode string.  It 
appears (from bug report 476593) that VC6 disagrees 
with GCC here; I don't know which compiler is right 
(actually, looking at the VC documentation for _open, 
it appears GCC is right).  At any rate, it appears 
Python cannot rely on EINVAL referring only to the 
mode string under Windows.

Interestingly, the current Python Win32 build also 
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen 
fails, but it does not set errno.  (You can see this 
in the openfile function in _OPEN.C in the VC6 CRT 
source).  It might be possible to use this behavior to 
produce more accurate error messages under Windows.



----------------------------------------------------------------------

>Comment By: Greg Chapman (glchapman)
Date: 2002-04-07 11:09

Message:
Logged In: YES 
user_id=86307

I'm using Windows 2000; I also just tested this on Windows 
XP Pro and got the same results (as on Windows 2000).

As far as a patch, the simplest thing might be to add an 
ifdef so that EINVAL is not treated as a special case when 
compiling with VC; this would revert to the behavior before 
November 2001 (i.e., the patch for bug 476593).  If this 
path is chosen, should there be a special define introduced 
for invalid use of EINVAL (I don't know if other C 
libraries have this problem), or should it simply refer to 
MSVC?

The above wouldn't fix the problem with MS's handling of 
invalid mode strings.  I had noticed that you could put 
anything in a mode string provided the first character was 
in [rwa].  How do other C libraries handle these kind of 
errors in mode strings?  I have the source to Borland C++ 
Builder 4.  It looks like it checks the entire mode string, 
but it also fails without setting errno if it finds any 
invalid characters.  Is fopen expected to set errno on 
failure?  (I note that neither the MS nor the Borland 
documentation for fopen refers to errno.)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-07 00:00

Message:
Logged In: YES 
user_id=31435

Which version of Windows are you using?  Here on Win98SE, I 
get

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'
>>>

all the way back through Python 2.0.  Note that MS's error 
translation table (in DOSMAP.C) doesn't contain an entry 
for ERROR_INVALID_NAME, so the logic in _dosmaperr() would 
return EINVAL in that case (it can't dream up anything 
better to return).  The errors CreateFile *can* trigger 
aren't documented, and I expect they vary across Windows 
flavors (and that Win98SE triggers ERROR_FILE_NOT_FOUND in 
this case, which maps to ENOENT).

Note that MS doesn't catch all senseless mode strings 
either.  For example,

>>> open('wtf', 'w hi greg!')
<open file 'wtf', mode 'w hi greg!' at 0x00768F30>
>>>

If you want to create a patch to clean up MS's mess here, 
be my guest.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-03 08:15

Message:
Logged In: YES 
user_id=6656

Guess who gets to look at this one.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 21:21:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 13:21:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-538827 ] Python open w/ MSVC6: bad error msgs
Message-ID: <E16uJ9s-0002dx-00@usw-sf-web4.sourceforge.net>

Bugs item #538827, was opened at 2002-04-03 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 4
Submitted By: Greg Chapman (glchapman)
Assigned to: Tim Peters (tim_one)
Summary: Python open w/ MSVC6: bad error msgs

Initial Comment:
With the current Win32 build (actually, 2.2.1c1), you 
get the following behavior when feeding bad filenames 
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error 
ERROR_INVALID_NAME to EINVAL, and Python always treats 
this error as being related to the mode string.  It 
appears (from bug report 476593) that VC6 disagrees 
with GCC here; I don't know which compiler is right 
(actually, looking at the VC documentation for _open, 
it appears GCC is right).  At any rate, it appears 
Python cannot rely on EINVAL referring only to the 
mode string under Windows.

Interestingly, the current Python Win32 build also 
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen 
fails, but it does not set errno.  (You can see this 
in the openfile function in _OPEN.C in the VC6 CRT 
source).  It might be possible to use this behavior to 
produce more accurate error messages under Windows.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-07 16:21

Message:
Logged In: YES 
user_id=31435

I'm afraid there are no answers to your questions short of 
doing an exhaustive study of each implementation of 
interest, and even then it hits a brick wall because Win32 
CreateFile() doesn't document its error conditions and its 
source code is secret.

I'm attaching a patch that should reliably distinguish 
between mode and filename errors across Windows flavors 
under MSVC, and that maps EINVALID to ENOENT on Windows 
(which may not be the best that *could* be done on Win2K, 
but Windows flavors are inconsistent here and Python has no 
idea which flavor of Win32 it's running under).  If that's 
good enough for you, I'll check it in,; else I'm inclined 
to close this as 3rdParty and Won'tFix.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-04-07 15:09

Message:
Logged In: YES 
user_id=86307

I'm using Windows 2000; I also just tested this on Windows 
XP Pro and got the same results (as on Windows 2000).

As far as a patch, the simplest thing might be to add an 
ifdef so that EINVAL is not treated as a special case when 
compiling with VC; this would revert to the behavior before 
November 2001 (i.e., the patch for bug 476593).  If this 
path is chosen, should there be a special define introduced 
for invalid use of EINVAL (I don't know if other C 
libraries have this problem), or should it simply refer to 
MSVC?

The above wouldn't fix the problem with MS's handling of 
invalid mode strings.  I had noticed that you could put 
anything in a mode string provided the first character was 
in [rwa].  How do other C libraries handle these kind of 
errors in mode strings?  I have the source to Borland C++ 
Builder 4.  It looks like it checks the entire mode string, 
but it also fails without setting errno if it finds any 
invalid characters.  Is fopen expected to set errno on 
failure?  (I note that neither the MS nor the Borland 
documentation for fopen refers to errno.)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-07 05:00

Message:
Logged In: YES 
user_id=31435

Which version of Windows are you using?  Here on Win98SE, I 
get

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'
>>>

all the way back through Python 2.0.  Note that MS's error 
translation table (in DOSMAP.C) doesn't contain an entry 
for ERROR_INVALID_NAME, so the logic in _dosmaperr() would 
return EINVAL in that case (it can't dream up anything 
better to return).  The errors CreateFile *can* trigger 
aren't documented, and I expect they vary across Windows 
flavors (and that Win98SE triggers ERROR_FILE_NOT_FOUND in 
this case, which maps to ENOENT).

Note that MS doesn't catch all senseless mode strings 
either.  For example,

>>> open('wtf', 'w hi greg!')
<open file 'wtf', mode 'w hi greg!' at 0x00768F30>
>>>

If you want to create a patch to clean up MS's mess here, 
be my guest.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-03 12:15

Message:
Logged In: YES 
user_id=6656

Guess who gets to look at this one.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 22:26:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 14:26:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads
Message-ID: <E16uKB4-0003Fv-00@usw-sf-web3.sourceforge.net>

Bugs item #539990, was opened at 2002-04-05 23:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pieter Claerhout (pclaerhout)
Assigned to: Jack Jansen (jackjansen)
Summary: Framework.mainloop() - multiple threads

Initial Comment:
I tried to use the threading module to start the XML 
RPC server in a different thread (xmlrpcServer itself 
also is a threaded piece of code), but that seems to 
conflict with the mainloop. If you start this 
application, it starts the thread, starts the mainloop 
and stays in there, once you finish the mainloop, the 
thread continues.

You've stumbled on a bug in Framework.mainloop(): it 
doesn't know anything about multiple threads. It gives 
time to other applications (by calling WaitNextEvent) 
but not to other threads within Python.

Also see
http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005416.html

and 

http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005428.html

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-07 23:26

Message:
Logged In: YES 
user_id=45365

Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 22:55:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 14:55:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-540720 ] test_email fails on Mac in summer
Message-ID: <E16uKda-0003Zy-00@usw-sf-web3.sourceforge.net>

Bugs item #540720, was opened at 2002-04-07 23:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_email fails on Mac in summer

Initial Comment:
Yes, I kid you not:-)

The test of the date/time  parser in test_email tries to cater for the fact that the Mac uses localtime (at least, before OSX), but it fails to cater for DST. So, test_email passes in winter, but fails in summer.

I think the whole idea of comparing based on a numeric value is not so good. Why not try a roundtrip, or compare against another date coder (time.asctime)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 23:19:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 15:19:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-538361 ] packing double yields garbage
Message-ID: <E16uL0n-0001Ay-00@usw-sf-web2.sourceforge.net>

Bugs item #538361, was opened at 2002-04-02 12:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470

Category: Python Library
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Carifio (carifio)
Assigned to: Nobody/Anonymous (nobody)
Summary: packing double yields garbage

Initial Comment:
On RH Linux 6.2/alpha (kernal 2.2.14-6.0), egcs-
2.91.66, python 2.2.1c2. I build python
from source and test_struct.py dies with
a floating point exception. I believe I've
found out why:


>>> import struct
>>> s = struct.pack("d", 3.14e20)
>>> struct.unpack("d", s)
(1.69270791053e-307,)


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-07 18:19

Message:
Logged In: YES 
user_id=6380

- Does the same error occur in earlier versions (2.2,
2.1.2)?

- I'm relabeling this as platform-specific because it only
fails on alphas (not the world's most popular CPU
architecture).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-02 16:24

Message:
Logged In: YES 
user_id=31435

Can you show what's in s?  As is, it's impossible to guess 
whether the problem is in pack() or unpack().  Life would 
be simpler if you started with a simpler float too (like, 
say, 1.0).

Something random that might help:  recompile structmodule.c 
with optimization turned off.

One other:  is this Alpha configured to run in big-endian 
or little-endian mode?

----------------------------------------------------------------------

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:59

Message:
Logged In: YES 
user_id=503643

EV6 I think. Can I run a command to find out?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:51

Message:
Logged In: YES 
user_id=6656

Oh.  That means it might be our fault.  Damn.

Erm, clutching at straws: what flavour of alpha is this?  I'm 
guessing this is some kind of alignment problem.



----------------------------------------------------------------------

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:48

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

----------------------------------------------------------------------

Comment By: Mike Carifio (carifio)
Date: 2002-04-02 13:47

Message:
Logged In: YES 
user_id=503643

I also tried this on RH7.*/alpha/2.4.something kernel
and gcc 2.95.something and got the same error. Actually,
it started with test_struct.py core dumping. I don't
actually need to pack doubles. I was just being a good
doobie.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-02 13:33

Message:
Logged In: YES 
user_id=6656

Hmm, that looks broke.

However, I don't see this behaviour on sf's compile farm with 
221c1; I'm building 221c2 now, but I'd be amazed if it's 
different.

That machine has kernel 2.4.something and gcc 2.95.something, 
so is it possible that this is a now-fixed bug in one those 
(most likely the compiler)?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538361&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 23:25:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 15:25:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-515745 ] Missing docs for module knee
Message-ID: <E16uL6L-0003tY-00@usw-sf-web3.sourceforge.net>

Bugs item #515745, was opened at 2002-02-11 00:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Martin v. L�wis (loewis)
Summary: Missing docs for module knee

Initial Comment:
3.21.1 in the lib manual sez: "A more complete example 
that implements hierarchical module names and includes 
a reload() function can be found in the standard 
module knee (which is intended as an example only -- 
don't rely on any part of it being a standard 
interface)."

...but knee is not in the module list, though it 
appears to be in the distribution.

----------------------------------------------------------------------

>Comment By: David Abrahams (david_abrahams)
Date: 2002-04-07 17:25

Message:
Logged In: YES 
user_id=52572

Moving it without changing the docs isn't much good. Is 
someone changing the docs?


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-07 11:30

Message:
Logged In: YES 
user_id=21627

knee.py is now moved to Demo/imputil.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 21:41

Message:
Logged In: YES 
user_id=6380

knee.py itself is mostly intended as documentation -- it's
working code that demonstrates how the import process works!

It's fine if it gets moved to the Demo directory.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-16 02:07

Message:
Logged In: YES 
user_id=31435

Sorry, I can't channel Guido here -- AFAICT, this is the 
first time I ever heard about knee!  Reassigned to Guido.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-02-14 12:24

Message:
Logged In: YES 
user_id=52572

If you move it, please change the docs so that it no longer 
says it's a standard module.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-14 12:04

Message:
Logged In: YES 
user_id=3066

Like it says, the knee module is supposed to be an example
only.  I don't think it should be included in the library at
all; it should be somewhere in Demo/.

I think Guido has resisted moving it before, but I don't
recall clearly.  I'll assign this to Tim since Guido's not
available now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 23:33:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 15:33:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-515745 ] Missing docs for module knee
Message-ID: <E16uLE8-00014J-00@usw-sf-web1.sourceforge.net>

Bugs item #515745, was opened at 2002-02-11 00:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Martin v. L�wis (loewis)
Summary: Missing docs for module knee

Initial Comment:
3.21.1 in the lib manual sez: "A more complete example 
that implements hierarchical module names and includes 
a reload() function can be found in the standard 
module knee (which is intended as an example only -- 
don't rely on any part of it being a standard 
interface)."

...but knee is not in the module list, though it 
appears to be in the distribution.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-07 18:33

Message:
Logged In: YES 
user_id=6380

What docs?

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-04-07 18:25

Message:
Logged In: YES 
user_id=52572

Moving it without changing the docs isn't much good. Is 
someone changing the docs?


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-07 12:30

Message:
Logged In: YES 
user_id=21627

knee.py is now moved to Demo/imputil.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 21:41

Message:
Logged In: YES 
user_id=6380

knee.py itself is mostly intended as documentation -- it's
working code that demonstrates how the import process works!

It's fine if it gets moved to the Demo directory.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-16 02:07

Message:
Logged In: YES 
user_id=31435

Sorry, I can't channel Guido here -- AFAICT, this is the 
first time I ever heard about knee!  Reassigned to Guido.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-02-14 12:24

Message:
Logged In: YES 
user_id=52572

If you move it, please change the docs so that it no longer 
says it's a standard module.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-14 12:04

Message:
Logged In: YES 
user_id=3066

Like it says, the knee module is supposed to be an example
only.  I don't think it should be included in the library at
all; it should be somewhere in Demo/.

I think Guido has resisted moving it before, but I don't
recall clearly.  I'll assign this to Tim since Guido's not
available now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470



From noreply@sourceforge.net  Sun Apr  7 23:49:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 15:49:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-515745 ] Missing docs for module knee
Message-ID: <E16uLT6-0001EY-00@usw-sf-web1.sourceforge.net>

Bugs item #515745, was opened at 2002-02-11 00:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Martin v. L�wis (loewis)
Summary: Missing docs for module knee

Initial Comment:
3.21.1 in the lib manual sez: "A more complete example 
that implements hierarchical module names and includes 
a reload() function can be found in the standard 
module knee (which is intended as an example only -- 
don't rely on any part of it being a standard 
interface)."

...but knee is not in the module list, though it 
appears to be in the distribution.

----------------------------------------------------------------------

>Comment By: David Abrahams (david_abrahams)
Date: 2002-04-07 17:49

Message:
Logged In: YES 
user_id=52572

Please see my comment below from 2002-02-14 12:24


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-07 17:33

Message:
Logged In: YES 
user_id=6380

What docs?

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-04-07 17:25

Message:
Logged In: YES 
user_id=52572

Moving it without changing the docs isn't much good. Is 
someone changing the docs?


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-07 11:30

Message:
Logged In: YES 
user_id=21627

knee.py is now moved to Demo/imputil.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 21:41

Message:
Logged In: YES 
user_id=6380

knee.py itself is mostly intended as documentation -- it's
working code that demonstrates how the import process works!

It's fine if it gets moved to the Demo directory.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-16 02:07

Message:
Logged In: YES 
user_id=31435

Sorry, I can't channel Guido here -- AFAICT, this is the 
first time I ever heard about knee!  Reassigned to Guido.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-02-14 12:24

Message:
Logged In: YES 
user_id=52572

If you move it, please change the docs so that it no longer 
says it's a standard module.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-14 12:04

Message:
Logged In: YES 
user_id=3066

Like it says, the knee module is supposed to be an example
only.  I don't think it should be included in the library at
all; it should be somewhere in Demo/.

I think Guido has resisted moving it before, but I don't
recall clearly.  I'll assign this to Tim since Guido's not
available now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 01:11:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 17:11:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-538827 ] Python open w/ MSVC6: bad error msgs
Message-ID: <E16uMlG-0004ya-00@usw-sf-web3.sourceforge.net>

Bugs item #538827, was opened at 2002-04-04 03:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470

Category: Windows
Group: Platform-specific
Status: Open
Resolution: None
Priority: 4
Submitted By: Greg Chapman (glchapman)
Assigned to: Tim Peters (tim_one)
Summary: Python open w/ MSVC6: bad error msgs

Initial Comment:
With the current Win32 build (actually, 2.2.1c1), you 
get the following behavior when feeding bad filenames 
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error 
ERROR_INVALID_NAME to EINVAL, and Python always treats 
this error as being related to the mode string.  It 
appears (from bug report 476593) that VC6 disagrees 
with GCC here; I don't know which compiler is right 
(actually, looking at the VC documentation for _open, 
it appears GCC is right).  At any rate, it appears 
Python cannot rely on EINVAL referring only to the 
mode string under Windows.

Interestingly, the current Python Win32 build also 
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen 
fails, but it does not set errno.  (You can see this 
in the openfile function in _OPEN.C in the VC6 CRT 
source).  It might be possible to use this behavior to 
produce more accurate error messages under Windows.



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-08 10:11

Message:
Logged In: YES 
user_id=14198

Confirming that on Win2k, before the patch I see:
>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

and after:
>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'

and a quick scan shows the patch to be reasonable.  So +1 on
checking it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-08 06:21

Message:
Logged In: YES 
user_id=31435

I'm afraid there are no answers to your questions short of 
doing an exhaustive study of each implementation of 
interest, and even then it hits a brick wall because Win32 
CreateFile() doesn't document its error conditions and its 
source code is secret.

I'm attaching a patch that should reliably distinguish 
between mode and filename errors across Windows flavors 
under MSVC, and that maps EINVALID to ENOENT on Windows 
(which may not be the best that *could* be done on Win2K, 
but Windows flavors are inconsistent here and Python has no 
idea which flavor of Win32 it's running under).  If that's 
good enough for you, I'll check it in,; else I'm inclined 
to close this as 3rdParty and Won'tFix.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-04-08 05:09

Message:
Logged In: YES 
user_id=86307

I'm using Windows 2000; I also just tested this on Windows 
XP Pro and got the same results (as on Windows 2000).

As far as a patch, the simplest thing might be to add an 
ifdef so that EINVAL is not treated as a special case when 
compiling with VC; this would revert to the behavior before 
November 2001 (i.e., the patch for bug 476593).  If this 
path is chosen, should there be a special define introduced 
for invalid use of EINVAL (I don't know if other C 
libraries have this problem), or should it simply refer to 
MSVC?

The above wouldn't fix the problem with MS's handling of 
invalid mode strings.  I had noticed that you could put 
anything in a mode string provided the first character was 
in [rwa].  How do other C libraries handle these kind of 
errors in mode strings?  I have the source to Borland C++ 
Builder 4.  It looks like it checks the entire mode string, 
but it also fails without setting errno if it finds any 
invalid characters.  Is fopen expected to set errno on 
failure?  (I note that neither the MS nor the Borland 
documentation for fopen refers to errno.)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-07 19:00

Message:
Logged In: YES 
user_id=31435

Which version of Windows are you using?  Here on Win98SE, I 
get

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'
>>>

all the way back through Python 2.0.  Note that MS's error 
translation table (in DOSMAP.C) doesn't contain an entry 
for ERROR_INVALID_NAME, so the logic in _dosmaperr() would 
return EINVAL in that case (it can't dream up anything 
better to return).  The errors CreateFile *can* trigger 
aren't documented, and I expect they vary across Windows 
flavors (and that Win98SE triggers ERROR_FILE_NOT_FOUND in 
this case, which maps to ENOENT).

Note that MS doesn't catch all senseless mode strings 
either.  For example,

>>> open('wtf', 'w hi greg!')
<open file 'wtf', mode 'w hi greg!' at 0x00768F30>
>>>

If you want to create a patch to clean up MS's mess here, 
be my guest.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-04 03:15

Message:
Logged In: YES 
user_id=6656

Guess who gets to look at this one.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 05:20:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 21:20:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-538827 ] Python open w/ MSVC6: bad error msgs
Message-ID: <E16uQdS-0007Si-00@usw-sf-web3.sourceforge.net>

Bugs item #538827, was opened at 2002-04-03 12:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470

Category: Windows
>Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
>Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Tim Peters (tim_one)
Summary: Python open w/ MSVC6: bad error msgs

Initial Comment:
With the current Win32 build (actually, 2.2.1c1), you 
get the following behavior when feeding bad filenames 
to Python's open function:

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

Apparently, VC6 maps the Win32 error 
ERROR_INVALID_NAME to EINVAL, and Python always treats 
this error as being related to the mode string.  It 
appears (from bug report 476593) that VC6 disagrees 
with GCC here; I don't know which compiler is right 
(actually, looking at the VC documentation for _open, 
it appears GCC is right).  At any rate, it appears 
Python cannot rely on EINVAL referring only to the 
mode string under Windows.

Interestingly, the current Python Win32 build also 
shows this:

>>> open("hello.txt", "x")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 0] Error: 'hello.txt'

When you actually provide a bad mode string, fopen 
fails, but it does not set errno.  (You can see this 
in the openfile function in _OPEN.C in the VC6 CRT 
source).  It might be possible to use this behavior to 
produce more accurate error messages under Windows.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-08 00:20

Message:
Logged In: YES 
user_id=31435

Based on Mark's confirmation and reviewlet, I'm closing 
this report.  The patched logic was checked in on the trunk 
and on the 2.2.1 branch (so will be in 2.2.1 final later 
this week).

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-07 20:11

Message:
Logged In: YES 
user_id=14198

Confirming that on Win2k, before the patch I see:
>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: invalid argument: r

and after:
>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'

and a quick scan shows the patch to be reasonable.  So +1 on
checking it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-07 16:21

Message:
Logged In: YES 
user_id=31435

I'm afraid there are no answers to your questions short of 
doing an exhaustive study of each implementation of 
interest, and even then it hits a brick wall because Win32 
CreateFile() doesn't document its error conditions and its 
source code is secret.

I'm attaching a patch that should reliably distinguish 
between mode and filename errors across Windows flavors 
under MSVC, and that maps EINVALID to ENOENT on Windows 
(which may not be the best that *could* be done on Win2K, 
but Windows flavors are inconsistent here and Python has no 
idea which flavor of Win32 it's running under).  If that's 
good enough for you, I'll check it in,; else I'm inclined 
to close this as 3rdParty and Won'tFix.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-04-07 15:09

Message:
Logged In: YES 
user_id=86307

I'm using Windows 2000; I also just tested this on Windows 
XP Pro and got the same results (as on Windows 2000).

As far as a patch, the simplest thing might be to add an 
ifdef so that EINVAL is not treated as a special case when 
compiling with VC; this would revert to the behavior before 
November 2001 (i.e., the patch for bug 476593).  If this 
path is chosen, should there be a special define introduced 
for invalid use of EINVAL (I don't know if other C 
libraries have this problem), or should it simply refer to 
MSVC?

The above wouldn't fix the problem with MS's handling of 
invalid mode strings.  I had noticed that you could put 
anything in a mode string provided the first character was 
in [rwa].  How do other C libraries handle these kind of 
errors in mode strings?  I have the source to Borland C++ 
Builder 4.  It looks like it checks the entire mode string, 
but it also fails without setting errno if it finds any 
invalid characters.  Is fopen expected to set errno on 
failure?  (I note that neither the MS nor the Borland 
documentation for fopen refers to errno.)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-07 05:00

Message:
Logged In: YES 
user_id=31435

Which version of Windows are you using?  Here on Win98SE, I 
get

>>> open("hello?.txt")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
IOError: [Errno 2] No such file or directory: 'hello?.txt'
>>>

all the way back through Python 2.0.  Note that MS's error 
translation table (in DOSMAP.C) doesn't contain an entry 
for ERROR_INVALID_NAME, so the logic in _dosmaperr() would 
return EINVAL in that case (it can't dream up anything 
better to return).  The errors CreateFile *can* trigger 
aren't documented, and I expect they vary across Windows 
flavors (and that Win98SE triggers ERROR_FILE_NOT_FOUND in 
this case, which maps to ENOENT).

Note that MS doesn't catch all senseless mode strings 
either.  For example,

>>> open('wtf', 'w hi greg!')
<open file 'wtf', mode 'w hi greg!' at 0x00768F30>
>>>

If you want to create a patch to clean up MS's mess here, 
be my guest.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-03 12:15

Message:
Logged In: YES 
user_id=6656

Guess who gets to look at this one.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=538827&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 06:26:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 22:26:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-515745 ] Missing docs for module knee
Message-ID: <E16uRfs-00085R-00@usw-sf-web3.sourceforge.net>

Bugs item #515745, was opened at 2002-02-11 00:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470

Category: Demos and Tools
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Martin v. L�wis (loewis)
Summary: Missing docs for module knee

Initial Comment:
3.21.1 in the lib manual sez: "A more complete example 
that implements hierarchical module names and includes 
a reload() function can be found in the standard 
module knee (which is intended as an example only -- 
don't rely on any part of it being a standard 
interface)."

...but knee is not in the module list, though it 
appears to be in the distribution.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-08 01:26

Message:
Logged In: YES 
user_id=3066

Description of knee's status has been changed as of
Doc/lib/libimp.tex revisions 1.28.4.1, 1.30.14.1, and 1.31.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-04-07 18:49

Message:
Logged In: YES 
user_id=52572

Please see my comment below from 2002-02-14 12:24


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-07 18:33

Message:
Logged In: YES 
user_id=6380

What docs?

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-04-07 18:25

Message:
Logged In: YES 
user_id=52572

Moving it without changing the docs isn't much good. Is 
someone changing the docs?


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-07 12:30

Message:
Logged In: YES 
user_id=21627

knee.py is now moved to Demo/imputil.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-22 21:41

Message:
Logged In: YES 
user_id=6380

knee.py itself is mostly intended as documentation -- it's
working code that demonstrates how the import process works!

It's fine if it gets moved to the Demo directory.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-16 02:07

Message:
Logged In: YES 
user_id=31435

Sorry, I can't channel Guido here -- AFAICT, this is the 
first time I ever heard about knee!  Reassigned to Guido.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-02-14 12:24

Message:
Logged In: YES 
user_id=52572

If you move it, please change the docs so that it no longer 
says it's a standard module.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-02-14 12:04

Message:
Logged In: YES 
user_id=3066

Like it says, the knee module is supposed to be an example
only.  I don't think it should be included in the library at
all; it should be somewhere in Demo/.

I think Guido has resisted moving it before, but I don't
recall clearly.  I'll assign this to Tim since Guido's not
available now.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=515745&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 07:12:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 23:12:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-540874 ] BoolType should be added to types.py
Message-ID: <E16uSOc-000079-00@usw-sf-web3.sourceforge.net>

Bugs item #540874, was opened at 2002-04-07 23:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Nobody/Anonymous (nobody)
Summary: BoolType should be added to types.py

Initial Comment:
That's it :-)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 07:16:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 23:16:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-540720 ] test_email fails on Mac in summer
Message-ID: <E16uSRc-000603-00@usw-sf-web2.sourceforge.net>

Bugs item #540720, was opened at 2002-04-07 17:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_email fails on Mac in summer

Initial Comment:
Yes, I kid you not:-)

The test of the date/time  parser in test_email tries to cater for the fact that the Mac uses localtime (at least, before OSX), but it fails to cater for DST. So, test_email passes in winter, but fails in summer.

I think the whole idea of comparing based on a numeric value is not so good. Why not try a roundtrip, or compare against another date coder (time.asctime)?

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-08 02:15

Message:
Logged In: YES 
user_id=12800

What do you think of the attached patch?  Is this still a
useful test to include?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 07:23:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 07 Apr 2002 23:23:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-540874 ] BoolType should be added to types.py
Message-ID: <E16uSZJ-0000Em-00@usw-sf-web3.sourceforge.net>

Bugs item #540874, was opened at 2002-04-08 02:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: BoolType should be added to types.py

Initial Comment:
That's it :-)

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-08 02:23

Message:
Logged In: YES 
user_id=31435

Probably not, Brian.  types.py largely exists just for 
backward compatibility now.  If you want the bool type, 
just say "bool"!

>>> bool
<type 'bool'>
>>> type(bool)
<type 'type'>
>>> isinstance(True, bool)
True
>>>

Like also int, str, long, file, dict, ... in 2.2, what used 
to be builtin functions for constructing an object of a 
given type are now *the* type objects themselves, acting as 
constructors for objects of their types.  There's no reason 
to add them to types.py too.

Assigning to Guido in case he disagrees.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 08:22:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 00:22:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-540874 ] BoolType should be added to types.py
Message-ID: <E16uTTw-000164-00@usw-sf-web4.sourceforge.net>

Bugs item #540874, was opened at 2002-04-07 23:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Guido van Rossum (gvanrossum)
Summary: BoolType should be added to types.py

Initial Comment:
That's it :-)

----------------------------------------------------------------------

>Comment By: Brian Quinlan (bquinlan)
Date: 2002-04-08 00:22

Message:
Logged In: YES 
user_id=108973

I understand your point about isinstance being the one true 
way of doing things now. 

But I don't understand what your code is trying to 
demonstrate.

As long as this works:
>>> type(True) is type(bool(1))
True
>>> type(1) is type(bool(1))
False

I don't see why StringType should be in types.py and 
BoolType shouldn't be.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-07 23:23

Message:
Logged In: YES 
user_id=31435

Probably not, Brian.  types.py largely exists just for 
backward compatibility now.  If you want the bool type, 
just say "bool"!

>>> bool
<type 'bool'>
>>> type(bool)
<type 'type'>
>>> isinstance(True, bool)
True
>>>

Like also int, str, long, file, dict, ... in 2.2, what used 
to be builtin functions for constructing an object of a 
given type are now *the* type objects themselves, acting as 
constructors for objects of their types.  There's no reason 
to add them to types.py too.

Assigning to Guido in case he disagrees.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 09:22:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 01:22:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16uUPl-0001YT-00@usw-sf-web3.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 19:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-08 08:22

Message:
Logged In: YES 
user_id=38388

Moving PyUnicode_Fini down in the finalization list
seems to help. 

Still, I'm afraid that if some Unicode objects are left 
stored in some lists or dictionaries, we may still see 
the problem (due to coercion of strings to Unicode).
OTOH, strings are finalized before Unicode object now.

Anyway, the test case works now after checkin
of the fix proposed by Martin, so I'm closing the 
report.


----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-04-07 01:37

Message:
Logged In: YES 
user_id=36737

The original report described a test case; test/t3.py in the
ZSI package.  Following up on this, Dave Wallace has a short
example that crashes.  See his posting in to xml-sig, at
http://mail.python.org/pipermail/xml-sig/2002-April/007553.html


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 07:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-13 02:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 19:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 13:01:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 05:01:31 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-540952 ] Memory Usage Reporting
Message-ID: <E16uXpz-0001DV-00@usw-sf-web1.sourceforge.net>

Feature Requests item #540952, was opened at 2002-04-08 12:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Usage Reporting

Initial Comment:
I would personally like a way in Python to report how 
many bytes of memory that the interpreter is using 
(perhaps through the sys module)?

If this sort of mechanism is added, then it may allow 
SoftReferences (a la Java) to be introduced, which 
would definitely be useful for memory sensitive 
caches...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 13:04:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 05:04:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16uXt9-0001Tl-00@usw-sf-web2.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 19:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-08 08:22

Message:
Logged In: YES 
user_id=38388

Moving PyUnicode_Fini down in the finalization list
seems to help. 

Still, I'm afraid that if some Unicode objects are left 
stored in some lists or dictionaries, we may still see 
the problem (due to coercion of strings to Unicode).
OTOH, strings are finalized before Unicode object now.

Anyway, the test case works now after checkin
of the fix proposed by Martin, so I'm closing the 
report.


----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-04-07 01:37

Message:
Logged In: YES 
user_id=36737

The original report described a test case; test/t3.py in the
ZSI package.  Following up on this, Dave Wallace has a short
example that crashes.  See his posting in to xml-sig, at
http://mail.python.org/pipermail/xml-sig/2002-April/007553.html


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 07:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-13 02:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 19:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 13:24:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 05:24:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16uYC0-0001hr-00@usw-sf-web2.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 12:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 14:20:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 06:20:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16uZ4V-0002B4-00@usw-sf-web1.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 19:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-04-08 13:20

Message:
Logged In: YES 
user_id=6656

So, do we want this in 221?  I know you may have said in a
checkin message...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-08 08:22

Message:
Logged In: YES 
user_id=38388

Moving PyUnicode_Fini down in the finalization list
seems to help. 

Still, I'm afraid that if some Unicode objects are left 
stored in some lists or dictionaries, we may still see 
the problem (due to coercion of strings to Unicode).
OTOH, strings are finalized before Unicode object now.

Anyway, the test case works now after checkin
of the fix proposed by Martin, so I'm closing the 
report.


----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-04-07 01:37

Message:
Logged In: YES 
user_id=36737

The original report described a test case; test/t3.py in the
ZSI package.  Following up on this, Dave Wallace has a short
example that crashes.  See his posting in to xml-sig, at
http://mail.python.org/pipermail/xml-sig/2002-April/007553.html


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 07:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-13 02:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 19:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 14:38:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 06:38:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16uZLo-0005WJ-00@usw-sf-web4.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 20:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-08 15:38

Message:
Logged In: YES 
user_id=21627

It's not a critical bug that is being fixed (a crash is
critical, but it is a rare problem).

OTOH, the fix seems reasonably straight-forward, and low
risk (he says :-); so yes - if that is still possible, it
should go into 2.2.1. Otherwise, it is a clear 2.2.2 candidate.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-08 15:20

Message:
Logged In: YES 
user_id=6656

So, do we want this in 221?  I know you may have said in a
checkin message...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-08 10:22

Message:
Logged In: YES 
user_id=38388

Moving PyUnicode_Fini down in the finalization list
seems to help. 

Still, I'm afraid that if some Unicode objects are left 
stored in some lists or dictionaries, we may still see 
the problem (due to coercion of strings to Unicode).
OTOH, strings are finalized before Unicode object now.

Anyway, the test case works now after checkin
of the fix proposed by Martin, so I'm closing the 
report.


----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-04-07 03:37

Message:
Logged In: YES 
user_id=36737

The original report described a test case; test/t3.py in the
ZSI package.  Following up on this, Dave Wallace has a short
example that crashes.  See his posting in to xml-sig, at
http://mail.python.org/pipermail/xml-sig/2002-April/007553.html


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 09:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-13 03:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 20:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 14:42:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 06:42:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-540874 ] BoolType should be added to types.py
Message-ID: <E16uZPJ-0005Kx-00@usw-sf-web3.sourceforge.net>

Bugs item #540874, was opened at 2002-04-08 08:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Guido van Rossum (gvanrossum)
Summary: BoolType should be added to types.py

Initial Comment:
That's it :-)

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-08 15:42

Message:
Logged In: YES 
user_id=21627

You would never write

type(True) is type(bool(1))

Instead, you write

type(True) is bool

just the same way as you write

type("") is str

So in practice, there is no need to use the types module,
atleast not in a typical application, and for new code. All
the old code can continue to use the types module, likewise
code that needs to work across versions - but such code
would not expect types.BoolType to be present, either.

So I agree with Tim that this is not a bug.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-04-08 09:22

Message:
Logged In: YES 
user_id=108973

I understand your point about isinstance being the one true 
way of doing things now. 

But I don't understand what your code is trying to 
demonstrate.

As long as this works:
>>> type(True) is type(bool(1))
True
>>> type(1) is type(bool(1))
False

I don't see why StringType should be in types.py and 
BoolType shouldn't be.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-08 08:23

Message:
Logged In: YES 
user_id=31435

Probably not, Brian.  types.py largely exists just for 
backward compatibility now.  If you want the bool type, 
just say "bool"!

>>> bool
<type 'bool'>
>>> type(bool)
<type 'type'>
>>> isinstance(True, bool)
True
>>>

Like also int, str, long, file, dict, ... in 2.2, what used 
to be builtin functions for constructing an object of a 
given type are now *the* type objects themselves, acting as 
constructors for objects of their types.  There's no reason 
to add them to types.py too.

Assigning to Guido in case he disagrees.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 14:43:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 06:43:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-540874 ] BoolType should be added to types.py
Message-ID: <E16uZQc-0005Ln-00@usw-sf-web3.sourceforge.net>

Bugs item #540874, was opened at 2002-04-08 02:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Brian Quinlan (bquinlan)
Assigned to: Guido van Rossum (gvanrossum)
Summary: BoolType should be added to types.py

Initial Comment:
That's it :-)

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-08 09:43

Message:
Logged In: YES 
user_id=6380

StringType should be in types for backwards compatibility.
There's lots of existing (user and 3rd party) code that uses
types.StringType. There's zero code that uses
types.BoolType, and I want to keep it that way.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-08 09:42

Message:
Logged In: YES 
user_id=21627

You would never write

type(True) is type(bool(1))

Instead, you write

type(True) is bool

just the same way as you write

type("") is str

So in practice, there is no need to use the types module,
atleast not in a typical application, and for new code. All
the old code can continue to use the types module, likewise
code that needs to work across versions - but such code
would not expect types.BoolType to be present, either.

So I agree with Tim that this is not a bug.

----------------------------------------------------------------------

Comment By: Brian Quinlan (bquinlan)
Date: 2002-04-08 03:22

Message:
Logged In: YES 
user_id=108973

I understand your point about isinstance being the one true 
way of doing things now. 

But I don't understand what your code is trying to 
demonstrate.

As long as this works:
>>> type(True) is type(bool(1))
True
>>> type(1) is type(bool(1))
False

I don't see why StringType should be in types.py and 
BoolType shouldn't be.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-08 02:23

Message:
Logged In: YES 
user_id=31435

Probably not, Brian.  types.py largely exists just for 
backward compatibility now.  If you want the bool type, 
just say "bool"!

>>> bool
<type 'bool'>
>>> type(bool)
<type 'type'>
>>> isinstance(True, bool)
True
>>>

Like also int, str, long, file, dict, ... in 2.2, what used 
to be builtin functions for constructing an object of a 
given type are now *the* type objects themselves, acting as 
constructors for objects of their types.  There's no reason 
to add them to types.py too.

Assigning to Guido in case he disagrees.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540874&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 16:35:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 08:35:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-528620 ] unicodeobject can coredump on exit
Message-ID: <E16ubAi-0003pa-00@usw-sf-web1.sourceforge.net>

Bugs item #528620, was opened at 2002-03-11 19:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Rich Salz (rsalz)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobject can coredump on exit

Initial Comment:
It looks like the internal unicode_empty object can be
destroyed before other unicode objects are destroyed.

    /* Convert to Unicode */
    if (len == 0) {
***     if (unicode_empty == NULL) goto onError;
        Py_INCREF(unicode_empty);
        v = (PyObject *)unicode_empty;
    }
    else
        v = PyUnicode_Decode(s, len, encoding, errors);

The line marked *** was added.  It prevents python from
segfaulting during its cleanup-and-exit phase.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-08 15:35

Message:
Logged In: YES 
user_id=38388

I marked it as "2.2.1 candidate" group. IMHO, this should
be done with all minor update candidates (I only found this
group thingie today -- seems like a nice way to markup
bug fix candidates).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-08 13:38

Message:
Logged In: YES 
user_id=21627

It's not a critical bug that is being fixed (a crash is
critical, but it is a rare problem).

OTOH, the fix seems reasonably straight-forward, and low
risk (he says :-); so yes - if that is still possible, it
should go into 2.2.1. Otherwise, it is a clear 2.2.2 candidate.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-08 13:20

Message:
Logged In: YES 
user_id=6656

So, do we want this in 221?  I know you may have said in a
checkin message...

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-08 08:22

Message:
Logged In: YES 
user_id=38388

Moving PyUnicode_Fini down in the finalization list
seems to help. 

Still, I'm afraid that if some Unicode objects are left 
stored in some lists or dictionaries, we may still see 
the problem (due to coercion of strings to Unicode).
OTOH, strings are finalized before Unicode object now.

Anyway, the test case works now after checkin
of the fix proposed by Martin, so I'm closing the 
report.


----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-04-07 01:37

Message:
Logged In: YES 
user_id=36737

The original report described a test case; test/t3.py in the
ZSI package.  Following up on this, Dave Wallace has a short
example that crashes.  See his posting in to xml-sig, at
http://mail.python.org/pipermail/xml-sig/2002-April/007553.html


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 07:31

Message:
Logged In: YES 
user_id=21627

Notice that unicode_empty is accessed from within
PyImport_Cleanup, which is currently run after PyUnicode_Fini.

I believe PyUnicode_Fini should be run *much* later, e.g.
after PyFloat_Fini.

----------------------------------------------------------------------

Comment By: Rich Salz (rsalz)
Date: 2002-03-13 02:29

Message:
Logged In: YES 
user_id=36737

Running python 2.1.1 against ZSI, for example test/t3.py segfaults on exit with the following as top of stack.
(gdb) bt
#0  0x0809365c in PyUnicode_FromEncodedObject () at eval.c:41
#1  0x0809352d in PyUnicode_FromObject () at eval.c:41
#2  0x0809714f in PyUnicode_Compare () at eval.c:41
#3  0x0808cb5d in PyObject_Unicode () at eval.c:41
#4  0x0808cf75 in PyObject_Compare () at eval.c:41
#5  0x0808d129 in PyObject_RichCompare () at eval.c:41
#6  0x08057361 in PyEval_EvalCode () at eval.c:41
#7  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#8  0x08057829 in PyEval_EvalCode () at eval.c:41
#9  0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#10 0x08057829 in PyEval_EvalCode () at eval.c:41
#11 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#12 0x08057829 in PyEval_EvalCode () at eval.c:41
#13 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#14 0x08057829 in PyEval_EvalCode () at eval.c:41
#15 0x0805914f in PyEval_CallObjectWithKeywords () at eval.c:41
#16 0x08057829 in PyEval_EvalCode () at eval.c:41
#17 0x0805905b in PyEval_CallObjectWithKeywords () at eval.c:41
#18 0x08058c90 in PyEval_CallObjectWithKeywords () at eval.c:41
#19 0x08058f2b in PyEval_CallObjectWithKeywords () at eval.c:41
#20 0x08058c7d in PyEval_CallObjectWithKeywords () at eval.c:41
#21 0x08058b73 in PyEval_CallObjectWithKeywords () at eval.c:41
#22 0x0807c749 in PyInstance_New () at eval.c:41
---Type <return> to continue, or q <return> to quit---
#23 0x0808a0e4 in PyDict_New () at eval.c:41
#24 0x0808a3b6 in PyDict_SetItem () at eval.c:41
#25 0x0808bfc4 in _PyModule_Clear () at eval.c:41
#26 0x080654d6 in PyImport_Cleanup () at eval.c:41
#27 0x0806ae72 in Py_Finalize () at eval.c:41
#28 0x08051fae in Py_Main () at eval.c:41
#29 0x40080507 in __libc_start_main (main=0x8051a20 <main>, argc=2,
    ubp_av=0xbffff9c4, init=0x8050e7c <_init>, fini=0x809f070 <_fini>,
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff9bc)
    at ../sysdeps/generic/libc-start.c:129
(gdb)


----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-03-11 19:51

Message:
Logged In: YES 
user_id=38388

Provided you only use Unicode objects with the
Unicode implementation properly initialized, this
cannot happen. unicode_empty is kept alive between
calls to _PyUnicode_Init() and _PyUnicode_Fini().

If you are seeing a core dump in the location
you suggested, then it's likely that you have hit
a ref count bug somewhere.

In any case, I'd need an example to be able to say
whether this is indeed a bug in the core or in some
extension module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528620&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 17:38:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 09:38:56 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-540952 ] Memory Usage Reporting
Message-ID: <E16ucAS-0004oS-00@usw-sf-web2.sourceforge.net>

Feature Requests item #540952, was opened at 2002-04-08 08:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Usage Reporting

Initial Comment:
I would personally like a way in Python to report how 
many bytes of memory that the interpreter is using 
(perhaps through the sys module)?

If this sort of mechanism is added, then it may allow 
SoftReferences (a la Java) to be introduced, which 
would definitely be useful for memory sensitive 
caches...

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-08 12:38

Message:
Logged In: YES 
user_id=31435

Allan, this isn't easy, so the cost/benefit ratio is high.  
For the most part, Python gets memory from the system 
malloc, and doesn't even try to keep track of it now; nor 
has it any idea how much overhead (padding, control bytes) 
the system malloc adds; nor is there a portable interface 
to C's malloc for finding out such things.

Still, I agree it would be nice to have such things <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 22:23:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 14:23:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-541245 ] __unicode__ not documented
Message-ID: <E16ugbo-0002gx-00@usw-sf-web4.sourceforge.net>

Bugs item #541245, was opened at 2002-04-08 17:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541245&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: __unicode__ not documented

Initial Comment:
__unicode__() is to unicode() as __str__() is to str(),
however it's difficult to find this in the
documentation.  AFAICT, there's only one mention in the
builtins documentation.  There's no listing under
special methods (in either the lib or lang ref
manuals), and __unicode__ isn't in the indexes.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541245&group_id=5470



From noreply@sourceforge.net  Mon Apr  8 22:45:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 08 Apr 2002 14:45:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-541257 ] link to index.html from modindex.html
Message-ID: <E16ugxH-00089Z-00@usw-sf-web1.sourceforge.net>

Bugs item #541257, was opened at 2002-04-08 23:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470

Category: Documentation
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Liechti (cliechti)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: link to index.html from modindex.html

Initial Comment:
could you please link to "index.html" from modindex.html instead 
of just "./"?

other candidates are about.html and 
acks.html

this makes local-copy navigation better. if one has 
modindex bookmarked, the uparrow gives a filelisting instead of 
the document index :-(


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470



From noreply@sourceforge.net  Tue Apr  9 15:31:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 07:31:25 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16uweb-0004ze-00@usw-sf-web3.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 04:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Open
>Resolution: Later
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 10:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 05:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 04:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 03:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 17:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Tue Apr  9 15:45:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 07:45:43 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-540952 ] Memory Usage Reporting
Message-ID: <E16uwsR-0002Ux-00@usw-sf-web2.sourceforge.net>

Feature Requests item #540952, was opened at 2002-04-08 12:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Usage Reporting

Initial Comment:
I would personally like a way in Python to report how 
many bytes of memory that the interpreter is using 
(perhaps through the sys module)?

If this sort of mechanism is added, then it may allow 
SoftReferences (a la Java) to be introduced, which 
would definitely be useful for memory sensitive 
caches...

----------------------------------------------------------------------

>Comment By: Allan Crooks (amc1)
Date: 2002-04-09 14:45

Message:
Logged In: YES 
user_id=39733

Thanks for the response.

Rather than having an internal way of figuring out how much 
memory is used, is there no external way that we can get 
the OS to return how big the process is?

I know that it is less than elegant, and would have to have 
different platform-dependent code to do this, but it is 
still an idea. I know that Jython can quiz the VM to see 
how much memory is being used, and I'll assume that you can 
do that with different OS's as well...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-08 16:38

Message:
Logged In: YES 
user_id=31435

Allan, this isn't easy, so the cost/benefit ratio is high.  
For the most part, Python gets memory from the system 
malloc, and doesn't even try to keep track of it now; nor 
has it any idea how much overhead (padding, control bytes) 
the system malloc adds; nor is there a portable interface 
to C's malloc for finding out such things.

Still, I agree it would be nice to have such things <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470



From noreply@sourceforge.net  Tue Apr  9 16:07:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 08:07:56 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16uxDw-0002jF-00@usw-sf-web2.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Later
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 17:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 16:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 11:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 10:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 09:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 23:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Tue Apr  9 18:52:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 10:52:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-541652 ] imp.is_builtin() returns bool/int?
Message-ID: <E16uznN-0004Oi-00@usw-sf-web2.sourceforge.net>

Bugs item #541652, was opened at 2002-04-09 13:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541652&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: imp.is_builtin() returns bool/int?

Initial Comment:
imp.is_builtin() is documented (libimp.tex:178)
to return -1, 0, or 1.  However, it was changed
to a bool.  Should this not return a bool?
Should the docs be updated to only return bool?

Let me know what you want and 
you can assign it back to me.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541652&group_id=5470



From noreply@sourceforge.net  Tue Apr  9 19:01:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 11:01:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-541652 ] imp.is_builtin() returns bool/int?
Message-ID: <E16uzvg-0004Ft-00@usw-sf-web1.sourceforge.net>

Bugs item #541652, was opened at 2002-04-09 13:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541652&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: imp.is_builtin() returns bool/int?

Initial Comment:
imp.is_builtin() is documented (libimp.tex:178)
to return -1, 0, or 1.  However, it was changed
to a bool.  Should this not return a bool?
Should the docs be updated to only return bool?

Let me know what you want and 
you can assign it back to me.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 14:01

Message:
Logged In: YES 
user_id=6380

Ouch. I messed up. I've reverted that part of the checkin.
Thanks for paying attention!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541652&group_id=5470



From noreply@sourceforge.net  Tue Apr  9 21:14:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 13:14:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-541730 ] IDLE can clobber files
Message-ID: <E16v20O-0000NY-00@usw-sf-web4.sourceforge.net>

Bugs item #541730, was opened at 2002-04-09 20:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541730&group_id=5470

Category: IDLE
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Darnell (bgdarnel)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE can clobber files

Initial Comment:
I just lost some work today when IDLE failed to save my
file.  The file was truncated to 0 bytes, so it wasn't
recoverable by the recycle bin or anything like that. 
I was running Python 2.2 on Win2kPro.  There was no
error message, although IDLE seemed to realize that the
save failed - the asterisk remained in the title bar. 
I tried saving to a different name, but that didn't
work either (although a zero-byte file was created with
the new name).  I know this isn't enough for you to go
on to fix the bug; if I encounter the error again I
will inspect the situation more closely.  

In order to prevent data loss like this in the future,
I'd like to see IDLE make a backup of files before it
saves over them.  I submit the following (untested) patch:

--- IOBinding.py.orig   Tue Apr  9 15:56:00 2002
+++ IOBinding.py        Tue Apr  9 15:59:07 2002
@@ -148,6 +148,11 @@
 
     def writefile(self, filename):
         self.fixlastline()
+       try:
+           if os.path.exists(filename):
+               os.rename(filename, filename+'~')
+       except IOError:
+           pass
         try:
             f = open(filename, "w")
             chars = self.text.get("1.0", "end-1c")


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541730&group_id=5470



From noreply@sourceforge.net  Tue Apr  9 22:49:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 14:49:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-540720 ] test_email fails on Mac in summer
Message-ID: <E16v3Uf-0001Mb-00@usw-sf-web3.sourceforge.net>

Bugs item #540720, was opened at 2002-04-07 23:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_email fails on Mac in summer

Initial Comment:
Yes, I kid you not:-)

The test of the date/time  parser in test_email tries to cater for the fact that the Mac uses localtime (at least, before OSX), but it fails to cater for DST. So, test_email passes in winter, but fails in summer.

I think the whole idea of comparing based on a numeric value is not so good. Why not try a roundtrip, or compare against another date coder (time.asctime)?

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-09 23:49

Message:
Logged In: YES 
user_id=45365

Barry,
I can't apply the patch, it seems to be against a different version of test_email than what's in the repository (I tried both the trunk and the 22 maintainance branch).

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-08 08:15

Message:
Logged In: YES 
user_id=12800

What do you think of the attached patch?  Is this still a
useful test to include?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 02:56:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 18:56:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-541828 ] Regression in unicodestr.encode()
Message-ID: <E16v7LH-00043Y-00@usw-sf-web4.sourceforge.net>

Bugs item #541828, was opened at 2002-04-09 21:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Regression in unicodestr.encode()

Initial Comment:
I'm porting over the latest email package to Python
2.3cvs, and I've
had one of my tests fail.  I've narrowed it down to the
following test
case:

a =
u'\u6b63\u78ba\u306b\u8a00\u3046\u3068\u7ffb\u8a33\u306f\u3055\u308c\u3066\u3044\u307e\u305b\u3093\u3002\u4e00\u90e8\u306f\u30c9\u30a4\u30c4\u8a9e\u3067\u3059\u304c\u3001\u3042\u3068\u306f\u3067\u305f\u3089\u3081\u3067\u3059\u3002\u5b9f\u969b\u306b\u306f\u300cWenn
ist das Nunstuck git und'
print repr(a.encode('utf-8', 'replace'))

In Python 2.2.1 I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git und'

but in Python 2.3 cvs I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git u\x00\x00'

Note that the last two characters, which should be `n'
and `d' are now
NULs.  My very limited Tim-enlightened understanding is
that encoding
a string to UTF-8 should never produce a string with NULs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 05:37:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 21:37:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-521448 ] Undocumented Py_InitModule
Message-ID: <E16v9rC-0002ge-00@usw-sf-web1.sourceforge.net>

Bugs item #521448, was opened at 2002-02-22 08:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521448&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Jes�s Cea Avi�n (jcea)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Undocumented Py_InitModule

Initial Comment:
Python 2.2 docs.

Function "Py_InitModule" is not documented in section 
5.3.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-10 00:37

Message:
Logged In: YES 
user_id=3066

It is documented in section 10.1 of that same document,
however, and is listed in the index.  It is included in the
documentation for all 2.2.* releases.

----------------------------------------------------------------------

Comment By: Jes�s Cea Avi�n (jcea)
Date: 2002-02-22 08:20

Message:
Logged In: YES 
user_id=97460

I'm talking about "Python/C API Reference Manual".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=521448&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 07:51:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 09 Apr 2002 23:51:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-541883 ] delattr() causes python to segfault
Message-ID: <E16vBxC-0006xo-00@usw-sf-web3.sourceforge.net>

Bugs item #541883, was opened at 2002-04-10 08:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent FIACK (vfiack)
Assigned to: Nobody/Anonymous (nobody)
Summary: delattr() causes python to segfault

Initial Comment:
delattr() causes python to segfault with builtins types

First a normal case to see what it should do :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> delattr(a, "__class__")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'int' object has only read-only attributes 
(del .__class__)



Then the faulty case :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> a.__class__
<type 'int'>
>>> delattr(a, "__class__")
Segmentation fault.

I don't know why, but if i access to a.__class__ 
before deleting it, it cause this error. The same 
occurs if i use another base type such as a string or 
a list. I haven't tried other attributes than 
__class__, but it may worth trying.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 08:25:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 00:25:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-541883 ] delattr() causes python to segfault
Message-ID: <E16vCUJ-0007LN-00@usw-sf-web3.sourceforge.net>

Bugs item #541883, was opened at 2002-04-10 08:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Vincent FIACK (vfiack)
Assigned to: Nobody/Anonymous (nobody)
Summary: delattr() causes python to segfault

Initial Comment:
delattr() causes python to segfault with builtins types

First a normal case to see what it should do :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> delattr(a, "__class__")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'int' object has only read-only attributes 
(del .__class__)



Then the faulty case :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> a.__class__
<type 'int'>
>>> delattr(a, "__class__")
Segmentation fault.

I don't know why, but if i access to a.__class__ 
before deleting it, it cause this error. The same 
occurs if i use another base type such as a string or 
a list. I haven't tried other attributes than 
__class__, but it may worth trying.

----------------------------------------------------------------------

>Comment By: Vincent FIACK (vfiack)
Date: 2002-04-10 09:25

Message:
Logged In: YES 
user_id=34036

I tried on "Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 
bit (Intel)] on win32" and a similar error occurs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 11:06:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 03:06:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-541883 ] delattr() causes python to segfault
Message-ID: <E16vF06-0000gW-00@usw-sf-web4.sourceforge.net>

Bugs item #541883, was opened at 2002-04-10 06:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
>Priority: 7
Submitted By: Vincent FIACK (vfiack)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: delattr() causes python to segfault

Initial Comment:
delattr() causes python to segfault with builtins types

First a normal case to see what it should do :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> delattr(a, "__class__")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'int' object has only read-only attributes 
(del .__class__)



Then the faulty case :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> a.__class__
<type 'int'>
>>> delattr(a, "__class__")
Segmentation fault.

I don't know why, but if i access to a.__class__ 
before deleting it, it cause this error. The same 
occurs if i use another base type such as a string or 
a list. I haven't tried other attributes than 
__class__, but it may worth trying.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-04-10 10:06

Message:
Logged In: YES 
user_id=6656

Confirmed in 2.2.1.

Arse.



----------------------------------------------------------------------

Comment By: Vincent FIACK (vfiack)
Date: 2002-04-10 07:25

Message:
Logged In: YES 
user_id=34036

I tried on "Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 
bit (Intel)] on win32" and a similar error occurs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 14:44:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 06:44:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-541980 ] urllib.urlopen throws OSError
Message-ID: <E16vIOg-0000If-00@usw-sf-web1.sourceforge.net>

Bugs item #541980, was opened at 2002-04-10 08:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541980&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jacques A. Vidrine (nectar)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlopen throws OSError

Initial Comment:
urllib.urlopen throws OSError when processing
file:// (local file) URLs and an error is encountered.
It should instead throw IOError in these cases to be
consistent with the built-in open function and with
the urllib documentation.  A patch is attached.

See bug report 482171 for an example of the
consequences of this bug (which was hacked around for
Python 2.2 it appears).  The bug also impacts 4Suite's
XSLT processor (using include paths causes an
unhandled exception).




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541980&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 15:00:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 07:00:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-482171 ] webchecker dies on file: URLs w/o robots
Message-ID: <E16vIeO-0000UR-00@usw-sf-web1.sourceforge.net>

Bugs item #482171, was opened at 2001-11-15 11:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470

Category: Demos and Tools
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: webchecker dies on file: URLs w/o robots

Initial Comment:
When webchecker is run on local documents using a file:
URL, it dies if there is not a robots.txt in the root
directory:

cj42289-a(.../python/Doc); python
../Tools/webchecker/webchecker.py file:`pwd`/html/api/
webchecker version 1.24
Traceback (most recent call last):
  File "../Tools/webchecker/webchecker.py", line 858, in ?
    main()
  File "../Tools/webchecker/webchecker.py", line 205,
in main
    c.addroot(arg)
  File "../Tools/webchecker/webchecker.py", line 324,
in addroot
    self.addrobot(root)
  File "../Tools/webchecker/webchecker.py", line 337,
in addrobot
    rp.read()
  File "/usr/local/lib/python2.2/robotparser.py", line
43, in read
    f = opener.open(self.url)
  File "/usr/local/lib/python2.2/urllib.py", line 178,
in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.2/urllib.py", line 405,
in open_file
    return self.open_local_file(url)
  File "/usr/local/lib/python2.2/urllib.py", line 412,
in open_local_file
    stats = os.stat(localname)
OSError: [Errno 2] No such file or directory: '/robots.txt'


----------------------------------------------------------------------

Comment By: Jacques A. Vidrine (nectar)
Date: 2002-04-10 09:00

Message:
Logged In: YES 
user_id=14672

Please see bug ID 541980.  I believe the fix here
(webchecker.py rev 1.25) was incorrect.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 16:41

Message:
Logged In: YES 
user_id=6380

Fixed in webchecker.py rev. 1.25.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 15:03:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 07:03:38 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-540952 ] Memory Usage Reporting
Message-ID: <E16vIhG-0000WV-00@usw-sf-web1.sourceforge.net>

Feature Requests item #540952, was opened at 2002-04-08 22:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Usage Reporting

Initial Comment:
I would personally like a way in Python to report how 
many bytes of memory that the interpreter is using 
(perhaps through the sys module)?

If this sort of mechanism is added, then it may allow 
SoftReferences (a la Java) to be introduced, which 
would definitely be useful for memory sensitive 
caches...

----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-11 00:03

Message:
Logged In: YES 
user_id=29957

You _can_ do this for most O/Ss, true. The problem is that
it's something that's extremely operating system specific,
and, worse yet, varies significantly between operating 
system releases. Have a look at the source for the system
utility 'top' one day - most of it is in the 'operating 
system specific' section, and there's all sorts of horrible
horrible hoops you have to jump through for different releases.

In addition, the notion of "how much memory is being used"
isn't always that clear in the case of things like shared
libraries.

On the plus side, implementing this would move the HP/UX
threading problem to #2 on the list of "most annoying 
operating-system dependent bugs".

----------------------------------------------------------------------

Comment By: Allan Crooks (amc1)
Date: 2002-04-10 00:45

Message:
Logged In: YES 
user_id=39733

Thanks for the response.

Rather than having an internal way of figuring out how much 
memory is used, is there no external way that we can get 
the OS to return how big the process is?

I know that it is less than elegant, and would have to have 
different platform-dependent code to do this, but it is 
still an idea. I know that Jython can quiz the VM to see 
how much memory is being used, and I'll assume that you can 
do that with different OS's as well...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-09 02:38

Message:
Logged In: YES 
user_id=31435

Allan, this isn't easy, so the cost/benefit ratio is high.  
For the most part, Python gets memory from the system 
malloc, and doesn't even try to keep track of it now; nor 
has it any idea how much overhead (padding, control bytes) 
the system malloc adds; nor is there a portable interface 
to C's malloc for finding out such things.

Still, I agree it would be nice to have such things <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 15:44:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 07:44:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-542003 ] Compile fails on posixmodule.c
Message-ID: <E16vJKN-00019s-00@usw-sf-web2.sourceforge.net>

Bugs item #542003, was opened at 2002-04-10 15:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542003&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Manic Hawk (manichawk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile fails on posixmodule.c

Initial Comment:
OS: Slackware Linux 7.0
Kernel: 2.4.18
Glibc: 2.1.2
Python: 2.2.1 release (not candidate)
Configure args: ./configure

Compile fails on posixmodule.c (attempted twice, with 
a make distclean between):

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -
I./Include -DHAVE_CONFIG_H   -
c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542003&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 16:33:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 08:33:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-541730 ] IDLE can clobber files
Message-ID: <E16vK63-0004UF-00@usw-sf-web3.sourceforge.net>

Bugs item #541730, was opened at 2002-04-09 20:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541730&group_id=5470

Category: IDLE
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Darnell (bgdarnel)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE can clobber files

Initial Comment:
I just lost some work today when IDLE failed to save my
file.  The file was truncated to 0 bytes, so it wasn't
recoverable by the recycle bin or anything like that. 
I was running Python 2.2 on Win2kPro.  There was no
error message, although IDLE seemed to realize that the
save failed - the asterisk remained in the title bar. 
I tried saving to a different name, but that didn't
work either (although a zero-byte file was created with
the new name).  I know this isn't enough for you to go
on to fix the bug; if I encounter the error again I
will inspect the situation more closely.  

In order to prevent data loss like this in the future,
I'd like to see IDLE make a backup of files before it
saves over them.  I submit the following (untested) patch:

--- IOBinding.py.orig   Tue Apr  9 15:56:00 2002
+++ IOBinding.py        Tue Apr  9 15:59:07 2002
@@ -148,6 +148,11 @@
 
     def writefile(self, filename):
         self.fixlastline()
+       try:
+           if os.path.exists(filename):
+               os.rename(filename, filename+'~')
+       except IOError:
+           pass
         try:
             f = open(filename, "w")
             chars = self.text.get("1.0", "end-1c")


----------------------------------------------------------------------

>Comment By: Ben Darnell (bgdarnel)
Date: 2002-04-10 15:33

Message:
Logged In: YES 
user_id=280

On further consideration, it's not the lack of backups that 
causes the problem, it's the fact that an exception in 
self.text.get can wipe out the file.  Moving the 
self.text.get call to before the file is opened would make 
it safe.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541730&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 16:40:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 08:40:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-482171 ] webchecker dies on file: URLs w/o robots
Message-ID: <E16vKCz-0004ZK-00@usw-sf-web3.sourceforge.net>

Bugs item #482171, was opened at 2001-11-15 12:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470

Category: Demos and Tools
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: webchecker dies on file: URLs w/o robots

Initial Comment:
When webchecker is run on local documents using a file:
URL, it dies if there is not a robots.txt in the root
directory:

cj42289-a(.../python/Doc); python
../Tools/webchecker/webchecker.py file:`pwd`/html/api/
webchecker version 1.24
Traceback (most recent call last):
  File "../Tools/webchecker/webchecker.py", line 858, in ?
    main()
  File "../Tools/webchecker/webchecker.py", line 205,
in main
    c.addroot(arg)
  File "../Tools/webchecker/webchecker.py", line 324,
in addroot
    self.addrobot(root)
  File "../Tools/webchecker/webchecker.py", line 337,
in addrobot
    rp.read()
  File "/usr/local/lib/python2.2/robotparser.py", line
43, in read
    f = opener.open(self.url)
  File "/usr/local/lib/python2.2/urllib.py", line 178,
in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.2/urllib.py", line 405,
in open_file
    return self.open_local_file(url)
  File "/usr/local/lib/python2.2/urllib.py", line 412,
in open_local_file
    stats = os.stat(localname)
OSError: [Errno 2] No such file or directory: '/robots.txt'


----------------------------------------------------------------------

Comment By: Jacques A. Vidrine (nectar)
Date: 2002-04-10 10:00

Message:
Logged In: YES 
user_id=14672

Please see bug ID 541980.  I believe the fix here
(webchecker.py rev 1.25) was incorrect.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 17:41

Message:
Logged In: YES 
user_id=6380

Fixed in webchecker.py rev. 1.25.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 16:43:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 08:43:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-482171 ] webchecker dies on file: URLs w/o robots
Message-ID: <E16vKFQ-0004b6-00@usw-sf-web3.sourceforge.net>

Bugs item #482171, was opened at 2001-11-15 12:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: webchecker dies on file: URLs w/o robots

Initial Comment:
When webchecker is run on local documents using a file:
URL, it dies if there is not a robots.txt in the root
directory:

cj42289-a(.../python/Doc); python
../Tools/webchecker/webchecker.py file:`pwd`/html/api/
webchecker version 1.24
Traceback (most recent call last):
  File "../Tools/webchecker/webchecker.py", line 858, in ?
    main()
  File "../Tools/webchecker/webchecker.py", line 205,
in main
    c.addroot(arg)
  File "../Tools/webchecker/webchecker.py", line 324,
in addroot
    self.addrobot(root)
  File "../Tools/webchecker/webchecker.py", line 337,
in addrobot
    rp.read()
  File "/usr/local/lib/python2.2/robotparser.py", line
43, in read
    f = opener.open(self.url)
  File "/usr/local/lib/python2.2/urllib.py", line 178,
in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.2/urllib.py", line 405,
in open_file
    return self.open_local_file(url)
  File "/usr/local/lib/python2.2/urllib.py", line 412,
in open_local_file
    stats = os.stat(localname)
OSError: [Errno 2] No such file or directory: '/robots.txt'


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-10 11:43

Message:
Logged In: YES 
user_id=6380

Maybe I'm dense, but I don't see the connection.

Can you elaborate?  I've reopened the bug report for your 
convenience.

----------------------------------------------------------------------

Comment By: Jacques A. Vidrine (nectar)
Date: 2002-04-10 10:00

Message:
Logged In: YES 
user_id=14672

Please see bug ID 541980.  I believe the fix here
(webchecker.py rev 1.25) was incorrect.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 17:41

Message:
Logged In: YES 
user_id=6380

Fixed in webchecker.py rev. 1.25.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 17:16:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 09:16:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-482171 ] webchecker dies on file: URLs w/o robots
Message-ID: <E16vKmH-0002FX-00@usw-sf-web2.sourceforge.net>

Bugs item #482171, was opened at 2001-11-15 11:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: webchecker dies on file: URLs w/o robots

Initial Comment:
When webchecker is run on local documents using a file:
URL, it dies if there is not a robots.txt in the root
directory:

cj42289-a(.../python/Doc); python
../Tools/webchecker/webchecker.py file:`pwd`/html/api/
webchecker version 1.24
Traceback (most recent call last):
  File "../Tools/webchecker/webchecker.py", line 858, in ?
    main()
  File "../Tools/webchecker/webchecker.py", line 205,
in main
    c.addroot(arg)
  File "../Tools/webchecker/webchecker.py", line 324,
in addroot
    self.addrobot(root)
  File "../Tools/webchecker/webchecker.py", line 337,
in addrobot
    rp.read()
  File "/usr/local/lib/python2.2/robotparser.py", line
43, in read
    f = opener.open(self.url)
  File "/usr/local/lib/python2.2/urllib.py", line 178,
in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.2/urllib.py", line 405,
in open_file
    return self.open_local_file(url)
  File "/usr/local/lib/python2.2/urllib.py", line 412,
in open_local_file
    stats = os.stat(localname)
OSError: [Errno 2] No such file or directory: '/robots.txt'


----------------------------------------------------------------------

Comment By: Jacques A. Vidrine (nectar)
Date: 2002-04-10 11:16

Message:
Logged In: YES 
user_id=14672

I should have been more clear.

The code in question in webchecker.py expected (correctly)
to handle IOError exceptions from urlopen.  However, due to
bug 541980, urlopen (incorrectly) can raise an OSError
exception when handling 'file:' URLs.

The fix made in rev 1.25 of webchecker.py was to catch both
the IOError and OSError exceptions.  This fix is incorrect,
because urlopen should not be raising OSError for this type
of condition (file not found).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-10 10:43

Message:
Logged In: YES 
user_id=6380

Maybe I'm dense, but I don't see the connection.

Can you elaborate?  I've reopened the bug report for your 
convenience.

----------------------------------------------------------------------

Comment By: Jacques A. Vidrine (nectar)
Date: 2002-04-10 09:00

Message:
Logged In: YES 
user_id=14672

Please see bug ID 541980.  I believe the fix here
(webchecker.py rev 1.25) was incorrect.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 16:41

Message:
Logged In: YES 
user_id=6380

Fixed in webchecker.py rev. 1.25.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 19:07:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 11:07:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-541828 ] Regression in unicodestr.encode()
Message-ID: <E16vMVZ-0006HH-00@usw-sf-web3.sourceforge.net>

Bugs item #541828, was opened at 2002-04-10 03:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Regression in unicodestr.encode()

Initial Comment:
I'm porting over the latest email package to Python
2.3cvs, and I've
had one of my tests fail.  I've narrowed it down to the
following test
case:

a =
u'\u6b63\u78ba\u306b\u8a00\u3046\u3068\u7ffb\u8a33\u306f\u3055\u308c\u3066\u3044\u307e\u305b\u3093\u3002\u4e00\u90e8\u306f\u30c9\u30a4\u30c4\u8a9e\u3067\u3059\u304c\u3001\u3042\u3068\u306f\u3067\u305f\u3089\u3081\u3067\u3059\u3002\u5b9f\u969b\u306b\u306f\u300cWenn
ist das Nunstuck git und'
print repr(a.encode('utf-8', 'replace'))

In Python 2.2.1 I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git und'

but in Python 2.3 cvs I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git u\x00\x00'

Note that the last two characters, which should be `n'
and `d' are now
NULs.  My very limited Tim-enlightened understanding is
that encoding
a string to UTF-8 should never produce a string with NULs.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 20:07

Message:
Logged In: YES 
user_id=21627

It appears that cbWritten can still run above cbAllocated,
namely if a long sequence of 3-byte characters is followed
by a long sequence of 1-byte or 2-byte characters.

I'm still in favour of dropping the resizing of the result
string, and computing the number of bytes in a first run.
The code becomes clearer that way and more performant; see
attached unicode.diff.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 19:09:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 11:09:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-542003 ] Compile fails on posixmodule.c
Message-ID: <E16vMX2-0006Ic-00@usw-sf-web3.sourceforge.net>

Bugs item #542003, was opened at 2002-04-10 16:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542003&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Manic Hawk (manichawk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compile fails on posixmodule.c

Initial Comment:
OS: Slackware Linux 7.0
Kernel: 2.4.18
Glibc: 2.1.2
Python: 2.2.1 release (not candidate)
Configure args: ./configure

Compile fails on posixmodule.c (attempted twice, with 
a make distclean between):

gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I. -
I./Include -DHAVE_CONFIG_H   -
c ./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function `posix_nice':
./Modules/posixmodule.c:1270: warning: implicit 
declaration of function `getpriority'
./Modules/posixmodule.c:1270: `PRIO_PROCESS' 
undeclared (first use in this function)
./Modules/posixmodule.c:1270: (Each undeclared 
identifier is reported only once
./Modules/posixmodule.c:1270: for each function it 
appears in.)
make: *** [Modules/posixmodule.o] Error 1



----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 20:09

Message:
Logged In: YES 
user_id=21627

This appears to be a duplicate of 535545.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542003&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 19:53:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 11:53:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-541828 ] Regression in unicodestr.encode()
Message-ID: <E16vNE5-00045v-00@usw-sf-web2.sourceforge.net>

Bugs item #541828, was opened at 2002-04-10 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Regression in unicodestr.encode()

Initial Comment:
I'm porting over the latest email package to Python
2.3cvs, and I've
had one of my tests fail.  I've narrowed it down to the
following test
case:

a =
u'\u6b63\u78ba\u306b\u8a00\u3046\u3068\u7ffb\u8a33\u306f\u3055\u308c\u3066\u3044\u307e\u305b\u3093\u3002\u4e00\u90e8\u306f\u30c9\u30a4\u30c4\u8a9e\u3067\u3059\u304c\u3001\u3042\u3068\u306f\u3067\u305f\u3089\u3081\u3067\u3059\u3002\u5b9f\u969b\u306b\u306f\u300cWenn
ist das Nunstuck git und'
print repr(a.encode('utf-8', 'replace'))

In Python 2.2.1 I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git und'

but in Python 2.3 cvs I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git u\x00\x00'

Note that the last two characters, which should be `n'
and `d' are now
NULs.  My very limited Tim-enlightened understanding is
that encoding
a string to UTF-8 should never produce a string with NULs.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 18:53

Message:
Logged In: YES 
user_id=38388

I'm not in favour of the precomputation. We already had a
discussion about the performance of this.

About the cbWritten thingie: that was your invention, IIRC :-)
I'll try ripping that bit out again and use pointer arithmetics
instead.

Still, I believe the real cause of the problem is in pymalloc,
since a debugging session indicated that the codec did write
the 'n', 'd' characters. It's the final _PyString_Resize() which
causes these to be dropped during the copying of the
memory block.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 18:07

Message:
Logged In: YES 
user_id=21627

It appears that cbWritten can still run above cbAllocated,
namely if a long sequence of 3-byte characters is followed
by a long sequence of 1-byte or 2-byte characters.

I'm still in favour of dropping the resizing of the result
string, and computing the number of bytes in a first run.
The code becomes clearer that way and more performant; see
attached unicode.diff.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 20:06:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 12:06:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-482171 ] webchecker dies on file: URLs w/o robots
Message-ID: <E16vNQa-0004FJ-00@usw-sf-web2.sourceforge.net>

Bugs item #482171, was opened at 2001-11-15 12:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470

Category: Demos and Tools
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Guido van Rossum (gvanrossum)
Summary: webchecker dies on file: URLs w/o robots

Initial Comment:
When webchecker is run on local documents using a file:
URL, it dies if there is not a robots.txt in the root
directory:

cj42289-a(.../python/Doc); python
../Tools/webchecker/webchecker.py file:`pwd`/html/api/
webchecker version 1.24
Traceback (most recent call last):
  File "../Tools/webchecker/webchecker.py", line 858, in ?
    main()
  File "../Tools/webchecker/webchecker.py", line 205,
in main
    c.addroot(arg)
  File "../Tools/webchecker/webchecker.py", line 324,
in addroot
    self.addrobot(root)
  File "../Tools/webchecker/webchecker.py", line 337,
in addrobot
    rp.read()
  File "/usr/local/lib/python2.2/robotparser.py", line
43, in read
    f = opener.open(self.url)
  File "/usr/local/lib/python2.2/urllib.py", line 178,
in open
    return getattr(self, name)(url)
  File "/usr/local/lib/python2.2/urllib.py", line 405,
in open_file
    return self.open_local_file(url)
  File "/usr/local/lib/python2.2/urllib.py", line 412,
in open_local_file
    stats = os.stat(localname)
OSError: [Errno 2] No such file or directory: '/robots.txt'


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-10 15:06

Message:
Logged In: YES 
user_id=6380

I wouldn't call the fix incorrect. It's harmless.
If 541980 was fixed it wouldn't be necessary, but
who cares.

----------------------------------------------------------------------

Comment By: Jacques A. Vidrine (nectar)
Date: 2002-04-10 12:16

Message:
Logged In: YES 
user_id=14672

I should have been more clear.

The code in question in webchecker.py expected (correctly)
to handle IOError exceptions from urlopen.  However, due to
bug 541980, urlopen (incorrectly) can raise an OSError
exception when handling 'file:' URLs.

The fix made in rev 1.25 of webchecker.py was to catch both
the IOError and OSError exceptions.  This fix is incorrect,
because urlopen should not be raising OSError for this type
of condition (file not found).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-10 11:43

Message:
Logged In: YES 
user_id=6380

Maybe I'm dense, but I don't see the connection.

Can you elaborate?  I've reopened the bug report for your 
convenience.

----------------------------------------------------------------------

Comment By: Jacques A. Vidrine (nectar)
Date: 2002-04-10 10:00

Message:
Logged In: YES 
user_id=14672

Please see bug ID 541980.  I believe the fix here
(webchecker.py rev 1.25) was incorrect.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-11 17:41

Message:
Logged In: YES 
user_id=6380

Fixed in webchecker.py rev. 1.25.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=482171&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 21:37:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 13:37:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-541828 ] Regression in unicodestr.encode()
Message-ID: <E16vOqS-0007x2-00@usw-sf-web3.sourceforge.net>

Bugs item #541828, was opened at 2002-04-10 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470

Category: Unicode
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Regression in unicodestr.encode()

Initial Comment:
I'm porting over the latest email package to Python
2.3cvs, and I've
had one of my tests fail.  I've narrowed it down to the
following test
case:

a =
u'\u6b63\u78ba\u306b\u8a00\u3046\u3068\u7ffb\u8a33\u306f\u3055\u308c\u3066\u3044\u307e\u305b\u3093\u3002\u4e00\u90e8\u306f\u30c9\u30a4\u30c4\u8a9e\u3067\u3059\u304c\u3001\u3042\u3068\u306f\u3067\u305f\u3089\u3081\u3067\u3059\u3002\u5b9f\u969b\u306b\u306f\u300cWenn
ist das Nunstuck git und'
print repr(a.encode('utf-8', 'replace'))

In Python 2.2.1 I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git und'

but in Python 2.3 cvs I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git u\x00\x00'

Note that the last two characters, which should be `n'
and `d' are now
NULs.  My very limited Tim-enlightened understanding is
that encoding
a string to UTF-8 should never produce a string with NULs.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 20:37

Message:
Logged In: YES 
user_id=38388

Fix checked in. Probably does not apply to the 2.2.1 branch
since this uses a different technique.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 18:53

Message:
Logged In: YES 
user_id=38388

I'm not in favour of the precomputation. We already had a
discussion about the performance of this.

About the cbWritten thingie: that was your invention, IIRC :-)
I'll try ripping that bit out again and use pointer arithmetics
instead.

Still, I believe the real cause of the problem is in pymalloc,
since a debugging session indicated that the codec did write
the 'n', 'd' characters. It's the final _PyString_Resize() which
causes these to be dropped during the copying of the
memory block.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 18:07

Message:
Logged In: YES 
user_id=21627

It appears that cbWritten can still run above cbAllocated,
namely if a long sequence of 3-byte characters is followed
by a long sequence of 1-byte or 2-byte characters.

I'm still in favour of dropping the resizing of the result
string, and computing the number of bytes in a first run.
The code becomes clearer that way and more performant; see
attached unicode.diff.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 21:50:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 13:50:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-541828 ] Regression in unicodestr.encode()
Message-ID: <E16vP39-0008Dm-00@usw-sf-web4.sourceforge.net>

Bugs item #541828, was opened at 2002-04-10 01:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Regression in unicodestr.encode()

Initial Comment:
I'm porting over the latest email package to Python
2.3cvs, and I've
had one of my tests fail.  I've narrowed it down to the
following test
case:

a =
u'\u6b63\u78ba\u306b\u8a00\u3046\u3068\u7ffb\u8a33\u306f\u3055\u308c\u3066\u3044\u307e\u305b\u3093\u3002\u4e00\u90e8\u306f\u30c9\u30a4\u30c4\u8a9e\u3067\u3059\u304c\u3001\u3042\u3068\u306f\u3067\u305f\u3089\u3081\u3067\u3059\u3002\u5b9f\u969b\u306b\u306f\u300cWenn
ist das Nunstuck git und'
print repr(a.encode('utf-8', 'replace'))

In Python 2.2.1 I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git und'

but in Python 2.3 cvs I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git u\x00\x00'

Note that the last two characters, which should be `n'
and `d' are now
NULs.  My very limited Tim-enlightened understanding is
that encoding
a string to UTF-8 should never produce a string with NULs.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 20:50

Message:
Logged In: YES 
user_id=38388

Just confirmed: Python 2.2.1 definitely doesn't have
this problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 20:37

Message:
Logged In: YES 
user_id=38388

Fix checked in. Probably does not apply to the 2.2.1 branch
since this uses a different technique.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 18:53

Message:
Logged In: YES 
user_id=38388

I'm not in favour of the precomputation. We already had a
discussion about the performance of this.

About the cbWritten thingie: that was your invention, IIRC :-)
I'll try ripping that bit out again and use pointer arithmetics
instead.

Still, I believe the real cause of the problem is in pymalloc,
since a debugging session indicated that the codec did write
the 'n', 'd' characters. It's the final _PyString_Resize() which
causes these to be dropped during the copying of the
memory block.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 18:07

Message:
Logged In: YES 
user_id=21627

It appears that cbWritten can still run above cbAllocated,
namely if a long sequence of 3-byte characters is followed
by a long sequence of 1-byte or 2-byte characters.

I'm still in favour of dropping the resizing of the result
string, and computing the number of bytes in a first run.
The code becomes clearer that way and more performant; see
attached unicode.diff.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 22:18:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 14:18:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-542181 ] Realloc behavior
Message-ID: <E16vPUQ-00006S-00@usw-sf-web4.sourceforge.net>

Bugs item #542181, was opened at 2002-04-10 21:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542181&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: Realloc behavior

Initial Comment:
I was just looking in obmalloc.c, and found this code 
and comment: 
 
else if (narenas == maxarenas) { 
   /* Grow arenas.  Don't use realloc:  if this 
    * fails, we don't want to lose the base 
    * addresses we already have. 
[...] 
 
Realloc may be safely used here. Realloc's behavior 
on failure is usually misunderstood. It will return 
NULL, but *won't* touch the already allocated memory. 
 
I know there are other constraints in this piece of 
code, but at least this comment may be safely 
removed. 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542181&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 22:27:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 14:27:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-542181 ] Realloc behavior
Message-ID: <E16vPd4-0005hz-00@usw-sf-web1.sourceforge.net>

Bugs item #542181, was opened at 2002-04-10 17:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542181&group_id=5470

Category: Python Interpreter Core
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
>Assigned to: Tim Peters (tim_one)
Summary: Realloc behavior

Initial Comment:
I was just looking in obmalloc.c, and found this code 
and comment: 
 
else if (narenas == maxarenas) { 
   /* Grow arenas.  Don't use realloc:  if this 
    * fails, we don't want to lose the base 
    * addresses we already have. 
[...] 
 
Realloc may be safely used here. Realloc's behavior 
on failure is usually misunderstood. It will return 
NULL, but *won't* touch the already allocated memory. 
 
I know there are other constraints in this piece of 
code, but at least this comment may be safely 
removed. 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-10 17:27

Message:
Logged In: YES 
user_id=31435

I agree, at least about part of this, and will fix the 
comment (in fact we cannot use realloc here, but the stated 
reason for that is bogus).  The debug version of realloc is 
coded incorrectly for this case too, so it's not just a 
comment that's hosed here.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542181&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 22:36:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 14:36:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-541828 ] Regression in unicodestr.encode()
Message-ID: <E16vPlm-0005yy-00@usw-sf-web2.sourceforge.net>

Bugs item #541828, was opened at 2002-04-10 03:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Regression in unicodestr.encode()

Initial Comment:
I'm porting over the latest email package to Python
2.3cvs, and I've
had one of my tests fail.  I've narrowed it down to the
following test
case:

a =
u'\u6b63\u78ba\u306b\u8a00\u3046\u3068\u7ffb\u8a33\u306f\u3055\u308c\u3066\u3044\u307e\u305b\u3093\u3002\u4e00\u90e8\u306f\u30c9\u30a4\u30c4\u8a9e\u3067\u3059\u304c\u3001\u3042\u3068\u306f\u3067\u305f\u3089\u3081\u3067\u3059\u3002\u5b9f\u969b\u306b\u306f\u300cWenn
ist das Nunstuck git und'
print repr(a.encode('utf-8', 'replace'))

In Python 2.2.1 I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git und'

but in Python 2.3 cvs I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git u\x00\x00'

Note that the last two characters, which should be `n'
and `d' are now
NULs.  My very limited Tim-enlightened understanding is
that encoding
a string to UTF-8 should never produce a string with NULs.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 23:36

Message:
Logged In: YES 
user_id=21627

There is no bug in pymalloc. The codec wrote beyond the end
of the allocated buffer, this causes undefined behaviour.
The malloc implemementation could not possibly know that the
data extends beyond the space it provided to the application.

Python 2.2 suffers from the same problem: If you have a
string of 10 characters, it will allocate 30 bytes. In UCS4
mode, if the first 6 characters consume each 4 bytes, this
will consume 24 bytes, leaving 6 bytes (resizing would only
be triggered if 4 bytes or less would be left). Now, if the
remaining 4 characters each consume 2 bytes, the total size
written will be 32 bytes, causing a write into unallocated
memory by 2 bytes. So this is the same problem.

About cbWritten: it was introduced in unicodeobject.c 2.41,
where the checkin message says

  New surrogate support in the UTF-8 codec. By Bill Tutt.

So I'd challenge the claim that this is my doing.

As for computing the size in advance: Your arguments on
performance are not convincing, since your measurements were
flawed.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 22:50

Message:
Logged In: YES 
user_id=38388

Just confirmed: Python 2.2.1 definitely doesn't have
this problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 22:37

Message:
Logged In: YES 
user_id=38388

Fix checked in. Probably does not apply to the 2.2.1 branch
since this uses a different technique.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 20:53

Message:
Logged In: YES 
user_id=38388

I'm not in favour of the precomputation. We already had a
discussion about the performance of this.

About the cbWritten thingie: that was your invention, IIRC :-)
I'll try ripping that bit out again and use pointer arithmetics
instead.

Still, I believe the real cause of the problem is in pymalloc,
since a debugging session indicated that the codec did write
the 'n', 'd' characters. It's the final _PyString_Resize() which
causes these to be dropped during the copying of the
memory block.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 20:07

Message:
Logged In: YES 
user_id=21627

It appears that cbWritten can still run above cbAllocated,
namely if a long sequence of 3-byte characters is followed
by a long sequence of 1-byte or 2-byte characters.

I'm still in favour of dropping the resizing of the result
string, and computing the number of bytes in a first run.
The code becomes clearer that way and more performant; see
attached unicode.diff.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470



From noreply@sourceforge.net  Wed Apr 10 23:22:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 15:22:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-541828 ] Regression in unicodestr.encode()
Message-ID: <E16vQTc-0006KP-00@usw-sf-web1.sourceforge.net>

Bugs item #541828, was opened at 2002-04-09 21:56
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Regression in unicodestr.encode()

Initial Comment:
I'm porting over the latest email package to Python
2.3cvs, and I've
had one of my tests fail.  I've narrowed it down to the
following test
case:

a =
u'\u6b63\u78ba\u306b\u8a00\u3046\u3068\u7ffb\u8a33\u306f\u3055\u308c\u3066\u3044\u307e\u305b\u3093\u3002\u4e00\u90e8\u306f\u30c9\u30a4\u30c4\u8a9e\u3067\u3059\u304c\u3001\u3042\u3068\u306f\u3067\u305f\u3089\u3081\u3067\u3059\u3002\u5b9f\u969b\u306b\u306f\u300cWenn
ist das Nunstuck git und'
print repr(a.encode('utf-8', 'replace'))

In Python 2.2.1 I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git und'

but in Python 2.3 cvs I get

'\xe6\xad\xa3\xe7\xa2\xba\xe3\x81\xab\xe8\xa8\x80\xe3\x81\x86\xe3\x81\xa8\xe7\xbf\xbb\xe8\xa8\xb3\xe3\x81\xaf\xe3\x81\x95\xe3\x82\x8c\xe3\x81\xa6\xe3\x81\x84\xe3\x81\xbe\xe3\x81\x9b\xe3\x82\x93\xe3\x80\x82\xe4\xb8\x80\xe9\x83\xa8\xe3\x81\xaf\xe3\x83\x89\xe3\x82\xa4\xe3\x83\x84\xe8\xaa\x9e\xe3\x81\xa7\xe3\x81\x99\xe3\x81\x8c\xe3\x80\x81\xe3\x81\x82\xe3\x81\xa8\xe3\x81\xaf\xe3\x81\xa7\xe3\x81\x9f\xe3\x82\x89\xe3\x82\x81\xe3\x81\xa7\xe3\x81\x99\xe3\x80\x82\xe5\xae\x9f\xe9\x9a\x9b\xe3\x81\xab\xe3\x81\xaf\xe3\x80\x8cWenn
ist das Nunstuck git u\x00\x00'

Note that the last two characters, which should be `n'
and `d' are now
NULs.  My very limited Tim-enlightened understanding is
that encoding
a string to UTF-8 should never produce a string with NULs.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-10 18:22

Message:
Logged In: YES 
user_id=31435

Note that the debug-build pymalloc does catch the 
overwrite, and complains about it as soon as the fatal 
realloc is entered.  Unfortunately, the overwrite was so 
bad that it also destroyed the "serial number" info the 
debug pymalloc tried to display in its error report.

I agree Martin didn't introduce cbWritten (BTW, that kind 
of Hungarian naming is a sure sign that *someone* at 
Microsoft introduced it <wink>), but don't care where it 
came from.  What I do care about is that there weren't (and 
still aren't) asserts *verifying* that this delicate code 
isn't spilling over the allocated bounds.

About timing, last time we went around on this, 
the "measure once, cut once" version of the code was 
significantly slower in my timing tests too.  I don't care 
so much if the code is tricky, but the trickier the code 
the more asserts are required.

Note that pymalloc's realloc still doesn't give memory back 
when a small block is realloc'ed to a smaller size.  That 
makes the current method enjoy a speed advantage (at the 
expense of using more memory) in the usual cases today, but 
this special advantage may not persist.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 17:36

Message:
Logged In: YES 
user_id=21627

There is no bug in pymalloc. The codec wrote beyond the end
of the allocated buffer, this causes undefined behaviour.
The malloc implemementation could not possibly know that the
data extends beyond the space it provided to the application.

Python 2.2 suffers from the same problem: If you have a
string of 10 characters, it will allocate 30 bytes. In UCS4
mode, if the first 6 characters consume each 4 bytes, this
will consume 24 bytes, leaving 6 bytes (resizing would only
be triggered if 4 bytes or less would be left). Now, if the
remaining 4 characters each consume 2 bytes, the total size
written will be 32 bytes, causing a write into unallocated
memory by 2 bytes. So this is the same problem.

About cbWritten: it was introduced in unicodeobject.c 2.41,
where the checkin message says

  New surrogate support in the UTF-8 codec. By Bill Tutt.

So I'd challenge the claim that this is my doing.

As for computing the size in advance: Your arguments on
performance are not convincing, since your measurements were
flawed.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 16:50

Message:
Logged In: YES 
user_id=38388

Just confirmed: Python 2.2.1 definitely doesn't have
this problem.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 16:37

Message:
Logged In: YES 
user_id=38388

Fix checked in. Probably does not apply to the 2.2.1 branch
since this uses a different technique.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-10 14:53

Message:
Logged In: YES 
user_id=38388

I'm not in favour of the precomputation. We already had a
discussion about the performance of this.

About the cbWritten thingie: that was your invention, IIRC :-)
I'll try ripping that bit out again and use pointer arithmetics
instead.

Still, I believe the real cause of the problem is in pymalloc,
since a debugging session indicated that the codec did write
the 'n', 'd' characters. It's the final _PyString_Resize() which
causes these to be dropped during the copying of the
memory block.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-10 14:07

Message:
Logged In: YES 
user_id=21627

It appears that cbWritten can still run above cbAllocated,
namely if a long sequence of 3-byte characters is followed
by a long sequence of 1-byte or 2-byte characters.

I'm still in favour of dropping the resizing of the result
string, and computing the number of bytes in a first run.
The code becomes clearer that way and more performant; see
attached unicode.diff.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541828&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 00:06:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 16:06:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-542226 ] octal escape doc contradiction
Message-ID: <E16vRAz-0001JD-00@usw-sf-web4.sourceforge.net>

Bugs item #542226, was opened at 2002-04-11 09:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542226&group_id=5470

Category: Regular Expressions
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John Machin (sjmachin)
Assigned to: Fredrik Lundh (effbot)
Summary: octal escape doc contradiction

Initial Comment:
Python version 2.2.1, Library Reference, section 
4.2.1

Following is old, correct 
text:

\number
[snip]
If the first digit of number is 0, or 
number is 3 octal digits long, it will not be interpreted as a group 
match, but as the character with octal value number. 

At the end 
of the section, the following has been appended 
recently:

"""Note that octal escapes are not included. While 
the parser can attempt to determine whether a character is being 
specified by it's ordinal value expressed in octal, doing so yields 
an expression which is relatively difficult to maintain, as the 
same syntax is used to refer to numbered groups. """

The first 
sentence is quite incorrect; remove it.

>>> 
re.sub("\157\157", "\165", "foobar")
'fubar'
>>>

The 
second sentence would even if cleaned up and made correct would 
still be out of place in this manual; remove it.

Also document 
that octal numbers are interpreted modulo \400:

>>> 
re.sub("\557\157", "\165", "foobar")
'fubar'
>>>


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542226&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 05:23:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 21:23:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-542314 ] long file name support broken in windows
Message-ID: <E16vW7m-0004Xr-00@usw-sf-web4.sourceforge.net>

Bugs item #542314, was opened at 2002-04-11 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: long file name support broken in windows

Initial Comment:
>From c.l.py, thread ""

Peter D:
I'm using windows and trying to call os.path.getmtime
() after using os.path.walk... However, I'm choking 
with "[Errno 38] Filename too long" on paths with len 
> ~260

Adding Martin's reply in a new comment (so it is not 
at the top of each and every mail I get on this bug :)

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 05:26:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 21:26:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-542314 ] long file name support broken in windows
Message-ID: <E16vWAA-0004ZQ-00@usw-sf-web4.sourceforge.net>

Bugs item #542314, was opened at 2002-04-11 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Nobody/Anonymous (nobody)
Summary: long file name support broken in windows

Initial Comment:
>From c.l.py, thread ""

Peter D:
I'm using windows and trying to call os.path.getmtime
() after using os.path.walk... However, I'm choking 
with "[Errno 38] Filename too long" on paths with len 
> ~260

Adding Martin's reply in a new comment (so it is not 
at the top of each and every mail I get on this bug :)

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-11 14:26

Message:
Logged In: YES 
user_id=14198

Martin v. Loewis's reply on c.l.py:

Since you are asking for a work-around: cd into one of the 
more nested directories when the path gets longer 
(os.chdir), and use relative paths from then on.

If you want to study how to solve the problem: the relevant 
code snippet is in Modules/posixmodule.c

	/* the library call can blow up if the file name is 
too long! */
	if (pathlen > MAX_PATH) {
		PyMem_Free(pathfree);
		errno = ENAMETOOLONG;
		return posix_error();
	}

There might be different ways to approach this:

- challenge the correctness of the comment:
   - try to establish why the author of that code
     thought that the C library could blow up
   - analyse whether these arguments are still true
     with the current compiler version
  -or-
   - prove the argument wrong by analysing the source 
     code of the C library
- then remove the constraint
-or-
- use different API to achieve the same effect without
  suffering from the constraint.

I'm serious about these suggestions: users would appreciate 
if this gets fixed somehow - apparently, the system allows 
longer file names, and apparently, the system itself can 
deal with that quite well. This
can be only true if the system either doesn't use its C 
library, or if the C library does not have this restriction.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542314&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 07:26:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 23:26:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc
Message-ID: <E16vY2X-0005kt-00@usw-sf-web3.sourceforge.net>

Bugs item #495401, was opened at 2001-12-20 14:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470

Category: Build
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Walter D�rwald (doerwalter)
Assigned to: Martin v. L�wis (loewis)
Summary: Build troubles: --with-pymalloc

Initial Comment:
The build process segfaults with the current CVS 
version when using --with-pymalloc

System is SuSE Linux 7.0

> uname -a
Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 
GMT 2000 i686 unknown
> gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-
linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)

Attached is the complete build log.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 08:26

Message:
Logged In: YES 
user_id=21627

I've revised the patch unicode3.diff to the current code
base (it still includes the assertion at the end); I've also
added a new timing test (utim3.py) which considers the
following cases:
- a string consisting of only spaces
- a string consisting of only spaces, and a single character
that needs three bytes in UTF-8
- a string only consisting of characters that need three bytes.

For all three cases, it tests various sizes of the string,
both below and above the pymalloc threshold. For the current
CVS (unicodeobject.c 2.136: MAL's change to use a variable
overalloc), I get

10 spaces                      20.060
100 spaces                     2.600
200 spaces                     2.030
1000 spaces                    0.930
10000 spaces                   0.690
10 spaces, 3 bytes             23.520
100 spaces, 3 bytes            3.730
200 spaces, 3 bytes            2.470
1000 spaces, 3 bytes           0.980
10000 spaces, 3 bytes          0.690
30 bytes                       24.800
300 bytes                      5.220
600 bytes                      3.830
3000 bytes                     2.480
30000 bytes                    2.230

With unicode3.diff, I get

10 spaces                      19.940
100 spaces                     3.260
200 spaces                     2.340
1000 spaces                    1.650
10000 spaces                   1.450
10 spaces, 3 bytes             21.420
100 spaces, 3 bytes            3.410
200 spaces, 3 bytes            2.420
1000 spaces, 3 bytes           1.660
10000 spaces, 3 bytes          1.450
30 bytes                       22.260
300 bytes                      5.830
600 bytes                      4.700
3000 bytes                     3.740
30000 bytes                    3.540

So it appears that unicode3.diff is more efficient for short
strings, and overallocation is more efficient for long
strings. Since overallocation may waste memory, I still
recommend to integrate unicode3.diff.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-13 13:39

Message:
Logged In: YES 
user_id=38388

Tim, I ran the test on my notebook and guess what:

when compiling Python with -mcpu=pentium I get
    58 vs. 59.8 (with / without patch)

when compiling Python with -mcpu=i686, it's
    65.8 vs. 60.17 (with / without patch)

No idea what chip is used in the notebook.
It's pretty old, though. I used gcc 2.95.2 and
some old SuSE Linux version (glibc 2).

Would be interesting to check this on a 
modern pentium 4 machine and maybe
a more recent sun sparc machine. Oh yes,
and your Cray, of coure ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 22:06

Message:
Logged In: YES 
user_id=31435

MAL, cool -- I saw a major slowdown using the patch too, 
but not nearly as dramatic as you saw, so was curious about 
what could account for that.  Chip, compiler and OS can all 
have major effects.

I assume Martin is using a Pentium box, so assuming your 
notebook is running Linux too, it would be good to get 
another LinTel datapoint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-11 21:50

Message:
Logged In: YES 
user_id=38388

Tim: Yes, I'm still all AMD based... it's Athlon 1200 I'm 
running. PGCC (the Pentium GCC groups version) has
a special AMD optimization mode for Athlon which is
what I'm using. Somebody has to hold up the flag against
the Wintel camp ;-)

Hmm, I could do the same tests on my notebook which
runs on one of those Inteliums. Maybe tomorrow...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 21:06

Message:
Logged In: YES 
user_id=31435

time.time() sucks for benchmarking on Windows (updates at 
about 18Hz).  Running the test as-is, MSVC6 and Win98SE, 
it's 1.3 seconds with current CVS, and 1.7 with 
unicode3.diff.

The quantization error in Windows time.time() is > 0.05 
seconds, so no point pretending there are 3 significant 
digits there; luckily(?), it's apparent there's a major 
difference with just 2 digits.

MAL, are you still using an AMD box?  In a decade, nobody 
else has ever reproduced the timing results you see <wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-11 19:42

Message:
Logged In: YES 
user_id=38388

Ok, with 100000 loops and time.clock() I get:
4.690 - 4.710 without your patch,
9.560 - 9.570 with your patch
(again, without pymalloc and the same compiler/machine
on SuSE 7.1).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-11 19:04

Message:
Logged In: YES 
user_id=21627

time.clock vs. time.time does not make a big difference on
an unloaded machine (except time.time has a higher resolution).
Can you please run the test 10x more often? I then get
12.520 clocks with CVS python, glibc 2.2.4, gcc 2.95, and
10.890 with my patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-11 18:49

Message:
Logged In: YES 
user_id=38388

I get different timings (note that you have to use time.clock() for 
benchmarks, not time.time()):

without your patch: 0.470 seconds
with your patch: 0.960 seconds

This is on Linux with pgcc 2.95.2, glibc 2.2, without pymalloc
(which is the normal configuration).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-11 18:06

Message:
Logged In: YES 
user_id=21627

Marc: Please have a look at pymalloc; it cannot be "fixed".
It is in the nature of a pool allocator that you have to
copy when you want to move between pools - or you have to
waste the extra space.

I agree that UTF-8 coding needs to be fast; that's why I
wrote this patch. I've revised it to fit the current
implementation, and too add the assert that Tim has
requested (unicode3.diff).

For the test case time_utf8.zip (which is a UTF-8 converted
Misc/ACKS), the version that first counts the size is about
10% faster on my system (Linux glibc 2.2.4) (see timings
inside time_utf8.py; #592 is the patched version). So the
price for counting the size turns out to be negligible, and
to offer significant, and is more than compensated for by
the reduction of calls to the memory management system.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-08 23:27

Message:
Logged In: YES 
user_id=38388

Good news, Walter.

Martin:
As I explained in an earlier comment, pymalloc needs to be fixed to better address overallocation. The two pass 
logic would avoid overallocation, but at a high price. Copying memory (if at all needed) is likely to be *much* faster. 
The UTF-8 codec has to be as fast as possible since it is one of the most used codecs in Python's Unicode 
implementation. Also note that I have reduced overallocation to 2*size in the codec.

I suggest to close the bug report.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-07 23:59

Message:
Logged In: YES 
user_id=21627

I still think the current algorithm has serious problems as 
it is based on overallocation, and that it should be 
replaced with an algorithm that counts the memory 
requirements upfront. This will be particularly important 
for pymalloc, but will also avoid unnecessary copies for 
many other malloc implementations.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-02-07 10:58

Message:
Logged In: YES 
user_id=89016

I tried the current CVS and make altinstall runs to 
completion.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-06 19:12

Message:
Logged In: YES 
user_id=38388

I've checked in a patch which fixes the memory allocation problem. Please give it a try and tell me whether this 
fixes your problem, Walter. If so, I'd suggest to close the bug.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-31 20:36

Message:
Logged In: YES 
user_id=31435

Martin, I like your second patch fine, but would like it a 
lot better with

assert(p - PyString_AS_STRING(v) == cbAllocated);

at the end.  Else a piddly change in either loop can cause 
more miserably hard-to-track-down problems.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-31 14:46

Message:
Logged In: YES 
user_id=21627

MAL,
I'm 100% positive that the crash on my system was caused by
the UTF-8 encoding; I've seen it in the debugger overwrite
memory that it doesn't own.

As for unicode.diff: Tim has proposed that this should not
be done, but that 4*size should be allocated in advance.
What do you think?

On unicode2.diff: If pymalloc was changed to shrink the
memory, it would have to copy the original string, since it
would likely be in a different size class. This is less
efficient than the approach taken in unicode2.diff. What
specifically is it that you dislike about first counting the
memory requirements? 

It actually simplifies the code. Notice that the current
code is still buggy with regard to surrogates. If there is a
high surrogate, but not a low one, it will write bogus UTF-8
 (with no lead byte). This is fixed in unicode2.diff as well.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-31 13:48

Message:
Logged In: YES 
user_id=38388

I like the unicode.diff, but not the unicode2.diff. Instead of fixing the UTF-8 codec here we should fix the 
pymalloc implementation, since overallocation is common thing to do and not only used in codecs. (Note 
that all Python extensions will start to use pymalloc too once we enable it per default.)

I don't know whether it's relevant, but I found that core dumps can easily be triggered by mixing the 
various 
memory allocation APIs in Python and the C lib. The bug may not only be related to the UTF-8 codec but 
may also linger in some other extension modules.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-30 11:26

Message:
Logged In: YES 
user_id=21627

I disabled threading, which fortunately gave me memory
watchpoints back. Then I noticed that the final *p=0
corrupted a non-NULL freeblock pointer, slightly decreasing
it. Then following the freeblock pointer, freeblock was
changed to a bogus block, which had its next pointer as
garbage. I had to trace this from the back, of course.

As for overallocation, I wonder whether the UTF-8 encoding
should overallocate at all. unicode2.diff is a modification
where it runs over the string twice, counting the number of
needed bytes the first time. This is likely slower (atleast
if no reallocations occur), but doesn't waste that much
memory (I notice that pymalloc will never copy objects when
they shrink, to return the extra space).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-30 04:54

Message:
Logged In: YES 
user_id=31435

Good eye, Martin!  It's clearly possible for the unpatched 
code to write beyond the memory allocated.  The one thing 
that doesn't jibe is that you said bp is 0x2, which means 3 
of its 4 bytes are 0x00, but UTF-8 doesn't produce 0 bytes 
except for one per \u0000 input character.  Right?  So, if 
this routine is the cause, where are the 0 bytes coming 
from?  (It could be test_unicode sets up a UTF-8 encoding 
case with several \u0000 characters, but if so I didn't 
stumble into it.)  Plausible:  when a new pymalloc "page" 
is allocated, the 40-byte chunks in it are *not* linked 
together at the start.  Instead a NULL pointer is stored at 
just the start of "the first" 40-byte chunk, and pymalloc-- 
on subsequent mallocs --finds that NULL and incrementally 
carves out additional 40-byte chunks.  So as a startup-- 
but not a steady-state --condition, the "next free block" 
pointers will very often be NULLs, and then if this is a 
little-endian machine, writing a single 2 byte at the start 
of a free block would lead to a bogus pointer value of 0x2.

About a fix, I'm in favor of junking all the cleverness 
here, by allocating size*4 bytes from the start.  It's 
overallocating in all normal cases already, so we're going 
to incur the expense of cutting the result string back 
anyway; how *much* we overallocate doesn't matter to speed, 
except that if we don't have to keep checking inside the 
loop, the code gets simpler and quicker and more robust.  
The loop should instead merely assert that cbWritten <= 
cbAllocated at the end of each trip.  Had this been done 
from the start, a debug build would have assert-failed a 
few nanoseconds after the wild store.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-30 02:44

Message:
Logged In: YES 
user_id=21627

I've found one source of troubles, see the attached
unicode.diff. Guido's intuition was right; it was an UCS-4
problem: EncodeUTF8 would over-allocate 3*size bytes, but
can actually write 4*size in the worst case, which occurs in
test_unicode.

I'll leave the patch for review and experiments; it fixes
the problem for me.

The existing adjustment for surrogates is pointless, IMO:
for the surrogate pair, it will allocate 6 bytes UTF-8 in
advance, which is more than actually needed.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-30 00:13

Message:
Logged In: YES 
user_id=21627

It's a Heisenbug. I found that even slightest modifications
to the Python source make it come and go, or appear at
different places. On my system, the crashes normally occur
in the first run (.pyc). So I don't think the order of make
invocations is the source of the problem. It's likely as Tim
says: somebody overwrites memory somewhere.

Unfortunately, even though I can reproduce crashes for the
same pool, for some reason, my gdb memory watches don't
trigger. Tim's approach of checking whether a the value came
from following the free list did not help, either: the bug
disappeared under the change.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-29 23:01

Message:
Logged In: YES 
user_id=6656

Hmm.  I now think that the stuff about extension modules is 
almost certainly a read herring.  What I said about "make && 
make altinstall" vs "make altinstall" still seems to be true, 
though.

If you compile with --with-pydebug, you crash right at the 
end of the second (-O) run of compileall.py -- I suspect this 
is something else, but it might not be.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-29 22:29

Message:
Logged In: YES 
user_id=6656

I don't know if these are helpful observations or not, but 
anyway:

(1) it doesn't core without the --enable-unicode=ucs4 option
(2) if you just run "make altinstall"  the library files are 
installed *and compiled* before the dynamically linked 
modules are built.  Then we don't crash.
(3) if you run "make altinstall" again, we crash.
If you initially ran "make && make install", we crash.
(4) when we crash, it's not long after the unicode tests are 
compiled.

Are these real clues or just red herrings?  I'm afraid I 
can't tell :(


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-29 19:43

Message:
Logged In: YES 
user_id=31435

Ouch.  Boosted priority back to 5, since Martin can 
reproduce it.  Alas, where pymalloc got called *from* is 
almost certainly irrelevant -- we're seeing the end result 
of earlier corruption.

Note that pymalloc is unusually sensitive to off-by-1 
stores, since the chunks it hands out are contiguous 
(there's no hidden bookkeeping padding between them).  
Plausible:  an earlier bogus store went beyond the end of 
its allocated chunk, overwriting the "next free block" 
pointer at the start of a previously free()'ed chunk of the 
same size (rounded up to a multiple of 8; 40 bytes in this 
case).

At the time this blows up, bp is supposed to point to a 
previously free()'ed chunk of size 40 bytes (if there were 
none free()'ed and available, the earlier "pool != pool-
>nextpool" guard should have failed).  The first 4 bytes 
(let's simplify by assuming this is a 32-bit box) of the 
free chunks link the free chunks together, most recently 
free()'ed at the start of the (singly linked) list.  So the 
code at this point is intent on returning bp, and "pool-
>freeblock = *(block **)bp" is setting the 40-byte-chunk 
list header's idea of the *next* available 40-byte chunk.

But bp is bogus.  The value of bp is gotten out of the free 
list headers, the static array usedpools.  This mechanism 
is horridly obscure, an array of pointer pairs that, in 
effect, capture just the first two members of the 
pool_header struct, once for each chunk size.  It's 
possible that someone is overwriting usedpools[4 + 4]-
>freeblock directly with 2, but that seems unlikely.

More likely is that a free() operation linked a 40-byte 
chunk into the list headed at usedpools[4+4]->freeblock 
correctly, and a later bad store overwrote the first 4 
bytes of the free()'ed block with 2.  Then the "pool-
>freeblock = *(block **)bp)" near the start of an 
unexceptional pymalloc would copy the 2 into the list 
header's freeblock without complaint.  The error wouldn't 
show up until a subsequent malloc tried to use it.

So that's one idea to get closer to the cause:  add code to 
dereference pool->freeblock, before the "return (void *)
bp".  If that blows up earlier, then the first four bytes 
of bp were corrupted, and that gives you a useful data 
breakpoint address for the next run.  If it doesn't blow up 
earlier, the corruption will be harder to find, but let's 
count on being lucky at first <wink>.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-29 17:00

Message:
Logged In: YES 
user_id=21627

Ok, I can reproduce it now; I did not 'make install' before.
Here is a gdb back trace

#0  _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417
#1  0x805885c in PyString_FromString (str=0x816c6e8
"checkJoin") at Objects/stringobject.c:136
#2  0x805d772 in PyString_InternFromString (cp=0x816c6e8
"checkJoin") at Objects/stringobject.c:3640
#3  0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0,
name=0x816c6e8 "checkJoin")
    at Python/compile.c:939
#4  0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at
Python/compile.c:1478
#5  0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at
Python/compile.c:1846
#6  0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at
Python/compile.c:1975
#7  0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at
Python/compile.c:1985
#8  0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858)
at Python/compile.c:2020
#9  0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838)
at Python/compile.c:2046
#10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at
Python/compile.c:2072
#11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at
Python/compile.c:2094
...

The access that crashes is *(block **)bp, since bp is 0x2.

Not sure how that happens; I'll investigate (but would
appreciate a clue). It seems that the pool chain got corrupted.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 15:52

Message:
Logged In: YES 
user_id=6380

Aha!  The --enable-unicode=ucs4 is more suspicious than the
--with-pymalloc. I had missed that info when this was first
reported.

Not that I'm any closer to solving it... :-(

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2001-12-29 11:53

Message:
Logged In: YES 
user_id=89016

OK, I did a "make distclean" which removed .o files and
the build directory and redid a "./configure --enable-
unicode=ucs4 --with-pymalloc && make && make altinstall".

The build process still crashes in the same spot:
Compiling /usr/local/lib/python2.2/test/test_urlparse.py ...
make: *** [libinstall] Segmentation fault

I also retried with a fresh untarred Python-2.2.tgz. This 
shows the same behaviour.



----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-29 10:23

Message:
Logged In: YES 
user_id=21627

Atleast I cannot reproduce it, on SuSE 7.3. Can you retry
this, building from a clean source tree (no .o files, no
build directory)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 23:30

Message:
Logged In: YES 
user_id=6380

My prediction: this is irreproducible. Lowering the priority
accordingly.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2001-12-23 13:24

Message:
Logged In: YES 
user_id=89016

Unfortunately no core file was generated. Can I somehow 
force core file generation?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-22 15:42

Message:
Logged In: YES 
user_id=21627

Did that produce a core file? If so, can you attach a gdb
backtrace as well?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 07:37:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 10 Apr 2002 23:37:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-542181 ] Realloc behavior
Message-ID: <E16vYDS-0008KM-00@usw-sf-web1.sourceforge.net>

Bugs item #542181, was opened at 2002-04-10 17:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542181&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gustavo Niemeyer (niemeyer)
Assigned to: Tim Peters (tim_one)
Summary: Realloc behavior

Initial Comment:
I was just looking in obmalloc.c, and found this code 
and comment: 
 
else if (narenas == maxarenas) { 
   /* Grow arenas.  Don't use realloc:  if this 
    * fails, we don't want to lose the base 
    * addresses we already have. 
[...] 
 
Realloc may be safely used here. Realloc's behavior 
on failure is usually misunderstood. It will return 
NULL, but *won't* touch the already allocated memory. 
 
I know there are other constraints in this piece of 
code, but at least this comment may be safely 
removed. 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-11 02:37

Message:
Logged In: YES 
user_id=31435

Fixed in Objects/obmalloc.c; new revision: 2.34

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-10 17:27

Message:
Logged In: YES 
user_id=31435

I agree, at least about part of this, and will fix the 
comment (in fact we cannot use realloc here, but the stated 
reason for that is bogus).  The debug version of realloc is 
coded incorrectly for this case too, so it's not just a 
comment that's hosed here.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542181&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 13:25:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 05:25:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-542226 ] octal escape doc contradiction
Message-ID: <E16vddq-0001LS-00@usw-sf-web3.sourceforge.net>

Bugs item #542226, was opened at 2002-04-11 01:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542226&group_id=5470

Category: Regular Expressions
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Machin (sjmachin)
Assigned to: Fredrik Lundh (effbot)
Summary: octal escape doc contradiction

Initial Comment:
Python version 2.2.1, Library Reference, section 
4.2.1

Following is old, correct 
text:

\number
[snip]
If the first digit of number is 0, or 
number is 3 octal digits long, it will not be interpreted as a group 
match, but as the character with octal value number. 

At the end 
of the section, the following has been appended 
recently:

"""Note that octal escapes are not included. While 
the parser can attempt to determine whether a character is being 
specified by it's ordinal value expressed in octal, doing so yields 
an expression which is relatively difficult to maintain, as the 
same syntax is used to refer to numbered groups. """

The first 
sentence is quite incorrect; remove it.

>>> 
re.sub("\157\157", "\165", "foobar")
'fubar'
>>>

The 
second sentence would even if cleaned up and made correct would 
still be out of place in this manual; remove it.

Also document 
that octal numbers are interpreted modulo \400:

>>> 
re.sub("\557\157", "\165", "foobar")
'fubar'
>>>


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 14:25

Message:
Logged In: YES 
user_id=21627

You are using plain Python strings here, not raw strings -
so the escape characters are used to form bytes in the
string already. The regular expression itself does not
contain a backslash:

>>> s="\557\157" 
>>> ord(s[0])
111
>>> ord("\")
92

So the string s in this example definitely does not start
with a backslash. As a result, it does not demonstrate
whether re.sub supports octal escapes. 

However, since re.sub does support octal escapes, I've
corrected the documentation in libre.tex 1.83.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542226&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 13:39:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 05:39:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-541245 ] __unicode__ not documented
Message-ID: <E16vdrp-0007Ag-00@usw-sf-web2.sourceforge.net>

Bugs item #541245, was opened at 2002-04-08 23:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541245&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: __unicode__ not documented

Initial Comment:
__unicode__() is to unicode() as __str__() is to str(),
however it's difficult to find this in the
documentation.  AFAICT, there's only one mention in the
builtins documentation.  There's no listing under
special methods (in either the lib or lang ref
manuals), and __unicode__ isn't in the indexes.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 14:39

Message:
Logged In: YES 
user_id=21627

This is fixed in ref3.tex 1.86.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541245&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 13:42:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 05:42:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-533188 ] configure.in Assumes cc_r Exists on AIX.
Message-ID: <E16vdu3-0007Cr-00@usw-sf-web2.sourceforge.net>

Bugs item #533188, was opened at 2002-03-21 18:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Michael Hudson (mwh)
Summary: configure.in Assumes cc_r Exists on AIX.

Initial Comment:
Running plain `./configure' on an AIX 3.2.5 machine 
fails.

    configure:966: checking whether the C compiler 
        (cc_r  ) works
    configure:982: cc_r -o conftest    conftest.c  
        1>&5
    ./configure: cc_r: not found
    configure: failed program was:
    
    #line 977 "configure"
    #include "confdefs.h"

    main(){return(0);}

Here's details about the machine.
    
    $ uname -a 
    AIX anon 2 3 000038834100
    $ oslevel
    >3250

cc_r doesn't exist.  cc does.  Running configure thus

    $ ./configure --without-gcc

as a workaround lets configure successfully complete.

configure.in assumes $CC should be cc_r if no
--with-gcc or --without-gcc option is given and if the 
system is AIX.  This seems wrong.  Instead, perhaps it 
should search for the first cc that works with an
order of preference to cc_r, then cc.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-31 22:15

Message:
Logged In: YES 
user_id=6656

I'm proposing to close this, maybe adding a note to the 
README that says "if in difficulties, run ./configure --
without-gcc".

Objections?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-25 14:36

Message:
Logged In: YES 
user_id=6656

I'm getting lost.  What action is needed?

The LINKCC thing was fixed, but I forgot to run autoconf
before building the 2.2.1c1 tarball (sorry).

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-23 01:43

Message:
Logged In: YES 
user_id=911

BTW, the build then halts because 1.295 of configure.in
isn't in the release candidate so LINKCC's definition
in Makefile contains LINKCC and the recursion isn't welcome.
SF bug #477487 apparently.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 22:34

Message:
Logged In: YES 
user_id=911

Replying to a few comments at once...  The C compiler
on AIX comes in many guises.  They are normally all
hard links to the same executable.  /etc/xlc.cfg
defines these identities, so cc_r, if it exists, just
causes a certain set of options to be used.

* extended c compiler aliased as cc_r
cc_r: use        = DEFLT
    crt        = /lib/crt0_r.o
    mcrt       = /lib/mcrt0.o
    gcrt       = /lib/gcrt0.o
    libraries  = -L/usr/lib/dce,-lc_r,-lpthreads
    proflibs   = -L/lib/profiled,-L/usr/lib/profiled
    options    = -H512,-T512,-qlanglvl=extended,
        -qnoro,-D_THREAD_SAFE,-D_CMA_NOWRAPPERS_,
        -qnoroconst

So
http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html
is wrong when it says that you can't use cc with an
appropriate set of options since that's all that cc_r,
cckern, c89, xlc_r, or any of the other hard links
are.

However, not all AIX installations have all bits of
the C compiler available to support all its guises.
So I think it's preferable to use cc_r if it is
available, else fall-back on cc.  And if using cc
hopefully configure's testing for whether threads is
available will determine it isn't.

This is all based on AIX 3, AIX 4 expanded on this in
a few ways.

In summary, I'd agree with donnc `Without cc_r, just
don't enable threads'.  Hopefully, that'll happen
automatically.


----------------------------------------------------------------------

Comment By: Donn Cave (donnc)
Date: 2002-03-22 19:34

Message:
Logged In: YES 
user_id=42839

I can't account for the absence of cc_r, but it doesn't pay to try 
to understand IBM.  The compiler we have here mentions cc_r at the 
top of the "man" (from "info") page, along with xlc_r, cc_r4, cc_r7 
and all permutations.  Looking in /etc/xlC.cfg, _r means "AIX 
threads", _r4 "DCE" [threads] and _r7 is missing.  The "r" stands 
for "reentrant", and I know from experience that the code linked by 
cc_r has extra mutexes etc.  Without cc_r, just don't enable 
threads.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-22 19:00

Message:
Logged In: YES 
user_id=21627

Please have a look at

http://www.openldap.org/lists/openldap-bugs/199812/msg00044.html

This claims that using cc_r on AIX is mandatory, as this is
the the compiler that generates thread-safe executables.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-22 18:54

Message:
Logged In: YES 
user_id=21627

It appears that cc_r got introduced by patch
python.org/sf/403679. I recommend to consult donnc why he
thinks that the compiler is named cc_r on AIX.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 18:10

Message:
Logged In: YES 
user_id=911

PS.  No, it doesn't continue to build sucessfully.  But
that's another bug report I've yet to raise and is
unrelated AFAICS to this problem.

----------------------------------------------------------------------

Comment By: Ralph Corderoy (ralph)
Date: 2002-03-22 18:08

Message:
Logged In: YES 
user_id=911

I've attached a possible patch.  It seems right in theory
but I'm not experienced with autoconf.  Unfortunately, I
can't test the patch because I can't re-generate configure
on this system -- I guess I have incompatible versions of
autoconf, automake, etc.  If you want to email me the
resulting configure I'd be happy to try it.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-22 11:06

Message:
Logged In: YES 
user_id=6656

Thanks for the report.  Can you come up with a patch?  I can
probably bodge something together if not, but it's obviously
easier to test.

Does the build actually work after
./configure --without-gcc
?



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=533188&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 13:48:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 05:48:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python
Message-ID: <E16ve00-0001eZ-00@usw-sf-web3.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 12:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling Python

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 22:49:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 14:49:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-524062 ] USE_CACHE_ALIGNED still helpful?
Message-ID: <E16vmRd-0007a5-00@usw-sf-web3.sourceforge.net>

Bugs item #524062, was opened at 2002-02-28 22:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524062&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Jack Jansen (jackjansen)
Summary: USE_CACHE_ALIGNED still helpful?

Initial Comment:
Jack asked for this report:

"""
MacPython uses it. At the time it was put in it caused 
a 15% increase in Pystones because dictionary entries 
were aligned in cache lines. But: this was in the PPC 
601 and 604 era, I must say that I've never tested 
whether it made any difference on G3 and G4.

Put in a bug report in my name, and one day I'll get 
around to  testing whether it still makes a difference 
on current hardware and rip it out if it doesn't.
"""

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-11 23:49

Message:
Logged In: YES 
user_id=45365

As MacPython normally uses the standard MSL malloc nowadays (and will probably use pymalloc in the future) the benefit of USE_CACHE_ALIGNED has disappeared. I've removed it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524062&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 22:57:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 14:57:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-524062 ] USE_CACHE_ALIGNED still helpful?
Message-ID: <E16vmZQ-0004eP-00@usw-sf-web2.sourceforge.net>

Bugs item #524062, was opened at 2002-02-28 16:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524062&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Jack Jansen (jackjansen)
Summary: USE_CACHE_ALIGNED still helpful?

Initial Comment:
Jack asked for this report:

"""
MacPython uses it. At the time it was put in it caused 
a 15% increase in Pystones because dictionary entries 
were aligned in cache lines. But: this was in the PPC 
601 and 604 era, I must say that I've never tested 
whether it made any difference on G3 and G4.

Put in a bug report in my name, and one day I'll get 
around to  testing whether it still makes a difference 
on current hardware and rip it out if it doesn't.
"""

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-11 17:57

Message:
Logged In: YES 
user_id=31435

Since Jack removed this moldy old symbol, closing this as 
Fixed.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-11 17:49

Message:
Logged In: YES 
user_id=45365

As MacPython normally uses the standard MSL malloc nowadays (and will probably use pymalloc in the future) the benefit of USE_CACHE_ALIGNED has disappeared. I've removed it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=524062&group_id=5470



From noreply@sourceforge.net  Thu Apr 11 22:59:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 14:59:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python
Message-ID: <E16vmbJ-0007hT-00@usw-sf-web3.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling Python

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 23:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 00:06:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 16:06:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-542737 ] Build unable to import w/gcc 3.0.4
Message-ID: <E16vneb-0008TJ-00@usw-sf-web3.sourceforge.net>

Bugs item #542737, was opened at 2002-04-11 17:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Henderson (blueronin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build unable to import w/gcc 3.0.4

Initial Comment:
I'm building on SunOS 5.8 with gcc 3.0.4. I needed to 
recompile 2.2 to add threads for Zope and am not 
having any of the build 'xxx' extensions succeed. My 
original compile with gcc 3.0.2 had succeeded. I've 
tried it with --with-threads and without, same 
results. I downloaded 2.2.1, same results.

Configured with --------------------
 ./configure  --prefix=/ftp/lmp/local

Make output ------------------------

/ftp/lmp/local/src/gnu/python/Python-2.2.1/
 tin/prodfix/dev > make
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -
g -O3 -Wall -Wstrict-prototypes' ./python -
E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -
O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py 
build;; \
esac
running build
running build_ext
building 'struct' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -
I. -I/ftp/lmphr/local/src/gnu/python/Python-
2.2.1/./Include -I/usr/local/include -IInclude/ -
c /ftp/lmphr/local/src/gnu/python/Python-
2.2.1/Modules/structmodule.c -o build/temp.solaris-2.8-
sun4u-2.2/structmodule.o
gcc -shared build/temp.solaris-2.8-sun4u-
2.2/structmodule.o -L/usr/local/lib -o 
build/lib.solaris-2.8-sun4u-2.2/struct.so
WARNING: removing "struct" since importing it failed


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 00:50:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 16:50:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-542751 ] Config option --without-pth not working?
Message-ID: <E16voKZ-0005vX-00@usw-sf-web2.sourceforge.net>

Bugs item #542751, was opened at 2002-04-11 17:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542751&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Henderson (blueronin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Config option --without-pth not working?

Initial Comment:
Running "configure --with-threads --without-pth" seems 
to force libpth to be used. I would have expected it 
to force libpthread instead.

Using "configure --with-threads" causes libpthread to 
be used.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542751&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 01:05:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 11 Apr 2002 17:05:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-542737 ] Build unable to import w/gcc 3.0.4
Message-ID: <E16voZK-0000eA-00@usw-sf-web3.sourceforge.net>

Bugs item #542737, was opened at 2002-04-11 17:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Henderson (blueronin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build unable to import w/gcc 3.0.4

Initial Comment:
I'm building on SunOS 5.8 with gcc 3.0.4. I needed to 
recompile 2.2 to add threads for Zope and am not 
having any of the build 'xxx' extensions succeed. My 
original compile with gcc 3.0.2 had succeeded. I've 
tried it with --with-threads and without, same 
results. I downloaded 2.2.1, same results.

Configured with --------------------
 ./configure  --prefix=/ftp/lmp/local

Make output ------------------------

/ftp/lmp/local/src/gnu/python/Python-2.2.1/
 tin/prodfix/dev > make
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -
g -O3 -Wall -Wstrict-prototypes' ./python -
E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -
O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py 
build;; \
esac
running build
running build_ext
building 'struct' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -
I. -I/ftp/lmphr/local/src/gnu/python/Python-
2.2.1/./Include -I/usr/local/include -IInclude/ -
c /ftp/lmphr/local/src/gnu/python/Python-
2.2.1/Modules/structmodule.c -o build/temp.solaris-2.8-
sun4u-2.2/structmodule.o
gcc -shared build/temp.solaris-2.8-sun4u-
2.2/structmodule.o -L/usr/local/lib -o 
build/lib.solaris-2.8-sun4u-2.2/struct.so
WARNING: removing "struct" since importing it failed


----------------------------------------------------------------------

>Comment By: Mike Henderson (blueronin)
Date: 2002-04-11 18:05

Message:
Logged In: YES 
user_id=201694

The release candidate downloaded from SourceForge compiled 
w/o problems. The download with the problems came from the 
www.python.org site.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 08:30:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 00:30:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-542737 ] Build unable to import w/gcc 3.0.4
Message-ID: <E16vvVm-0007dc-00@usw-sf-web1.sourceforge.net>

Bugs item #542737, was opened at 2002-04-12 01:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Henderson (blueronin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build unable to import w/gcc 3.0.4

Initial Comment:
I'm building on SunOS 5.8 with gcc 3.0.4. I needed to 
recompile 2.2 to add threads for Zope and am not 
having any of the build 'xxx' extensions succeed. My 
original compile with gcc 3.0.2 had succeeded. I've 
tried it with --with-threads and without, same 
results. I downloaded 2.2.1, same results.

Configured with --------------------
 ./configure  --prefix=/ftp/lmp/local

Make output ------------------------

/ftp/lmp/local/src/gnu/python/Python-2.2.1/
 tin/prodfix/dev > make
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -
g -O3 -Wall -Wstrict-prototypes' ./python -
E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -
O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py 
build;; \
esac
running build
running build_ext
building 'struct' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -
I. -I/ftp/lmphr/local/src/gnu/python/Python-
2.2.1/./Include -I/usr/local/include -IInclude/ -
c /ftp/lmphr/local/src/gnu/python/Python-
2.2.1/Modules/structmodule.c -o build/temp.solaris-2.8-
sun4u-2.2/structmodule.o
gcc -shared build/temp.solaris-2.8-sun4u-
2.2/structmodule.o -L/usr/local/lib -o 
build/lib.solaris-2.8-sun4u-2.2/struct.so
WARNING: removing "struct" since importing it failed


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 09:30

Message:
Logged In: YES 
user_id=21627

Can you please manually invoke the gcc command lines to
build struct? Then please try to import it in the
interpreter, and report any error messages you get in doing so.

----------------------------------------------------------------------

Comment By: Mike Henderson (blueronin)
Date: 2002-04-12 02:05

Message:
Logged In: YES 
user_id=201694

The release candidate downloaded from SourceForge compiled 
w/o problems. The download with the problems came from the 
www.python.org site.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 10:17:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 02:17:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-542912 ] Distutils readme outdated
Message-ID: <E16vxB4-00069e-00@usw-sf-web4.sourceforge.net>

Bugs item #542912, was opened at 2002-04-12 11:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542912&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Greg Ward (gward)
Summary: Distutils readme outdated

Initial Comment:
The distutils readme file is outdated. It says the documentation isn't part of the standard python docs (it is, nowadays) and points you to the SIG page, where you find outdated documentation.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542912&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 12:31:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 04:31:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16vzGg-0007iP-00@usw-sf-web4.sourceforge.net>

Bugs item #530070, was opened at 2002-03-15 06:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 19:30

Message:
Logged In: YES 
user_id=146903

Please reconsider this patch.  My patch in bug #504343 was
designed to let me use a descriptor for the __doc__
attribute of some of my classes in PyGTK.

I add some information in the docstrings is looked up via
introspection (so that it is in sync with the objects I am
wrapping, and also to avoid the startup overhead), which is
why I wanted to use a descriptor.

Your patch means that all classes (which are non heap type)
now return None when instead of calling the descriptor.  For
heap type classes, it won't call the descriptor's
tp_descr_get() method if __doc__ happens to be a descriptor
-- instead returning the descriptor itself.

Would it be possible to reconsider this fix?  If not for
2.2.1, at least for 2.3.  Maybe just adding an extra str()
call in pydoc/inspect would fix the problem.

Being able to use descriptors for the __doc__ attribute in
order to load docs lazily may be useful for other purposes
as well (not just pygtk).

Would it be better open a new bug for this, or reopen this
report?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-18 03:00

Message:
Logged In: YES 
user_id=31435

I applied type2.txt and inspect3.txt to the trunk and to 
release22-maint.  If you believe there are other bugs here 
that need fixing day, please open new bug reports.

Lib/inspect.py
    new revision: 1.28
    new revision: 1.26.10.2
Objects/typeobject.c
    new revision: 2.130
    new revision: 2.126.4.4

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-16 02:55

Message:
Logged In: YES 
user_id=6380

Indeed, but that's a different problem worthy of a separate
bug report. It happens in the unpatched code too, so I don't
think it is a result of my patch -- it just so happens that
your patch also addressed this. But I believe getdoc()
should work for Unicode strings just fine.

I've uploaded inspect3.txt which addresses a different
cosmetic issue but is otherwise the same as inspect2.txt.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-16 02:42

Message:
Logged In: YES 
user_id=21627

Your inspect patch has undesirable results. Given

class Foo:
  u"Autor: v. L�wis"

help(Foo) will produce a UnicodeError. This is undesirable,
IMO - it should better just ignore the doc string.

It may be sensible to ignore this for now, hoping that
output devices which support full Unicode become available
(actually, the pydoc web server, can, in principle, support
this case well).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-16 02:27

Message:
Logged In: YES 
user_id=6380

I've appended a better version (IMO) of the inspect patch. 
I find it ugly to have to catch UnicodeError with a comment
explaining it. My version (inspect2.txt) leaves nothing to
the imagination. It also makes sure that there's an explicit
return in each path through the function.

Random gripe: why doesn't inspect.py use string methods? The
string module looks soooooooo dorky...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-16 02:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-16 01:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 23:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-15 17:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 08:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 08:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 13:27:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 05:27:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16w090-0005dm-00@usw-sf-web2.sourceforge.net>

Bugs item #530070, was opened at 2002-03-14 23:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 14:27

Message:
Logged In: YES 
user_id=21627

James, it would be better to submit a new bug report for
this. I have problems figuring out what it is that you want
to do, so please include a small example, saying what it is
that you expect to happen, and what happens instead.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 13:30

Message:
Logged In: YES 
user_id=146903

Please reconsider this patch.  My patch in bug #504343 was
designed to let me use a descriptor for the __doc__
attribute of some of my classes in PyGTK.

I add some information in the docstrings is looked up via
introspection (so that it is in sync with the objects I am
wrapping, and also to avoid the startup overhead), which is
why I wanted to use a descriptor.

Your patch means that all classes (which are non heap type)
now return None when instead of calling the descriptor.  For
heap type classes, it won't call the descriptor's
tp_descr_get() method if __doc__ happens to be a descriptor
-- instead returning the descriptor itself.

Would it be possible to reconsider this fix?  If not for
2.2.1, at least for 2.3.  Maybe just adding an extra str()
call in pydoc/inspect would fix the problem.

Being able to use descriptors for the __doc__ attribute in
order to load docs lazily may be useful for other purposes
as well (not just pygtk).

Would it be better open a new bug for this, or reopen this
report?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-17 20:00

Message:
Logged In: YES 
user_id=31435

I applied type2.txt and inspect3.txt to the trunk and to 
release22-maint.  If you believe there are other bugs here 
that need fixing day, please open new bug reports.

Lib/inspect.py
    new revision: 1.28
    new revision: 1.26.10.2
Objects/typeobject.c
    new revision: 2.130
    new revision: 2.126.4.4

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 19:55

Message:
Logged In: YES 
user_id=6380

Indeed, but that's a different problem worthy of a separate
bug report. It happens in the unpatched code too, so I don't
think it is a result of my patch -- it just so happens that
your patch also addressed this. But I believe getdoc()
should work for Unicode strings just fine.

I've uploaded inspect3.txt which addresses a different
cosmetic issue but is otherwise the same as inspect2.txt.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-15 19:42

Message:
Logged In: YES 
user_id=21627

Your inspect patch has undesirable results. Given

class Foo:
  u"Autor: v. L�wis"

help(Foo) will produce a UnicodeError. This is undesirable,
IMO - it should better just ignore the doc string.

It may be sensible to ignore this for now, hoping that
output devices which support full Unicode become available
(actually, the pydoc web server, can, in principle, support
this case well).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 19:27

Message:
Logged In: YES 
user_id=6380

I've appended a better version (IMO) of the inspect patch. 
I find it ugly to have to catch UnicodeError with a comment
explaining it. My version (inspect2.txt) leaves nothing to
the imagination. It also makes sure that there's an explicit
return in each path through the function.

Random gripe: why doesn't inspect.py use string methods? The
string module looks soooooooo dorky...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 19:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-15 18:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 16:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-15 10:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 01:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 01:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 14:18:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 06:18:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w0x4-0006G2-00@usw-sf-web2.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 21:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 14:24:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 06:24:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-530070 ] pydoc regression
Message-ID: <E16w12d-0006KK-00@usw-sf-web2.sourceforge.net>

Bugs item #530070, was opened at 2002-03-15 06:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Closed
Resolution: Accepted
Priority: 7
Submitted By: Tim Peters (tim_one)
Assigned to: Tim Peters (tim_one)
Summary: pydoc regression

Initial Comment:
In current CVS trunk and release22-maint branch:

C:\Pyt>python
Python 2.2.1a1 (#32, Mar 14 2002, 14:10:11) [MSC 32 
bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import __builtin__
>>> help(__builtin__)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "C:\Pyt\lib\site.py", line 279, in __call__
    return pydoc.help(*args, **kwds)
  File "C:\Pyt\lib\pydoc.py", line 1509, in __call__
    self.help(request)
  File "C:\Pyt\lib\pydoc.py", line 1545, in help
    else: doc(request, 'Help on %s:')
  File "C:\Pyt\lib\pydoc.py", line 1340, in doc
    pager(title % (desc + suffix) + '\n\n' + 
text.document(thing, name))
  File "C:\Pyt\lib\pydoc.py", line 267, in document
    if inspect.ismodule(object): return apply
(self.docmodule, args)
  File "C:\Pyt\lib\pydoc.py", line 960, in docmodule
    contents.append(self.document(value, key, name))
  File "C:\Pyt\lib\pydoc.py", line 268, in document
    if inspect.isclass(object): return apply
(self.docclass, args)
  File "C:\Pyt\lib\pydoc.py", line 1005, in docclass
    doc = getdoc(object)
  File "C:\Pyt\lib\pydoc.py", line 66, in getdoc
    result = inspect.getdoc(object) or 
inspect.getcomments(object)
  File "C:\Pyt\lib\inspect.py", line 267, in getdoc
    lines = string.split(string.expandtabs
(object.__doc__), '\n')
  File "C:\Pyt\lib\string.py", line 298, in expandtabs
    return s.expandtabs(tabsize)
AttributeError: 'member_descriptor' object has no 
attribute 'expandtabs'
>>>

help(__builtin__) worked in 2.2.  Trying to browse the 
__builtin__ module from GUI pydoc crashes pydoc for 
the same reason.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:24

Message:
Logged In: YES 
user_id=146903

I have openeed bug #542984 to track this issue.  Please add
yourself to the CC list if you are interested.  I will
attach a patch for inspect.py to that bug that solves the
above pydoc error shortly.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 20:27

Message:
Logged In: YES 
user_id=21627

James, it would be better to submit a new bug report for
this. I have problems figuring out what it is that you want
to do, so please include a small example, saying what it is
that you expect to happen, and what happens instead.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 19:30

Message:
Logged In: YES 
user_id=146903

Please reconsider this patch.  My patch in bug #504343 was
designed to let me use a descriptor for the __doc__
attribute of some of my classes in PyGTK.

I add some information in the docstrings is looked up via
introspection (so that it is in sync with the objects I am
wrapping, and also to avoid the startup overhead), which is
why I wanted to use a descriptor.

Your patch means that all classes (which are non heap type)
now return None when instead of calling the descriptor.  For
heap type classes, it won't call the descriptor's
tp_descr_get() method if __doc__ happens to be a descriptor
-- instead returning the descriptor itself.

Would it be possible to reconsider this fix?  If not for
2.2.1, at least for 2.3.  Maybe just adding an extra str()
call in pydoc/inspect would fix the problem.

Being able to use descriptors for the __doc__ attribute in
order to load docs lazily may be useful for other purposes
as well (not just pygtk).

Would it be better open a new bug for this, or reopen this
report?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-18 03:00

Message:
Logged In: YES 
user_id=31435

I applied type2.txt and inspect3.txt to the trunk and to 
release22-maint.  If you believe there are other bugs here 
that need fixing day, please open new bug reports.

Lib/inspect.py
    new revision: 1.28
    new revision: 1.26.10.2
Objects/typeobject.c
    new revision: 2.130
    new revision: 2.126.4.4

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-16 02:55

Message:
Logged In: YES 
user_id=6380

Indeed, but that's a different problem worthy of a separate
bug report. It happens in the unpatched code too, so I don't
think it is a result of my patch -- it just so happens that
your patch also addressed this. But I believe getdoc()
should work for Unicode strings just fine.

I've uploaded inspect3.txt which addresses a different
cosmetic issue but is otherwise the same as inspect2.txt.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-16 02:42

Message:
Logged In: YES 
user_id=21627

Your inspect patch has undesirable results. Given

class Foo:
  u"Autor: v. L�wis"

help(Foo) will produce a UnicodeError. This is undesirable,
IMO - it should better just ignore the doc string.

It may be sensible to ignore this for now, hoping that
output devices which support full Unicode become available
(actually, the pydoc web server, can, in principle, support
this case well).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-16 02:27

Message:
Logged In: YES 
user_id=6380

I've appended a better version (IMO) of the inspect patch. 
I find it ugly to have to catch UnicodeError with a comment
explaining it. My version (inspect2.txt) leaves nothing to
the imagination. It also makes sure that there's an explicit
return in each path through the function.

Random gripe: why doesn't inspect.py use string methods? The
string module looks soooooooo dorky...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-16 02:14

Message:
Logged In: YES 
user_id=31435

Thanks, fellows!  Let's leave this assigned to me.  I'll 
get to it over the weekend (if not toady).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-16 01:39

Message:
Logged In: YES 
user_id=21627

I recommend to guarantee that inspect.getdoc always returns
a string or None. The attached patch should cover all cases
discussed so far: if __doc__ is a non-string object, it will
produce a string version of it - somewhat ugly, but not
catastrophic. If it is a Unicode object, it will return
nothing if that does not convert into a byte string.

Together with Guido's patch, this should bring us back to
the 2.2 state.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-15 23:07

Message:
Logged In: YES 
user_id=6380

Hm, that doesn't solve all cases. E.g.
types.FunctionType.__doc__ is None in 2.2, but returns a
descriptor in current CVS, and still after your patch.

I've attached a new patch that looks at the HEAPTYPE flag.
When the HEAPTYPE flag is clear, it's a type defined in C,
and we should believe tp_doc. When HEAPTYPE is set, it's a
new-style class defined in Python, and we should believe
__dict__['__doc__'].

But pydoc is still broken, and needs to be fixed, because
one could define a type in Python that has a __doc__
descriptor for its instances, and then pydoc would still do
the wrong thing.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-15 17:57

Message:
Logged In: YES 
user_id=21627

This was changed with typeobject.c 2.127, which changed
__doc__ access to always look into the __dict__ and never
into  tp_doc, to allow for Unicode doc strings.

The attached patch partially reverts this change: it now
duplicates tp_doc if present, and only returns
__dict__['__doc__'] if tp_doc is NULL.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-15 08:48

Message:
Logged In: YES 
user_id=31435

Well, it's obviously not expected by pydoc <wink>.  In 2.2, 
__builtin__.property.__doc__ was a string.  I've no idea 
why it changed, but it doesn't smell right to me.  Maybe 
Guido knows?  Assigning to him just in case.

----------------------------------------------------------------------

Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-15 08:13

Message:
Logged In: YES 
user_id=11375

The fundamental problem is that __builtin__.property.__doc__ 

returns an object of type 'member_descriptor', not a string.
Is that 
expected?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=530070&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 14:35:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 06:35:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w1DT-0003PQ-00@usw-sf-web1.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 13:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-04-12 13:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 14:37:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 06:37:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w1FD-0001Cu-00@usw-sf-web3.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 21:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 21:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 14:39:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 06:39:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w1Gi-0003S1-00@usw-sf-web1.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 21:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 21:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 15:23:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 07:23:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w1xh-00072u-00@usw-sf-web2.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 15:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 16:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 15:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 15:33:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 07:33:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w27P-0001RO-00@usw-sf-web4.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 15:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 16:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 16:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 15:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 16:06:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 08:06:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w2dE-0007U3-00@usw-sf-web2.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 21:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 23:06

Message:
Logged In: YES 
user_id=146903

Maybe getting pydoc to ignore any __doc__ attributes (that
is, what gets returned by getattr) that weren't strings or
unicode would work.

As for using a different metatype, a reason for getting this
into the the standard metatype is that it is also an
inconsistency between how new and old style classes act, and
is fairly easy to reconcile (granted descriptors didn't
exist in python < 2.2, but everytime new style classes act a
bit differently, people seem to start submitting pygtk bug
reports).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 22:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 22:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 21:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 16:29:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 08:29:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16w2zb-0004jO-00@usw-sf-web1.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 15:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 17:29

Message:
Logged In: YES 
user_id=21627

This is not (primarily) a pydoc issue: with your change,
property.__doc__ gets changed. pydoc could ignore the object
returned, but then property would have no documentation at
all - even though there is a tp_doc in it. So I don't see
any easy solution. If you do, please attach a patch for the
current CVS (we can then decide whether to backport it to
2.2.2).

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 17:06

Message:
Logged In: YES 
user_id=146903

Maybe getting pydoc to ignore any __doc__ attributes (that
is, what gets returned by getattr) that weren't strings or
unicode would work.

As for using a different metatype, a reason for getting this
into the the standard metatype is that it is also an
inconsistency between how new and old style classes act, and
is fairly easy to reconcile (granted descriptors didn't
exist in python < 2.2, but everytime new style classes act a
bit differently, people seem to start submitting pygtk bug
reports).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 16:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 16:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 15:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 19:48:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 11:48:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16w662-0004Q1-00@usw-sf-web4.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 20:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 20:16:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 12:16:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16w6XA-0004k6-00@usw-sf-web4.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Neil Schemenauer (nascheme)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 21:52:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 13:52:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-528748 ] range() description: rewording suggested
Message-ID: <E16w81c-0006Cn-00@usw-sf-web3.sourceforge.net>

Bugs item #528748, was opened at 2002-03-12 00:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528748&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Colin J. Williams (cjwhrh)
Assigned to: Nobody/Anonymous (nobody)
Summary: range() description: rewording suggested

Initial Comment:
The help now has: 
     range([start,] stop[, step]) 
     This is a versatile function to create lists containing arithmetic
     progressions. It is most often used in for loops. The arguments
     must be plain integers. If the step argument is omitted, it
     defaults to 1. If the start argument is omitted, it defaults to
     0. The full form returns a list of plain integers [start, start +
     step, start + 2 * step, ...].  If step is positive, the last
     element is the largest start + i * step less than stop; if step is
     negative, the last element is the largest start + i * step greater
     than stop. step must not be zero (or else ValueError is raised). 

It might say:   

     range([start= 0,] stop[, step= 1]) 
     This function creates a list containing an arithmetic progression.
     The arguments must be integers.   If only one argument is passed it 
     is the 'stop' value, if two values are passed then the first is the
     'start' value and the second the 'stop' value.
     The function returns a list of integers [start, start + step, start
     + 2 * step, ...]. The 'step' must not be zero; if 'step' is positive, 
     the last element is the largest; if  'step' is negative, the last
     element is the smallest.
-----------------------------------------------------------
Using Python 2.2

The main intent is to clarify the usage of the optional arguments.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-04-12 20:52

Message:
Logged In: YES 
user_id=80475

IMO, the current version is clearer than the re-write.  
Also, the docs add further clarity by showing 7 examples.  
The proposed documentation style, range([start=0,] stop
[,step=1 ]) is inconsistent with the style used in the rest 
of the docs.

A side note, the docstring for range() is shorter and 
clearer than both of the above:

range(...)
    range([start,] stop[, step]) -> list of integers
    
    Return a list containing an arithmetic progression of 
integers.  range(i, j) returns [i, i+1, i+2, ..., j-1]; 
start (!) defaults to 0.  When step is given, it specifies 
the increment (or decrement).  For example, range(4) 
returns [0, 1, 2, 3].  The end point is omitted!  These are 
exactly the valid indices for a list of 4 elements.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=528748&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 22:45:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 14:45:40 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-543222 ] IDLE Shell window RunScript warning
Message-ID: <E16w8rU-0000fT-00@usw-sf-web1.sourceforge.net>

Feature Requests item #543222, was opened at 2002-04-12 21:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=543222&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Raymond Hettinger (rhettinger)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE Shell window RunScript warning 

Initial Comment:
Alter IDLE's ScriptBinding.py to provide a warning if 
called from the shell window instead of a program 
window.

Also, consider providing a warning for File Save or 
SaveAs from the shell window.

The purpose of the warnings is handle a newbie problem 
of typing a program in the interpreter, trying to save 
it from there with File SaveAs mymprog.py, and trying 
to run it with F5 from the shell window.

Here is an except of a dialogue on help@python.org:

[beginner]
'''I have several programs I've written and saved.  I 
have saved them as ' save ' , ' save as ' , ' save 
copy ';  but when I try to run the program I get the 
same response from the GUI, name error: name ' ' not 
defined.  The exact procedure I use is: I bring up the 
GUI; click on file; click open; click the program I 
want to run.  Then when that window opens I click 
Edit; then Run Script. When that opens I type ; 
filename ( )  to run the program and all I get is " 
filename not defined" which I'm assuming means I have 
to rewrite the entire program each time I want to use 
it.'''

[helper]
'''IDLE has an interpreted mode (indicated by the >>> 
prompt) -- that is not the place to write and save 
your program.  Select File New to create a new blank 
page for your program. Type in the program (only 
once!) and select File SaveAs myprog.py.  Next, press 
F5 which will run your program. '''

[beginner]
''' So, your saying WRITE the program on the blank 
screen , the one without the prompts, etc ? Then save 
it to file "save as" ?  I never knew that was the way 
it's to be done. I've written every program I've done 
on the idle screen.  I really appreciate your help '''






----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=543222&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 23:00:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 15:00:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16w965-0006aC-00@usw-sf-web4.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Neil Schemenauer (nascheme)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 23:27:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 15:27:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16w9WN-00017K-00@usw-sf-web1.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Neil Schemenauer (nascheme)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 23:39:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 15:39:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16w9hc-0001FK-00@usw-sf-web1.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Neil Schemenauer (nascheme)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:39

Message:
Logged In: YES 
user_id=31435

OK, it *is* the frameobject free_list that's screwing us 
here.  Disable that mechanism, and the fleak2.py output is 
steady over time, and the process doesn't grow over time.

gc is triggered by an excess of allocations over 
deallocations, by some delta N.  After the first N frames 
in cycles are allocated, gc cleans them up, but they all go 
into the free_list.  Then it takes N+N frames in cycles 
before gc is triggered again (the first N come out of the 
free_list so don't bump the allocation count at all), and 
all N+N are returned to the free_list.  Then it takes N+N+N 
frames in cycles before gc is triggered again, etc.  Over 
time, the number of frames in the free_list grows without 
bound.

I'm thinking about putting a bound on it.  That is, if 
frame_dealloc sees there are already K frames on free_list, 
free the memory instead of keeping it devoted to frames 
forever.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 23:54:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 15:54:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16w9wK-0007A3-00@usw-sf-web4.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 18:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Neil Schemenauer (nascheme)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-12 22:54

Message:
Logged In: YES 
user_id=35752

Sounds like a sensible solution.  I think this is a 
problem with all GC collected objects that use a free list.
I can't think of a nice general solution for it though (other
than removing the other free lists :).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 22:39

Message:
Logged In: YES 
user_id=31435

OK, it *is* the frameobject free_list that's screwing us 
here.  Disable that mechanism, and the fleak2.py output is 
steady over time, and the process doesn't grow over time.

gc is triggered by an excess of allocations over 
deallocations, by some delta N.  After the first N frames 
in cycles are allocated, gc cleans them up, but they all go 
into the free_list.  Then it takes N+N frames in cycles 
before gc is triggered again (the first N come out of the 
free_list so don't bump the allocation count at all), and 
all N+N are returned to the free_list.  Then it takes N+N+N 
frames in cycles before gc is triggered again, etc.  Over 
time, the number of frames in the free_list grows without 
bound.

I'm thinking about putting a bound on it.  That is, if 
frame_dealloc sees there are already K frames on free_list, 
free the memory instead of keeping it devoted to frames 
forever.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 22:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 22:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 19:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Fri Apr 12 23:55:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 15:55:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-543244 ] installation atop 2.2 fails
Message-ID: <E16w9xK-0007XO-00@usw-sf-web3.sourceforge.net>

Bugs item #543244, was opened at 2002-04-12 17:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation atop 2.2 fails

Initial Comment:
Installing Python 2.2.1 atop Python 2.2 on cygwin 
fails at the last stage when it tries to create a 
link from /usr/bin/python.exe -> /usr/bin/python-
2.2.exe. Since the link already exists, installation 
stops.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 00:05:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 16:05:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16wA70-0007dg-00@usw-sf-web3.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Tim Peters (tim_one)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-12 19:05

Message:
Logged In: YES 
user_id=31435

Reassigned to me.

Bernhard, can you suggest where the docs could say 
something in 2.1 that would do you any good?  And/or what 
they could say that would help?  Documenting cases where 
cycles can cause leaks hasn't appeared to do much good over 
the years -- if someone doesn't already know that assigning 
the current frame to a local vrbl in that frame causes a 
cycle, or why such a cycle leaks before 2.2, they're not 
easy things to get across.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-12 18:54

Message:
Logged In: YES 
user_id=35752

Sounds like a sensible solution.  I think this is a 
problem with all GC collected objects that use a free list.
I can't think of a nice general solution for it though (other
than removing the other free lists :).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:39

Message:
Logged In: YES 
user_id=31435

OK, it *is* the frameobject free_list that's screwing us 
here.  Disable that mechanism, and the fleak2.py output is 
steady over time, and the process doesn't grow over time.

gc is triggered by an excess of allocations over 
deallocations, by some delta N.  After the first N frames 
in cycles are allocated, gc cleans them up, but they all go 
into the free_list.  Then it takes N+N frames in cycles 
before gc is triggered again (the first N come out of the 
free_list so don't bump the allocation count at all), and 
all N+N are returned to the free_list.  Then it takes N+N+N 
frames in cycles before gc is triggered again, etc.  Over 
time, the number of frames in the free_list grows without 
bound.

I'm thinking about putting a bound on it.  That is, if 
frame_dealloc sees there are already K frames on free_list, 
free the memory instead of keeping it devoted to frames 
forever.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 00:09:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 16:09:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-543244 ] installation atop 2.2 fails
Message-ID: <E16wAAF-0007JP-00@usw-sf-web4.sourceforge.net>

Bugs item #543244, was opened at 2002-04-12 18:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470

Category: Installation
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation atop 2.2 fails

Initial Comment:
Installing Python 2.2.1 atop Python 2.2 on cygwin 
fails at the last stage when it tries to create a 
link from /usr/bin/python.exe -> /usr/bin/python-
2.2.exe. Since the link already exists, installation 
stops.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-12 19:09

Message:
Logged In: YES 
user_id=31435

Change Group to Platform-specific.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 01:03:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 17:03:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16wB0n-00057j-00@usw-sf-web2.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: None
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Tim Peters (tim_one)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-12 20:03

Message:
Logged In: YES 
user_id=31435

Neil, are there other gcable containers that use free 
lists?  Offhand I could only think of tuples, but they 
already put a bound on the their free list size 
(MAXSAVEDTUPLES).  Of course I agree it is a general 
problem.

Another approach could expose part of the guts of 
_PyObject_GC_Malloc, and tell free-list addicts (FLAs) they 
have to call that on every "virtual" allocation; similarly 
for virtual deallocation.  The "excess" approach remains, I 
think, a clever and solid one, and from that view "the 
problem" is that the FLAs simply don't participate in it.  
OTOH, FLAs are using a free-list because they're keen to 
make allocation as fast as possible, so making newing 
external calls is unattractive on that ground.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 19:05

Message:
Logged In: YES 
user_id=31435

Reassigned to me.

Bernhard, can you suggest where the docs could say 
something in 2.1 that would do you any good?  And/or what 
they could say that would help?  Documenting cases where 
cycles can cause leaks hasn't appeared to do much good over 
the years -- if someone doesn't already know that assigning 
the current frame to a local vrbl in that frame causes a 
cycle, or why such a cycle leaks before 2.2, they're not 
easy things to get across.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-12 18:54

Message:
Logged In: YES 
user_id=35752

Sounds like a sensible solution.  I think this is a 
problem with all GC collected objects that use a free list.
I can't think of a nice general solution for it though (other
than removing the other free lists :).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:39

Message:
Logged In: YES 
user_id=31435

OK, it *is* the frameobject free_list that's screwing us 
here.  Disable that mechanism, and the fleak2.py output is 
steady over time, and the process doesn't grow over time.

gc is triggered by an excess of allocations over 
deallocations, by some delta N.  After the first N frames 
in cycles are allocated, gc cleans them up, but they all go 
into the free_list.  Then it takes N+N frames in cycles 
before gc is triggered again (the first N come out of the 
free_list so don't bump the allocation count at all), and 
all N+N are returned to the free_list.  Then it takes N+N+N 
frames in cycles before gc is triggered again, etc.  Over 
time, the number of frames in the free_list grows without 
bound.

I'm thinking about putting a bound on it.  That is, if 
frame_dealloc sees there are already K frames on free_list, 
free the memory instead of keeping it devoted to frames 
forever.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 02:02:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 18:02:38 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16wBw6-0002e4-00@usw-sf-web1.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 04:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Simon Brunning (brunns)
>Assigned to: Walter D�rwald (doerwalter)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-12 21:02

Message:
Logged In: YES 
user_id=6380

Oops, I saw your remark too late.

I've checked in my own version of this for regular
strings...

Feel free to check in your version of this for Unicode
strings, and the docs etc.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 11:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 10:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 05:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 04:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 03:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 17:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 03:26:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 19:26:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python
Message-ID: <E16wDEu-0006Va-00@usw-sf-web2.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 12:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling Python

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




----------------------------------------------------------------------

>Comment By: Pierre (pierre42)
Date: 2002-04-13 02:26

Message:
Logged In: YES 
user_id=512388

Ok i have done :

root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3
-march=i686 -Wall -Wstrict-prototypes -dD --save-temps
--trace-includes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c >& compile.log

I attach you the file compile.log and the file thread.i


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 21:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 03:29:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 19:29:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python
Message-ID: <E16wDIQ-0006Xb-00@usw-sf-web2.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 12:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling Python

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




----------------------------------------------------------------------

>Comment By: Pierre (pierre42)
Date: 2002-04-13 02:29

Message:
Logged In: YES 
user_id=512388

In fact i can't attach the file thread.i, it is too big :(

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 02:26

Message:
Logged In: YES 
user_id=512388

Ok i have done :

root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3
-march=i686 -Wall -Wstrict-prototypes -dD --save-temps
--trace-includes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c >& compile.log

I attach you the file compile.log and the file thread.i


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 21:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 03:43:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 19:43:55 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16wDW7-0003b2-00@usw-sf-web1.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 04:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Walter D�rwald (doerwalter)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-12 22:43

Message:
Logged In: YES 
user_id=3066

(I'd say this is a good reason not to use separate trackers
for features, bugs, & patches -- they're too closely related
to keep them separate, and links between them too tedious
when written only in tracker comments!)

I've updated the documentation for these methods in
Doc/lib/libstdtypes.tex revision 1.87.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-12 21:02

Message:
Logged In: YES 
user_id=6380

Oops, I saw your remark too late.

I've checked in my own version of this for regular
strings...

Feel free to check in your version of this for Unicode
strings, and the docs etc.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 11:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 10:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 05:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 04:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 03:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 17:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 03:48:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 19:48:48 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-535450 ] documentation in CHM format
Message-ID: <E16wDaq-0000zf-00@usw-sf-web4.sourceforge.net>

Feature Requests item #535450, was opened at 2002-03-26 17:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=535450&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: G�bor Lipt�k (gliptak)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: documentation in CHM format

Initial Comment:
Please add html-help-2.2.chm to the sf.net 
downloadables.

Thanks



----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-12 22:48

Message:
Logged In: YES 
user_id=3066

These are provided by contributors for most releases, but
should be integrated with the Windows installer from PythonLabs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=535450&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 05:52:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 21:52:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-543318 ] SocketServer initializing outbound UDP
Message-ID: <E16wFX0-00021N-00@usw-sf-web4.sourceforge.net>

Bugs item #543318, was opened at 2002-04-13 00:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543318&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank J. Tobin (ftobin)
Assigned to: Nobody/Anonymous (nobody)
Summary: SocketServer initializing outbound UDP

Initial Comment:
In SocketServer.DatagramRequestHandler.setup, it calls:
  self.wfile = StringIO.StringIO(self.packet)

It doesn't make sense to initialize wfile to anything;
one probably wantsto start off with a 'clean' packet.
Should this not rather be:
  self.wfile = StringIO.StringIO()

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543318&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 06:25:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 12 Apr 2002 22:25:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16wG2t-0002mt-00@usw-sf-web3.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

>Category: Documentation
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-13 01:25

Message:
Logged In: YES 
user_id=31435

The slower leak in current CVS got plugged via bounding the 
frameobject free_list, in

Objects/frameobject.c; new revision: 2.61

Also backported to the 2.2 branch.

Reassigned to Fred for 2.1, in case he can figure out what 
kind of doc change might help.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 20:03

Message:
Logged In: YES 
user_id=31435

Neil, are there other gcable containers that use free 
lists?  Offhand I could only think of tuples, but they 
already put a bound on the their free list size 
(MAXSAVEDTUPLES).  Of course I agree it is a general 
problem.

Another approach could expose part of the guts of 
_PyObject_GC_Malloc, and tell free-list addicts (FLAs) they 
have to call that on every "virtual" allocation; similarly 
for virtual deallocation.  The "excess" approach remains, I 
think, a clever and solid one, and from that view "the 
problem" is that the FLAs simply don't participate in it.  
OTOH, FLAs are using a free-list because they're keen to 
make allocation as fast as possible, so making newing 
external calls is unattractive on that ground.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 19:05

Message:
Logged In: YES 
user_id=31435

Reassigned to me.

Bernhard, can you suggest where the docs could say 
something in 2.1 that would do you any good?  And/or what 
they could say that would help?  Documenting cases where 
cycles can cause leaks hasn't appeared to do much good over 
the years -- if someone doesn't already know that assigning 
the current frame to a local vrbl in that frame causes a 
cycle, or why such a cycle leaks before 2.2, they're not 
easy things to get across.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-12 18:54

Message:
Logged In: YES 
user_id=35752

Sounds like a sensible solution.  I think this is a 
problem with all GC collected objects that use a free list.
I can't think of a nice general solution for it though (other
than removing the other free lists :).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:39

Message:
Logged In: YES 
user_id=31435

OK, it *is* the frameobject free_list that's screwing us 
here.  Disable that mechanism, and the fleak2.py output is 
steady over time, and the process doesn't grow over time.

gc is triggered by an excess of allocations over 
deallocations, by some delta N.  After the first N frames 
in cycles are allocated, gc cleans them up, but they all go 
into the free_list.  Then it takes N+N frames in cycles 
before gc is triggered again (the first N come out of the 
free_list so don't bump the allocation count at all), and 
all N+N are returned to the free_list.  Then it takes N+N+N 
frames in cycles before gc is triggered again, etc.  Over 
time, the number of frames in the free_list grows without 
bound.

I'm thinking about putting a bound on it.  That is, if 
frame_dealloc sees there are already K frames on free_list, 
free the memory instead of keeping it devoted to frames 
forever.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 09:12:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 01:12:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-543344 ] Interpreter crashes when recoding
Message-ID: <E16wIe8-0003vp-00@usw-sf-web4.sourceforge.net>

Bugs item #543344, was opened at 2002-04-13 10:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543344&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L�wis (loewis)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Interpreter crashes when recoding

Initial Comment:
Python crashes when executing

import codecs
f = open("syllables", "w+")
f2 = codecs.EncodedFile(f, "unicode_internal", "utf-8")
f2.write(u"a")
f2.close()


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543344&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 09:31:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 01:31:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python
Message-ID: <E16wIw1-0004XH-00@usw-sf-web3.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling Python

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-13 10:31

Message:
Logged In: YES 
user_id=21627

I think I can see the problem now. For some reason, Python
tries to use both GNU pth and pthreads for threading; this
cannot work.

How did you invoke configure?

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 04:29

Message:
Logged In: YES 
user_id=512388

In fact i can't attach the file thread.i, it is too big :(

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 04:26

Message:
Logged In: YES 
user_id=512388

Ok i have done :

root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3
-march=i686 -Wall -Wstrict-prototypes -dD --save-temps
--trace-includes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c >& compile.log

I attach you the file compile.log and the file thread.i


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 23:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 09:36:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 01:36:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-543344 ] Interpreter crashes when recoding
Message-ID: <E16wJ0s-00075C-00@usw-sf-web1.sourceforge.net>

Bugs item #543344, was opened at 2002-04-13 04:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543344&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Martin v. L�wis (loewis)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Interpreter crashes when recoding

Initial Comment:
Python crashes when executing

import codecs
f = open("syllables", "w+")
f2 = codecs.EncodedFile(f, "unicode_internal", "utf-8")
f2.write(u"a")
f2.close()


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-13 04:36

Message:
Logged In: YES 
user_id=31435

Here's a clue from a debug-mode build:

>>> import codecs
[9477 refs]
>>> f = open("syllables", "w+")
[9483 refs]
>>> f2 = codecs.EncodedFile(f, "unicode_internal", "utf-8")
[9830 refs]
>>> f2.write(u"a")
C:\Code\python\Objects\tupleobject.c:147 negative ref 
count -1


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543344&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 14:18:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 06:18:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python
Message-ID: <E16wNPk-0007b3-00@usw-sf-web3.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 12:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling Python

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




----------------------------------------------------------------------

>Comment By: Pierre (pierre42)
Date: 2002-04-13 13:18

Message:
Logged In: YES 
user_id=512388

I did ./configure  --with-threads --with-pth
I thought it means "enable thread support, and for this use
gnu pth". 

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-13 08:31

Message:
Logged In: YES 
user_id=21627

I think I can see the problem now. For some reason, Python
tries to use both GNU pth and pthreads for threading; this
cannot work.

How did you invoke configure?

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 02:29

Message:
Logged In: YES 
user_id=512388

In fact i can't attach the file thread.i, it is too big :(

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 02:26

Message:
Logged In: YES 
user_id=512388

Ok i have done :

root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3
-march=i686 -Wall -Wstrict-prototypes -dD --save-temps
--trace-includes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c >& compile.log

I attach you the file compile.log and the file thread.i


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 21:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 14:46:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 06:46:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E16wNrh-0007uk-00@usw-sf-web3.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 15:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 15:26:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 07:26:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E16wOU6-0008Lk-00@usw-sf-web3.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 20:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Bernhard Herzog (bernhard)
Date: 2002-04-13 16:26

Message:
Logged In: YES 
user_id=2369

For the documentation, perhaps a note in section 3.11.4,
"The interpreter stack", might be appropriate. Something
like this:

   In Python 2.1 and earlier, stackframes stored directly or
   indirectly in local variables can easily cause referency
   cycles the garbage collector can't collect, leading to
   memory leaks. To avoid this, it's a good idea to
   explicitly remove the cycle in a finally: clause. For
   example:

   def handle_stackframe_without_leak():
       frame = inspect.currentframe()
       try:
           # do something with the frame
       finally:
           del frame


The situation here is very similar to sys.exc_info and the
traceback in its return value.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 07:25

Message:
Logged In: YES 
user_id=31435

The slower leak in current CVS got plugged via bounding the 
frameobject free_list, in

Objects/frameobject.c; new revision: 2.61

Also backported to the 2.2 branch.

Reassigned to Fred for 2.1, in case he can figure out what 
kind of doc change might help.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 02:03

Message:
Logged In: YES 
user_id=31435

Neil, are there other gcable containers that use free 
lists?  Offhand I could only think of tuples, but they 
already put a bound on the their free list size 
(MAXSAVEDTUPLES).  Of course I agree it is a general 
problem.

Another approach could expose part of the guts of 
_PyObject_GC_Malloc, and tell free-list addicts (FLAs) they 
have to call that on every "virtual" allocation; similarly 
for virtual deallocation.  The "excess" approach remains, I 
think, a clever and solid one, and from that view "the 
problem" is that the FLAs simply don't participate in it.  
OTOH, FLAs are using a free-list because they're keen to 
make allocation as fast as possible, so making newing 
external calls is unattractive on that ground.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 01:05

Message:
Logged In: YES 
user_id=31435

Reassigned to me.

Bernhard, can you suggest where the docs could say 
something in 2.1 that would do you any good?  And/or what 
they could say that would help?  Documenting cases where 
cycles can cause leaks hasn't appeared to do much good over 
the years -- if someone doesn't already know that assigning 
the current frame to a local vrbl in that frame causes a 
cycle, or why such a cycle leaks before 2.2, they're not 
easy things to get across.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-13 00:54

Message:
Logged In: YES 
user_id=35752

Sounds like a sensible solution.  I think this is a 
problem with all GC collected objects that use a free list.
I can't think of a nice general solution for it though (other
than removing the other free lists :).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 00:39

Message:
Logged In: YES 
user_id=31435

OK, it *is* the frameobject free_list that's screwing us 
here.  Disable that mechanism, and the fleak2.py output is 
steady over time, and the process doesn't grow over time.

gc is triggered by an excess of allocations over 
deallocations, by some delta N.  After the first N frames 
in cycles are allocated, gc cleans them up, but they all go 
into the free_list.  Then it takes N+N frames in cycles 
before gc is triggered again (the first N come out of the 
free_list so don't bump the allocation count at all), and 
all N+N are returned to the free_list.  Then it takes N+N+N 
frames in cycles before gc is triggered again, etc.  Over 
time, the number of frames in the free_list grows without 
bound.

I'm thinking about putting a bound on it.  That is, if 
frame_dealloc sees there are already K frames on free_list, 
free the memory instead of keeping it devoted to frames 
forever.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 00:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 00:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 21:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 17:54:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 09:54:06 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-536796 ] fchdir
Message-ID: <E16wQms-00078i-00@usw-sf-web2.sourceforge.net>

Feature Requests item #536796, was opened at 2002-03-29 11:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=536796&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Jarc (prjsf)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fchdir

Initial Comment:
os.fchdir(fd) would be a welcome addition.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-13 12:54

Message:
Logged In: YES 
user_id=3066

Patch in development, but got interrupted.  Will finish
later & close this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=536796&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 19:47:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 11:47:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-543464 ] ResolveAliasFile problem
Message-ID: <E16wSYy-0002Cd-00@usw-sf-web4.sourceforge.net>

Bugs item #543464, was opened at 2002-04-13 13:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543464&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Jack Jansen (jackjansen)
Summary: ResolveAliasFile problem

Initial Comment:
ResolveAliasFile (and other macfs functions) are 
not as robust as macpath functions when it comes 
to testing a path containing an alias.

For example, path s shown below is the path to the 
file 'macintosh hd:desktop folder:k:' generated 
during a walk of folder f.  h is an alias in f that 
points to a desktop folder named h; ka is an alias 
within h that points to the folder k on the desktop.

While exists() can tell that it exists, an alias 
resolution fails as the following interactive 
sessions shows:

>>> s
'macintosh hd:desktop folder:f:h:ka:'
>>> macpath.exists(s)
1
>>> macpath.isdir(s)
1
>>> macpath.isfile(s)
0
>>> macfs.ResolveAliasFile(s)
Traceback (most recent call last):
  File "<input>", line 1, in ?
MacOS.Error: (-120, 'Directory not found')

The folder does exist, though, and can be resolved 
if the reference to f is bypassed in the path:

>>> macfs.ResolveAliasFile('macintosh 
hd:desktop folder:k')
(FSSpec((-1, 16, 'K')), 1, 0)

The resolution of anything in folder h fails.  Here I 
try to resolve the fss to the file h1 that exists in h:

>>> macfs.ResolveAliasFile('macintosh 
hd:desktop folder:f:h:h1')
Traceback (most recent call last):
  File "<input>", line 1, in ?
MacOS.Error: (-120, 'Directory not found')

When I bypass folder f in the path, the fss is 
returned:
>>> macfs.ResolveAliasFile('macintosh 
hd:desktop folder:h:h1')
(FSSpec((-1, 184613, 'h1')), 0, 0)

The same trouble plagues macfs.copy:

>>> p='macintosh hd:desktop folder:'
>>> macostools.copy(p+'k:jnk',p+'test') #this works
>>> macostools.copy(p+"h:ka:jnk",p+'test') #fails
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Macintosh HD:Applications (Mac OS 
9):Python 2.2:Mac:Lib:macostools.py", line 85, in 
copy
    srcfss = macfs.FSSpec(src)
MacOS.Error: (-120, 'Directory not found')

A workaround that I have used is to create a 
resolve() function that rebuilds the path one 
element at a time, resolving elements along the 
way so a valid path is finally obtained:

def resolve(s, justPath=0):
	"""Get an absolute path from this possibly 
convoluted path that would give ResolveAliasFile 
problems.
	If justPath=1 then only the path up to the last entity 
in the path will be resolved, otherwise the
	whole path will be resolved and you will have the 
actual path to the item if it exists on disk.  If the
	file does not exist, an error is raised."""
	#
	# If you resolve all but the last item in the s then 
you will be able to call
	# resolveAliasFile and find out if the thing is an 
alias or not, otherwise you 
	# will have resolved the entire path to a real item if 
it exists.
	#
	p=abspath(s).split(":")
	
	# Define the indice to use so slices below will (or 
will not) include
	# the last element in the path.
	if justPath:
		last=-1
	else:
		last=len(p)
		
	rv=p[0]+":"
	for pi in p[1:last]:
		try:
			d=join(rv,pi)
			rv=macfs.ResolveAliasFile(d)[0].as_pathname()
		except:
			raise "File not found."
			
	return  join(rv,p[last:])




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543464&group_id=5470



From noreply@sourceforge.net  Sat Apr 13 22:44:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 14:44:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-543464 ] ResolveAliasFile problem
Message-ID: <E16wVJc-0001So-00@usw-sf-web2.sourceforge.net>

Bugs item #543464, was opened at 2002-04-13 20:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543464&group_id=5470

Category: Macintosh
>Group: Not a Bug
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Jack Jansen (jackjansen)
Summary: ResolveAliasFile problem

Initial Comment:
ResolveAliasFile (and other macfs functions) are 
not as robust as macpath functions when it comes 
to testing a path containing an alias.

For example, path s shown below is the path to the 
file 'macintosh hd:desktop folder:k:' generated 
during a walk of folder f.  h is an alias in f that 
points to a desktop folder named h; ka is an alias 
within h that points to the folder k on the desktop.

While exists() can tell that it exists, an alias 
resolution fails as the following interactive 
sessions shows:

>>> s
'macintosh hd:desktop folder:f:h:ka:'
>>> macpath.exists(s)
1
>>> macpath.isdir(s)
1
>>> macpath.isfile(s)
0
>>> macfs.ResolveAliasFile(s)
Traceback (most recent call last):
  File "<input>", line 1, in ?
MacOS.Error: (-120, 'Directory not found')

The folder does exist, though, and can be resolved 
if the reference to f is bypassed in the path:

>>> macfs.ResolveAliasFile('macintosh 
hd:desktop folder:k')
(FSSpec((-1, 16, 'K')), 1, 0)

The resolution of anything in folder h fails.  Here I 
try to resolve the fss to the file h1 that exists in h:

>>> macfs.ResolveAliasFile('macintosh 
hd:desktop folder:f:h:h1')
Traceback (most recent call last):
  File "<input>", line 1, in ?
MacOS.Error: (-120, 'Directory not found')

When I bypass folder f in the path, the fss is 
returned:
>>> macfs.ResolveAliasFile('macintosh 
hd:desktop folder:h:h1')
(FSSpec((-1, 184613, 'h1')), 0, 0)

The same trouble plagues macfs.copy:

>>> p='macintosh hd:desktop folder:'
>>> macostools.copy(p+'k:jnk',p+'test') #this works
>>> macostools.copy(p+"h:ka:jnk",p+'test') #fails
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Macintosh HD:Applications (Mac OS 
9):Python 2.2:Mac:Lib:macostools.py", line 85, in 
copy
    srcfss = macfs.FSSpec(src)
MacOS.Error: (-120, 'Directory not found')

A workaround that I have used is to create a 
resolve() function that rebuilds the path one 
element at a time, resolving elements along the 
way so a valid path is finally obtained:

def resolve(s, justPath=0):
	"""Get an absolute path from this possibly 
convoluted path that would give ResolveAliasFile 
problems.
	If justPath=1 then only the path up to the last entity 
in the path will be resolved, otherwise the
	whole path will be resolved and you will have the 
actual path to the item if it exists on disk.  If the
	file does not exist, an error is raised."""
	#
	# If you resolve all but the last item in the s then 
you will be able to call
	# resolveAliasFile and find out if the thing is an 
alias or not, otherwise you 
	# will have resolved the entire path to a real item if 
it exists.
	#
	p=abspath(s).split(":")
	
	# Define the indice to use so slices below will (or 
will not) include
	# the last element in the path.
	if justPath:
		last=-1
	else:
		last=len(p)
		
	rv=p[0]+":"
	for pi in p[1:last]:
		try:
			d=join(rv,pi)
			rv=macfs.ResolveAliasFile(d)[0].as_pathname()
		except:
			raise "File not found."
			
	return  join(rv,p[last:])




----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-13 23:44

Message:
Logged In: YES 
user_id=45365

This isn't a bug: it's just the way the ResolveAliasFile() toolbox call works, the path leading up to the alias needs to be a real pathname, not containing aliases. You'll see this behaviour in lots of MacOS toolbox calls (aliases within paths don't work).

However, I would like to include your routine in the macostools module, it's definitely very handy!

Could you please submit a patch, and then attach the routine in stead of incorporating it textually (SF seriously mangles code that is textually inserted). Thanks!

(Oh yes: don't forget to click the obnoxious checkbox if you attach a file, otherwise nothing happens!).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543464&group_id=5470



From noreply@sourceforge.net  Sun Apr 14 00:04:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 16:04:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-542482 ] Problem compiling Python
Message-ID: <E16wWZR-00053m-00@usw-sf-web3.sourceforge.net>

Bugs item #542482, was opened at 2002-04-11 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Pierre (pierre42)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem compiling Python

Initial Comment:
Hi,

I try to compile Python-2.2.1 on my linux slackware 8
with gcc-3.0.4
there was no problem with the configure, but for the
make i got this :

# gmake
gcc -c -DNDEBUG -g -O3 -march=i686 -Wall
-Wstrict-prototypes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c
In file included from Python/thread.c:109:
Python/thread_pth.h: In function
`PyThread_start_new_thread':
Python/thread_pth.h:59: warning: return makes integer
from pointer without a cast
In file included from Python/thread.c:113:
Python/thread_pthread.h:113:1: warning: "CHECK_STATUS"
redefined
Python/thread_pth.h:31:1: warning: this is the location
of the previous definition
In file included from Python/thread.c:113:
Python/thread_pthread.h: At top level:
Python/thread_pthread.h:139: redefinition of
`PyThread__init_thread'
Python/thread_pth.h:38: `PyThread__init_thread'
previously defined here
Python/thread_pthread.h:154: redefinition of
`PyThread_start_new_thread'
Python/thread_pth.h:48: `PyThread_start_new_thread'
previously defined here
Python/thread_pthread.h:235: redefinition of
`PyThread_get_thread_ident'
Python/thread_pth.h:63: `PyThread_get_thread_ident'
previously defined here
Python/thread_pthread.h:250: redefinition of
`do_PyThread_exit_thread'
Python/thread_pth.h:73: `do_PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:262: redefinition of
`PyThread_exit_thread'
Python/thread_pth.h:84: `PyThread_exit_thread'
previously defined here
Python/thread_pthread.h:268: redefinition of
`PyThread__exit_thread'
Python/thread_pth.h:89: `PyThread__exit_thread'
previously defined here
Python/thread_pthread.h:302: redefinition of
`PyThread_allocate_lock'
Python/thread_pth.h:119: `PyThread_allocate_lock'
previously defined here
Python/thread_pthread.h:335: redefinition of
`PyThread_free_lock'
Python/thread_pth.h:145: `PyThread_free_lock'
previously defined here
Python/thread_pthread.h:352: redefinition of
`PyThread_acquire_lock'
Python/thread_pth.h:154: `PyThread_acquire_lock'
previously defined here
Python/thread_pthread.h:390: redefinition of
`PyThread_release_lock'
Python/thread_pth.h:191: `PyThread_release_lock'
previously defined here
Python/thread_pthread.h:413: redefinition of `struct
semaphore'
Python/thread_pthread.h:421: redefinition of
`PyThread_allocate_sema'
Python/thread_pth.h:221: `PyThread_allocate_sema'
previously defined here
Python/thread_pthread.h:449: redefinition of
`PyThread_free_sema'
Python/thread_pth.h:246: `PyThread_free_sema'
previously defined here
Python/thread_pthread.h:463: redefinition of
`PyThread_down_sema'
Python/thread_pth.h:254: `PyThread_down_sema'
previously defined here
Python/thread_pthread.h:493: redefinition of
`PyThread_up_sema'
Python/thread_pth.h:283: `PyThread_up_sema' previously
defined here
gmake: *** [Python/thread.o] Error 1


It would be great if you could help me with this !

Best regards,

Pierre.




----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-14 01:04

Message:
Logged In: YES 
user_id=21627

You are right; this is the intention. It turns out that a 
configuration of an alternate thread library is not 
supported if pthreads are also available on the system. 
 
I'll try to come up with a work-around, but this is not 
high-priority, and may take a while. 

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 15:18

Message:
Logged In: YES 
user_id=512388

I did ./configure  --with-threads --with-pth
I thought it means "enable thread support, and for this use
gnu pth". 

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-13 10:31

Message:
Logged In: YES 
user_id=21627

I think I can see the problem now. For some reason, Python
tries to use both GNU pth and pthreads for threading; this
cannot work.

How did you invoke configure?

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 04:29

Message:
Logged In: YES 
user_id=512388

In fact i can't attach the file thread.i, it is too big :(

----------------------------------------------------------------------

Comment By: Pierre (pierre42)
Date: 2002-04-13 04:26

Message:
Logged In: YES 
user_id=512388

Ok i have done :

root@pierre:/tmp/Python-2.2.1# gcc -c -DNDEBUG -g -O3
-march=i686 -Wall -Wstrict-prototypes -dD --save-temps
--trace-includes -I. -I./Include -DHAVE_CONFIG_H  -o
Python/thread.o Python/thread.c >& compile.log

I attach you the file compile.log and the file thread.i


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 23:59

Message:
Logged In: YES 
user_id=21627

Can you please add the options "-dD --save-temps
--trace-includes" to the gcc invocation, and attach both the
compiler (error) output and thread.i to this report?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542482&group_id=5470



From noreply@sourceforge.net  Sun Apr 14 00:13:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 13 Apr 2002 16:13:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-543244 ] installation atop 2.2 fails
Message-ID: <E16wWhq-00059h-00@usw-sf-web3.sourceforge.net>

Bugs item #543244, was opened at 2002-04-13 00:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470

Category: Installation
>Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation atop 2.2 fails

Initial Comment:
Installing Python 2.2.1 atop Python 2.2 on cygwin 
fails at the last stage when it tries to create a 
link from /usr/bin/python.exe -> /usr/bin/python-
2.2.exe. Since the link already exists, installation 
stops.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-14 01:13

Message:
Logged In: YES 
user_id=21627

Can you report the precise sequence of commands being 
executed? Normally, it should be 
 
if test -f /usr/local/bin/python; \ 
then rm -f /usr/local/bin/python; \ 
else true; \ 
fi 
(cd /usr/local/bin; ln python2.2 python) 
 
If this is the ln that fails, it is not clear why the 
target already exists: the rm command is supposed to 
delete it. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 01:09

Message:
Logged In: YES 
user_id=31435

Change Group to Platform-specific.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470



From noreply@sourceforge.net  Sun Apr 14 12:33:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 04:33:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-543674 ] pdb: contradictory msg for "exit"/Ctrl-D
Message-ID: <E16wiG6-0005OR-00@usw-sf-web4.sourceforge.net>

Bugs item #543674, was opened at 2002-04-14 13:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543674&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gregor Hoffleit (flight)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb: contradictory msg for "exit"/Ctrl-D

Initial Comment:
pdb gives contradictory messages when I try to leave it:

"exit" gives me the message 'Use Ctrl-D (i.e. EOF) to
exit.'; when I then press "Ctrl-D", nothing happens.
Only "quit" will exit the debugger:

  freefly:1> python2.2 /usr/lib/python2.2/pdb.py
/tmp/xxx.py 
  > <string>(0)?()
  (Pdb) exit
  'Use Ctrl-D (i.e. EOF) to exit.'
  (Pdb) [Ctrl-D](Pdb) quit
  freefly:2> 

The cause for this trouble is that exit() is defined in
site.py to issue that warning, but then, "Ctrl-D" is
not accordingly handled in pdb.py. So either pdb.py
should be fixed to handle "Ctrl-D" like "quit", or
"exit" should be changed in pdb.py to either quit the
program or just do nothing.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543674&group_id=5470



From noreply@sourceforge.net  Sun Apr 14 21:53:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 13:53:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-543840 ] complex(string) accepts strings with \0
Message-ID: <E16wr0R-000325-00@usw-sf-web3.sourceforge.net>

Bugs item #543840, was opened at 2002-04-14 22:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: complex(string) accepts strings with \0

Initial Comment:
the complex constructor doesn't fail when passing
strings with an embbebed \0

Python 2.3a0 (#10, Apr 14 2002, 16:21:30) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> complex('1+0j\0j')
(1+0j)
>>> 

Other malformed arguments do fail:

>>> complex('1+0j j')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    complex('1+0j j')
ValueError: complex() arg is a malformed string

--
Source code from todays CVS.

Regards,
-Hernan


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470



From noreply@sourceforge.net  Sun Apr 14 22:50:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 14:50:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-543840 ] complex(string) accepts strings with \0
Message-ID: <E16wrtR-0006Rn-00@usw-sf-web1.sourceforge.net>

Bugs item #543840, was opened at 2002-04-14 22:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: complex(string) accepts strings with \0

Initial Comment:
the complex constructor doesn't fail when passing
strings with an embbebed \0

Python 2.3a0 (#10, Apr 14 2002, 16:21:30) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> complex('1+0j\0j')
(1+0j)
>>> 

Other malformed arguments do fail:

>>> complex('1+0j j')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    complex('1+0j j')
ValueError: complex() arg is a malformed string

--
Source code from todays CVS.

Regards,
-Hernan


----------------------------------------------------------------------

>Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 23:50

Message:
Logged In: YES 
user_id=112690

It seems to be a problem in complex_subtype_from_string(..)
when there is a '\0' in the string argument.
I'm uploading a patch that seems to fix this.
In another patch goes the tests for this fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470



From noreply@sourceforge.net  Sun Apr 14 22:55:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 14:55:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-543840 ] complex(string) accepts strings with \0
Message-ID: <E16wryH-0003ik-00@usw-sf-web3.sourceforge.net>

Bugs item #543840, was opened at 2002-04-14 16:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Tim Peters (tim_one)
Summary: complex(string) accepts strings with \0

Initial Comment:
the complex constructor doesn't fail when passing
strings with an embbebed \0

Python 2.3a0 (#10, Apr 14 2002, 16:21:30) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> complex('1+0j\0j')
(1+0j)
>>> 

Other malformed arguments do fail:

>>> complex('1+0j j')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    complex('1+0j j')
ValueError: complex() arg is a malformed string

--
Source code from todays CVS.

Regards,
-Hernan


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-14 17:55

Message:
Logged In: YES 
user_id=31435

Assigned to me; I've already got a fix, so you needn't 
bother with that.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 17:50

Message:
Logged In: YES 
user_id=112690

It seems to be a problem in complex_subtype_from_string(..)
when there is a '\0' in the string argument.
I'm uploading a patch that seems to fix this.
In another patch goes the tests for this fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470



From noreply@sourceforge.net  Sun Apr 14 23:05:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 15:05:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-543840 ] complex(string) accepts strings with \0
Message-ID: <E16ws7i-0003pW-00@usw-sf-web3.sourceforge.net>

Bugs item #543840, was opened at 2002-04-14 16:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470

Category: Python Interpreter Core
>Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Tim Peters (tim_one)
Summary: complex(string) accepts strings with \0

Initial Comment:
the complex constructor doesn't fail when passing
strings with an embbebed \0

Python 2.3a0 (#10, Apr 14 2002, 16:21:30) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> complex('1+0j\0j')
(1+0j)
>>> 

Other malformed arguments do fail:

>>> complex('1+0j j')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in ?
    complex('1+0j j')
ValueError: complex() arg is a malformed string

--
Source code from todays CVS.

Regards,
-Hernan


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-14 18:05

Message:
Logged In: YES 
user_id=31435

Fixed, in

Lib/test/test_b1.py; new revision: 1.45
Objects/complexobject.c; new revision: 2.57

I didn't backport it to any earlier releases (pressed for 
time).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 17:55

Message:
Logged In: YES 
user_id=31435

Assigned to me; I've already got a fix, so you needn't 
bother with that.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 17:50

Message:
Logged In: YES 
user_id=112690

It seems to be a problem in complex_subtype_from_string(..)
when there is a '\0' in the string argument.
I'm uploading a patch that seems to fix this.
In another patch goes the tests for this fix.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543840&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 00:24:30 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 16:24:30 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E16wtME-00021J-00@usw-sf-web2.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 15:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-15 01:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:09:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:09:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16wu3N-0007qt-00@usw-sf-web1.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 08:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
>Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:09

Message:
Logged In: YES 
user_id=6380

> PyType_GenericNew should also invoke all allocator 
> functions of the argument type's superclasses (in 
> reverse mro, I think).

No, this doesn't make sense; you can't invoke
more than one allocator. (Each allocator would
create a whole new object.)

The cause of your problem is in type_new(): it
always overrides tp_alloc with PyType_GenericAlloc.
You'd have to write a new metaclass (inheriting
from type) in C to change the tp_alloc (and tp_free)
settings.

But why do you want this? Why do you want
A instances to use the same allocator as _A?
This is not how subclassing built-in types works
elsewhere; e.g. int uses a special allocator,
but subclasses of int don't inherit that.

Before I do anything about this I'd like to
understand what you are trying to accomplish.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:20:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:20:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-541730 ] IDLE can clobber files
Message-ID: <E16wuEI-0002aw-00@usw-sf-web2.sourceforge.net>

Bugs item #541730, was opened at 2002-04-09 16:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541730&group_id=5470

Category: IDLE
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Ben Darnell (bgdarnel)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: IDLE can clobber files

Initial Comment:
I just lost some work today when IDLE failed to save my
file.  The file was truncated to 0 bytes, so it wasn't
recoverable by the recycle bin or anything like that. 
I was running Python 2.2 on Win2kPro.  There was no
error message, although IDLE seemed to realize that the
save failed - the asterisk remained in the title bar. 
I tried saving to a different name, but that didn't
work either (although a zero-byte file was created with
the new name).  I know this isn't enough for you to go
on to fix the bug; if I encounter the error again I
will inspect the situation more closely.  

In order to prevent data loss like this in the future,
I'd like to see IDLE make a backup of files before it
saves over them.  I submit the following (untested) patch:

--- IOBinding.py.orig   Tue Apr  9 15:56:00 2002
+++ IOBinding.py        Tue Apr  9 15:59:07 2002
@@ -148,6 +148,11 @@
 
     def writefile(self, filename):
         self.fixlastline()
+       try:
+           if os.path.exists(filename):
+               os.rename(filename, filename+'~')
+       except IOError:
+           pass
         try:
             f = open(filename, "w")
             chars = self.text.get("1.0", "end-1c")


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:20

Message:
Logged In: YES 
user_id=6380

I've fixed this using your later suggestion. We really
should do something better, but that requires more thought
and decisions, so I'm putting that off until the next
serious IDLE overhaul.

----------------------------------------------------------------------

Comment By: Ben Darnell (bgdarnel)
Date: 2002-04-10 11:33

Message:
Logged In: YES 
user_id=280

On further consideration, it's not the lack of backups that 
causes the problem, it's the fact that an exception in 
self.text.get can wipe out the file.  Moving the 
self.text.get call to before the file is opened would make 
it safe.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541730&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:25:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:25:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-541980 ] urllib.urlopen throws OSError
Message-ID: <E16wuJ6-00080i-00@usw-sf-web1.sourceforge.net>

Bugs item #541980, was opened at 2002-04-10 09:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541980&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jacques A. Vidrine (nectar)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: urllib.urlopen throws OSError

Initial Comment:
urllib.urlopen throws OSError when processing
file:// (local file) URLs and an error is encountered.
It should instead throw IOError in these cases to be
consistent with the built-in open function and with
the urllib documentation.  A patch is attached.

See bug report 482171 for an example of the
consequences of this bug (which was hacked around for
Python 2.2 it appears).  The bug also impacts 4Suite's
XSLT processor (using include paths causes an
unhandled exception).




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:25

Message:
Logged In: YES 
user_id=6380

Thanks; your fix is applied as urllib.py 1.143.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541980&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:31:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:31:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16wuP2-00084K-00@usw-sf-web1.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 09:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:31

Message:
Logged In: YES 
user_id=6380

James, can you please explain the problem again, but without
referring to other existing patches?  With all the
references to pydoc, inspect, properties, descriptors, other
patches and SF bug reports I have completely lost the trail,
and I don't think it's productive for me to try and gather
all the separate bits together.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 11:29

Message:
Logged In: YES 
user_id=21627

This is not (primarily) a pydoc issue: with your change,
property.__doc__ gets changed. pydoc could ignore the object
returned, but then property would have no documentation at
all - even though there is a tp_doc in it. So I don't see
any easy solution. If you do, please attach a patch for the
current CVS (we can then decide whether to backport it to
2.2.2).

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 11:06

Message:
Logged In: YES 
user_id=146903

Maybe getting pydoc to ignore any __doc__ attributes (that
is, what gets returned by getattr) that weren't strings or
unicode would work.

As for using a different metatype, a reason for getting this
into the the standard metatype is that it is also an
inconsistency between how new and old style classes act, and
is fairly easy to reconcile (granted descriptors didn't
exist in python < 2.2, but everytime new style classes act a
bit differently, people seem to start submitting pygtk bug
reports).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 10:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 10:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 09:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 09:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 09:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:31:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:31:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-543244 ] installation atop 2.2 fails
Message-ID: <E16wuPF-0005MQ-00@usw-sf-web3.sourceforge.net>

Bugs item #543244, was opened at 2002-04-12 17:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470

Category: Installation
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation atop 2.2 fails

Initial Comment:
Installing Python 2.2.1 atop Python 2.2 on cygwin 
fails at the last stage when it tries to create a 
link from /usr/bin/python.exe -> /usr/bin/python-
2.2.exe. Since the link already exists, installation 
stops.

----------------------------------------------------------------------

>Comment By: David Abrahams (david_abrahams)
Date: 2002-04-14 19:31

Message:
Logged In: YES 
user_id=52572

No, it's not that ln. Read my report again. It's 
linking /usr/bin/python -> /usr/bin/python2.2.exe. 
No "local" in the path. Since I've already installed 
2.2.1, I can't reproduce the behavior anymore without 
building myself a fresh 2.2... but it happened twice, once 
on a pydebug installation of 2.2.1 over 2.2 and once on a 
regular build.


-Dave


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-13 18:13

Message:
Logged In: YES 
user_id=21627

Can you report the precise sequence of commands being 
executed? Normally, it should be 
 
if test -f /usr/local/bin/python; \ 
then rm -f /usr/local/bin/python; \ 
else true; \ 
fi 
(cd /usr/local/bin; ln python2.2 python) 
 
If this is the ln that fails, it is not clear why the 
target already exists: the rm command is supposed to 
delete it. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:09

Message:
Logged In: YES 
user_id=31435

Change Group to Platform-specific.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:37:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:37:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-543318 ] SocketServer initializing outbound UDP
Message-ID: <E16wuUx-0002lU-00@usw-sf-web2.sourceforge.net>

Bugs item #543318, was opened at 2002-04-13 00:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543318&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Frank J. Tobin (ftobin)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: SocketServer initializing outbound UDP

Initial Comment:
In SocketServer.DatagramRequestHandler.setup, it calls:
  self.wfile = StringIO.StringIO(self.packet)

It doesn't make sense to initialize wfile to anything;
one probably wantsto start off with a 'clean' packet.
Should this not rather be:
  self.wfile = StringIO.StringIO()

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:37

Message:
Logged In: YES 
user_id=6380

You are so right. Fixed in CVS, marked as bugfix candidate.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543318&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:44:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:44:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E16wubQ-0005Fe-00@usw-sf-web4.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Tim Peters (tim_one)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 19:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:49:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:49:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-543674 ] pdb: contradictory msg for "exit"/Ctrl-D
Message-ID: <E16wugW-0008F9-00@usw-sf-web1.sourceforge.net>

Bugs item #543674, was opened at 2002-04-14 07:33
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543674&group_id=5470

>Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Gregor Hoffleit (flight)
>Assigned to: Guido van Rossum (gvanrossum)
>Summary: pdb: contradictory msg for "exit"/Ctrl-D

Initial Comment:
pdb gives contradictory messages when I try to leave it:

"exit" gives me the message 'Use Ctrl-D (i.e. EOF) to
exit.'; when I then press "Ctrl-D", nothing happens.
Only "quit" will exit the debugger:

  freefly:1> python2.2 /usr/lib/python2.2/pdb.py
/tmp/xxx.py 
  > <string>(0)?()
  (Pdb) exit
  'Use Ctrl-D (i.e. EOF) to exit.'
  (Pdb) [Ctrl-D](Pdb) quit
  freefly:2> 

The cause for this trouble is that exit() is defined in
site.py to issue that warning, but then, "Ctrl-D" is
not accordingly handled in pdb.py. So either pdb.py
should be fixed to handle "Ctrl-D" like "quit", or
"exit" should be changed in pdb.py to either quit the
program or just do nothing.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:49

Message:
Logged In: YES 
user_id=6380

The easiest solution was to add exit as an alias of quit,
and that's what I've done in CVS. There's still the problem
with ^D being ignored; I'd be happy to get a patch for that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543674&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 01:55:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 17:55:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-541883 ] delattr() causes python to segfault
Message-ID: <E16wume-0008Iy-00@usw-sf-web1.sourceforge.net>

Bugs item #541883, was opened at 2002-04-10 02:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 7
Submitted By: Vincent FIACK (vfiack)
Assigned to: Guido van Rossum (gvanrossum)
Summary: delattr() causes python to segfault

Initial Comment:
delattr() causes python to segfault with builtins types

First a normal case to see what it should do :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> delattr(a, "__class__")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'int' object has only read-only attributes 
(del .__class__)



Then the faulty case :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> a.__class__
<type 'int'>
>>> delattr(a, "__class__")
Segmentation fault.

I don't know why, but if i access to a.__class__ 
before deleting it, it cause this error. The same 
occurs if i use another base type such as a string or 
a list. I haven't tried other attributes than 
__class__, but it may worth trying.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-14 20:55

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem,
not sure if this is appropriate or not.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-10 06:06

Message:
Logged In: YES 
user_id=6656

Confirmed in 2.2.1.

Arse.



----------------------------------------------------------------------

Comment By: Vincent FIACK (vfiack)
Date: 2002-04-10 03:25

Message:
Logged In: YES 
user_id=34036

I tried on "Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 
bit (Intel)] on win32" and a similar error occurs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 02:04:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 18:04:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-541883 ] delattr() causes python to segfault
Message-ID: <E16wuux-0005g6-00@usw-sf-web3.sourceforge.net>

Bugs item #541883, was opened at 2002-04-10 02:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Vincent FIACK (vfiack)
Assigned to: Guido van Rossum (gvanrossum)
Summary: delattr() causes python to segfault

Initial Comment:
delattr() causes python to segfault with builtins types

First a normal case to see what it should do :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> delattr(a, "__class__")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: 'int' object has only read-only attributes 
(del .__class__)



Then the faulty case :

Python 2.2.1c2 (#1, Apr  3 2002, 14:02:46) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "help", "copyright", "credits" or "license" for 
more information.
>>> a = 5
>>> a.__class__
<type 'int'>
>>> delattr(a, "__class__")
Segmentation fault.

I don't know why, but if i access to a.__class__ 
before deleting it, it cause this error. The same 
occurs if i use another base type such as a string or 
a list. I haven't tried other attributes than 
__class__, but it may worth trying.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:04

Message:
Logged In: YES 
user_id=6380

Thanks! I fixed it pretty much the way Neal suggested; the
test I checked in is slightly different. Definitely a bugfix
candidate.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-14 20:55

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem,
not sure if this is appropriate or not.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-10 06:06

Message:
Logged In: YES 
user_id=6656

Confirmed in 2.2.1.

Arse.



----------------------------------------------------------------------

Comment By: Vincent FIACK (vfiack)
Date: 2002-04-10 03:25

Message:
Logged In: YES 
user_id=34036

I tried on "Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 
bit (Intel)] on win32" and a similar error occurs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541883&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 02:23:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 18:23:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E16wvDV-0005sA-00@usw-sf-web3.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-14 21:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 19:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 02:36:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 18:36:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E16wvQA-000602-00@usw-sf-web3.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Guido van Rossum (gvanrossum)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 21:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 19:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 02:42:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 18:42:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E16wvVT-00063N-00@usw-sf-web3.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 21:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 19:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 05:12:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 14 Apr 2002 21:12:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16wxrC-0001tB-00@usw-sf-web1.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 21:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Guido van Rossum (gvanrossum)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: James Henstridge (jhenstridge)
Date: 2002-04-15 12:12

Message:
Logged In: YES 
user_id=146903

Okay.  Here is a summary of the story so far:

I am working on the bindings for the GTK 2.0 gui toolkit. 
Gtk widgets can have properties (basically a combination of
the name, type, some documentation and getters/setters;
similar to python), and signals (part of gtk's notification
framework).

I wanted to provide documentation on the signals and
properties of each widget, and putting them in the __doc__
attribute seemed natural.  As information on the properties
and signals can be read via gtk's introspection APIs, it
seemed natural to want to generate this documentation at
runtime.

Now gtk tries to delay initialisation as much as possible
(classes are only initialised on first use).  So generating
documentation for every class on module initialisation would
mean initialising every class in gtk, which is a fairly big
speed hit I don't want to incur -- especially since online
documentation is mainly used during development.

This is why I wanted to use a descriptor -- so that the
signal and property documentation only gets generated when
the user asks for it.

Unfortunately this didn't work in python 2.2, as the
type.__doc__ member descriptor (which returns tp_doc) would
take precedence over the __doc__ attribute in the class itself.

To me, this seemed like a needless difference between new
and old style classes.  My initial patch made __doc__ act
more like the old style classes by getting rid of the
type.__doc__ descriptor and getting PyType_Ready to set
__doc__ appropriately from tp_doc, if it hadn't already been
set.

This allowed me to use descriptors to generate
signal/property documentation, and also allowed other non
string __doc__ attributes (such as unicode strings).

This fix was applied to head and the 2.2 branch but
unfortunately, it also caused pydoc to raise an exception
when displaying the documentation for __builtin__.property,
as its __doc__ attribute was now being returned when you
asked for property.__doc__ (rather than the type.__doc__
descriptor taking precedence and returning tp_doc).

property.__doc__ is a descriptor which returns a string for
property instances, but returns itself in the class context
(ie. getting property.__doc__).  As this is not a string or
unicode string, pydoc gets an error.

The fix (again, checked into both head and 2.2 branches)
that was checked in added a __doc__ descriptor again.  This
descriptor returns tp_doc for non heap type classes, and
looks up __doc__ in the class dictionary for heap type classes.

This causes problems for both heap and non heap classes: for
non heap classes, __doc__ in the class dict is never
accessed.  For heap classes, the tp_descr_get method of
__doc__ is never called.

Here is my prefered way to fix the problem (which you may
disagree with):

1. remove the type.__doc__ descriptor again

2. make the property.__doc__ descriptor return something
meaningful in the class context

3. make pydoc handle non string-like __doc__ attributes
better (either ignoring them or converting them to strings).
 Currently I can get help() to error out with a simple class
like:
    class foo:
        __doc__ = 42

(I am not saying that people should use integers as __doc__;
just that pydoc should handle things like this more gracefully).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 08:31

Message:
Logged In: YES 
user_id=6380

James, can you please explain the problem again, but without
referring to other existing patches?  With all the
references to pydoc, inspect, properties, descriptors, other
patches and SF bug reports I have completely lost the trail,
and I don't think it's productive for me to try and gather
all the separate bits together.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 23:29

Message:
Logged In: YES 
user_id=21627

This is not (primarily) a pydoc issue: with your change,
property.__doc__ gets changed. pydoc could ignore the object
returned, but then property would have no documentation at
all - even though there is a tp_doc in it. So I don't see
any easy solution. If you do, please attach a patch for the
current CVS (we can then decide whether to backport it to
2.2.2).

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 23:06

Message:
Logged In: YES 
user_id=146903

Maybe getting pydoc to ignore any __doc__ attributes (that
is, what gets returned by getattr) that weren't strings or
unicode would work.

As for using a different metatype, a reason for getting this
into the the standard metatype is that it is also an
inconsistency between how new and old style classes act, and
is fairly easy to reconcile (granted descriptors didn't
exist in python < 2.2, but everytime new style classes act a
bit differently, people seem to start submitting pygtk bug
reports).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 22:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 22:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 21:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 21:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 09:06:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 01:06:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16x1VY-0007Lp-00@usw-sf-web2.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 12:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

>Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 08:06

Message:
Logged In: YES 
user_id=495820

The class A does not know how to allocate the 'base part' of instances of itself
(i.e. what makes an instance of class _A). Thus sometime during instantiation 
of class A objects, the allocater of the base class must be called!
This will not happen, however, if the tp_new-slot function merely calls the 
allocator of the argument type.

You pointed out, that e.g. subclasses of 'int' won't inherit int's special allocator.
Does this mean, int's allocator will not be invoked on instantiation of the subclass?
Then, I don't understand why this works; I can only imagine, that PyType_GenericAlloc
is designed to deal with Python built-in types (and probably compostitions of these).




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 00:09

Message:
Logged In: YES 
user_id=6380

> PyType_GenericNew should also invoke all allocator 
> functions of the argument type's superclasses (in 
> reverse mro, I think).

No, this doesn't make sense; you can't invoke
more than one allocator. (Each allocator would
create a whole new object.)

The cause of your problem is in type_new(): it
always overrides tp_alloc with PyType_GenericAlloc.
You'd have to write a new metaclass (inheriting
from type) in C to change the tp_alloc (and tp_free)
settings.

But why do you want this? Why do you want
A instances to use the same allocator as _A?
This is not how subclassing built-in types works
elsewhere; e.g. int uses a special allocator,
but subclasses of int don't inherit that.

Before I do anything about this I'd like to
understand what you are trying to accomplish.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 12:09:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 04:09:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16x4Mp-0006Ox-00@usw-sf-web1.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 15:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Guido van Rossum (gvanrossum)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-15 13:09

Message:
Logged In: YES 
user_id=21627

I would summarize this differently: For the attached
descr.py, Python currently prints in the third line

NewClass.__doc__   = <__main__.DocDescr object at 0x1094d0>

James requests that it prints

NewClass.__doc__   = 'object=None    type=NewClass'

instead.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-15 06:12

Message:
Logged In: YES 
user_id=146903

Okay.  Here is a summary of the story so far:

I am working on the bindings for the GTK 2.0 gui toolkit. 
Gtk widgets can have properties (basically a combination of
the name, type, some documentation and getters/setters;
similar to python), and signals (part of gtk's notification
framework).

I wanted to provide documentation on the signals and
properties of each widget, and putting them in the __doc__
attribute seemed natural.  As information on the properties
and signals can be read via gtk's introspection APIs, it
seemed natural to want to generate this documentation at
runtime.

Now gtk tries to delay initialisation as much as possible
(classes are only initialised on first use).  So generating
documentation for every class on module initialisation would
mean initialising every class in gtk, which is a fairly big
speed hit I don't want to incur -- especially since online
documentation is mainly used during development.

This is why I wanted to use a descriptor -- so that the
signal and property documentation only gets generated when
the user asks for it.

Unfortunately this didn't work in python 2.2, as the
type.__doc__ member descriptor (which returns tp_doc) would
take precedence over the __doc__ attribute in the class itself.

To me, this seemed like a needless difference between new
and old style classes.  My initial patch made __doc__ act
more like the old style classes by getting rid of the
type.__doc__ descriptor and getting PyType_Ready to set
__doc__ appropriately from tp_doc, if it hadn't already been
set.

This allowed me to use descriptors to generate
signal/property documentation, and also allowed other non
string __doc__ attributes (such as unicode strings).

This fix was applied to head and the 2.2 branch but
unfortunately, it also caused pydoc to raise an exception
when displaying the documentation for __builtin__.property,
as its __doc__ attribute was now being returned when you
asked for property.__doc__ (rather than the type.__doc__
descriptor taking precedence and returning tp_doc).

property.__doc__ is a descriptor which returns a string for
property instances, but returns itself in the class context
(ie. getting property.__doc__).  As this is not a string or
unicode string, pydoc gets an error.

The fix (again, checked into both head and 2.2 branches)
that was checked in added a __doc__ descriptor again.  This
descriptor returns tp_doc for non heap type classes, and
looks up __doc__ in the class dictionary for heap type classes.

This causes problems for both heap and non heap classes: for
non heap classes, __doc__ in the class dict is never
accessed.  For heap classes, the tp_descr_get method of
__doc__ is never called.

Here is my prefered way to fix the problem (which you may
disagree with):

1. remove the type.__doc__ descriptor again

2. make the property.__doc__ descriptor return something
meaningful in the class context

3. make pydoc handle non string-like __doc__ attributes
better (either ignoring them or converting them to strings).
 Currently I can get help() to error out with a simple class
like:
    class foo:
        __doc__ = 42

(I am not saying that people should use integers as __doc__;
just that pydoc should handle things like this more gracefully).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 02:31

Message:
Logged In: YES 
user_id=6380

James, can you please explain the problem again, but without
referring to other existing patches?  With all the
references to pydoc, inspect, properties, descriptors, other
patches and SF bug reports I have completely lost the trail,
and I don't think it's productive for me to try and gather
all the separate bits together.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 17:29

Message:
Logged In: YES 
user_id=21627

This is not (primarily) a pydoc issue: with your change,
property.__doc__ gets changed. pydoc could ignore the object
returned, but then property would have no documentation at
all - even though there is a tp_doc in it. So I don't see
any easy solution. If you do, please attach a patch for the
current CVS (we can then decide whether to backport it to
2.2.2).

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 17:06

Message:
Logged In: YES 
user_id=146903

Maybe getting pydoc to ignore any __doc__ attributes (that
is, what gets returned by getattr) that weren't strings or
unicode would work.

As for using a different metatype, a reason for getting this
into the the standard metatype is that it is also an
inconsistency between how new and old style classes act, and
is fairly easy to reconcile (granted descriptors didn't
exist in python < 2.2, but everytime new style classes act a
bit differently, people seem to start submitting pygtk bug
reports).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 16:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 16:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 15:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 15:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 13:37:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 05:37:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-543387 ] bug? floor divison on complex
Message-ID: <E16x5jO-0004eh-00@usw-sf-web3.sourceforge.net>

Bugs item #543387, was opened at 2002-04-13 09:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Hernan Martinez Foffani (hfoffani)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: bug? floor divison on complex

Initial Comment:
PEP 238 says:
"For complex numbers, // raises an exception, since
floor() of a complex number is not allowed."

But on 2.3 (and on CVS) complex floor division returns
divmod[0]

Is this a bug on complexobject.c or the PEP wasn't updated?

Regards,
-Hernan 




----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 08:37

Message:
Logged In: YES 
user_id=6380

Note: complex % is also being deprecated.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:42

Message:
Logged In: YES 
user_id=6380

Fred, can you fix the docs?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 21:36

Message:
Logged In: YES 
user_id=6380

OK, I'll add the deprecation warning.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-14 21:23

Message:
Logged In: YES 
user_id=31435

Heh.  divmod(c1, c2)[0] for complexes returns
  floor((c1/c2).real)
according to the Reference Manual (5.6 Binary arithmetic 
operations), and it looks like the code implements that 
just so.  The Library manual's "Builtin Functions" section 
only mentions ints, longs and floats, while the same 
manual's "2.2.4 Numeric Types" claims, in a footnote, 
that "Builtin Functions" told the full truth about divmod.

The primary lesson I take from this is that a .chm file is 
a truly wonderful way to search the docs <wink>.

I don't think divmod is useful for complexes, and would be 
happy to see it go away.  But I guess that means taking the 
full-blown deprecation path.

I note that the original complexobject.c didn't implement 
divmod.  The current divmod appears to derive from a patch 
contributed by Tim Hochberg, in rev 2.10 in 1996.  You 
(Guido) added a question mark to the checkin comment, so I 
figure it never made much sense to you either.

I agree floor divsion and divmod(...)[0] should do the same 
thing, whatever that is.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:44

Message:
Logged In: YES 
user_id=6380

Hm. I believe that if divmod() returns something, // should
return the same thing (well, divmod()[0]). But what on earth
does divmod() do on two complex numbers??? Does it make
sense to have divmod() on complex at all? Assigned to Tim
for a ruling.

----------------------------------------------------------------------

Comment By: Hernan Martinez Foffani (hfoffani)
Date: 2002-04-14 19:24

Message:
Logged In: YES 
user_id=112690

As suggested by Tim I'll upload here the patch and the test
for this bug.
The patch clears nb_true_divide entry and deletes the
complex_int_div function.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543387&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 14:01:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 06:01:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16x66m-0004fj-00@usw-sf-web4.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 08:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:01

Message:
Logged In: YES 
user_id=6380

Your understanding of instance allocation doesn't match
reality, *or* you're expressing yourself poorly. Allocation
does not include initialization; allocation simply requests
the memory for the object from malloc (or some other memory
allocator) and fills it with zeros, except for the reference
count, which is set to 1, and the ob_type field, which is
set to the type argument to the allocator. The amount of
memory allocated for the object is calculated by taking the
tp_basicsize of the type object, and adding nitems times the
tp_itemsize from the type object.

If you want to initialize your object, that should be done
in the tp_new slot, not in tp_alloc.

Have you tried to read the source code (or go through an
allocation in a C debugger) to find out how it really works?

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 04:06

Message:
Logged In: YES 
user_id=495820

The class A does not know how to allocate the 'base part' of instances of itself
(i.e. what makes an instance of class _A). Thus sometime during instantiation 
of class A objects, the allocater of the base class must be called!
This will not happen, however, if the tp_new-slot function merely calls the 
allocator of the argument type.

You pointed out, that e.g. subclasses of 'int' won't inherit int's special allocator.
Does this mean, int's allocator will not be invoked on instantiation of the subclass?
Then, I don't understand why this works; I can only imagine, that PyType_GenericAlloc
is designed to deal with Python built-in types (and probably compostitions of these).




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:09

Message:
Logged In: YES 
user_id=6380

> PyType_GenericNew should also invoke all allocator 
> functions of the argument type's superclasses (in 
> reverse mro, I think).

No, this doesn't make sense; you can't invoke
more than one allocator. (Each allocator would
create a whole new object.)

The cause of your problem is in type_new(): it
always overrides tp_alloc with PyType_GenericAlloc.
You'd have to write a new metaclass (inheriting
from type) in C to change the tp_alloc (and tp_free)
settings.

But why do you want this? Why do you want
A instances to use the same allocator as _A?
This is not how subclassing built-in types works
elsewhere; e.g. int uses a special allocator,
but subclasses of int don't inherit that.

Before I do anything about this I'd like to
understand what you are trying to accomplish.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 14:38:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 06:38:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16x6gw-00088G-00@usw-sf-web1.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 09:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Guido van Rossum (gvanrossum)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:38

Message:
Logged In: YES 
user_id=6380

I like Martin's summary better. :-)

Some remarks: 

- property.__doc__ works fine, it's
property.__dict__['__doc__'] that behaves strange (but
nobody should care)

- I can't get help() to break by setting __doc__ = 42 on
either an old or a new class

- I think I'd rather not lose the __doc__ descriptor in
type, but I can make it look for __dict__['__doc__'] first,
*and* call that if it appears a descriptor.

I'll post a patch here once I've had breakfast.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-15 07:09

Message:
Logged In: YES 
user_id=21627

I would summarize this differently: For the attached
descr.py, Python currently prints in the third line

NewClass.__doc__   = <__main__.DocDescr object at 0x1094d0>

James requests that it prints

NewClass.__doc__   = 'object=None    type=NewClass'

instead.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-15 00:12

Message:
Logged In: YES 
user_id=146903

Okay.  Here is a summary of the story so far:

I am working on the bindings for the GTK 2.0 gui toolkit. 
Gtk widgets can have properties (basically a combination of
the name, type, some documentation and getters/setters;
similar to python), and signals (part of gtk's notification
framework).

I wanted to provide documentation on the signals and
properties of each widget, and putting them in the __doc__
attribute seemed natural.  As information on the properties
and signals can be read via gtk's introspection APIs, it
seemed natural to want to generate this documentation at
runtime.

Now gtk tries to delay initialisation as much as possible
(classes are only initialised on first use).  So generating
documentation for every class on module initialisation would
mean initialising every class in gtk, which is a fairly big
speed hit I don't want to incur -- especially since online
documentation is mainly used during development.

This is why I wanted to use a descriptor -- so that the
signal and property documentation only gets generated when
the user asks for it.

Unfortunately this didn't work in python 2.2, as the
type.__doc__ member descriptor (which returns tp_doc) would
take precedence over the __doc__ attribute in the class itself.

To me, this seemed like a needless difference between new
and old style classes.  My initial patch made __doc__ act
more like the old style classes by getting rid of the
type.__doc__ descriptor and getting PyType_Ready to set
__doc__ appropriately from tp_doc, if it hadn't already been
set.

This allowed me to use descriptors to generate
signal/property documentation, and also allowed other non
string __doc__ attributes (such as unicode strings).

This fix was applied to head and the 2.2 branch but
unfortunately, it also caused pydoc to raise an exception
when displaying the documentation for __builtin__.property,
as its __doc__ attribute was now being returned when you
asked for property.__doc__ (rather than the type.__doc__
descriptor taking precedence and returning tp_doc).

property.__doc__ is a descriptor which returns a string for
property instances, but returns itself in the class context
(ie. getting property.__doc__).  As this is not a string or
unicode string, pydoc gets an error.

The fix (again, checked into both head and 2.2 branches)
that was checked in added a __doc__ descriptor again.  This
descriptor returns tp_doc for non heap type classes, and
looks up __doc__ in the class dictionary for heap type classes.

This causes problems for both heap and non heap classes: for
non heap classes, __doc__ in the class dict is never
accessed.  For heap classes, the tp_descr_get method of
__doc__ is never called.

Here is my prefered way to fix the problem (which you may
disagree with):

1. remove the type.__doc__ descriptor again

2. make the property.__doc__ descriptor return something
meaningful in the class context

3. make pydoc handle non string-like __doc__ attributes
better (either ignoring them or converting them to strings).
 Currently I can get help() to error out with a simple class
like:
    class foo:
        __doc__ = 42

(I am not saying that people should use integers as __doc__;
just that pydoc should handle things like this more gracefully).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:31

Message:
Logged In: YES 
user_id=6380

James, can you please explain the problem again, but without
referring to other existing patches?  With all the
references to pydoc, inspect, properties, descriptors, other
patches and SF bug reports I have completely lost the trail,
and I don't think it's productive for me to try and gather
all the separate bits together.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 11:29

Message:
Logged In: YES 
user_id=21627

This is not (primarily) a pydoc issue: with your change,
property.__doc__ gets changed. pydoc could ignore the object
returned, but then property would have no documentation at
all - even though there is a tp_doc in it. So I don't see
any easy solution. If you do, please attach a patch for the
current CVS (we can then decide whether to backport it to
2.2.2).

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 11:06

Message:
Logged In: YES 
user_id=146903

Maybe getting pydoc to ignore any __doc__ attributes (that
is, what gets returned by getattr) that weren't strings or
unicode would work.

As for using a different metatype, a reason for getting this
into the the standard metatype is that it is also an
inconsistency between how new and old style classes act, and
is fairly easy to reconcile (granted descriptors didn't
exist in python < 2.2, but everytime new style classes act a
bit differently, people seem to start submitting pygtk bug
reports).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 10:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 10:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 09:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 09:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 09:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 14:46:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 06:46:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16x6oD-0008EM-00@usw-sf-web1.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 12:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

>Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 13:46

Message:
Logged In: YES 
user_id=495820

The data structures used internally by class _A cannot
by cast into the 'basicsize\itemsize' scheme (i.e. a 
sparse matrix type). So tp_itemsize actually is set to 
zero for type _A and its allocator invokes malloc to
request memory for the initial data structure (which
is going to grow dynamically when a sparse matrix
is build up in a Python program).

Why would we need the tp_alloc slot at all, if the 
'memory demands' of any class (its instances 
respectively) would fit into the 'basicsize\itemsize'-
scheme?

I just looked into the source for the 'int' object.
The tp_alloc slot is set to zero, allocation is
done in 'int_new'. (so it didn't enlighten me...)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 13:01

Message:
Logged In: YES 
user_id=6380

Your understanding of instance allocation doesn't match
reality, *or* you're expressing yourself poorly. Allocation
does not include initialization; allocation simply requests
the memory for the object from malloc (or some other memory
allocator) and fills it with zeros, except for the reference
count, which is set to 1, and the ob_type field, which is
set to the type argument to the allocator. The amount of
memory allocated for the object is calculated by taking the
tp_basicsize of the type object, and adding nitems times the
tp_itemsize from the type object.

If you want to initialize your object, that should be done
in the tp_new slot, not in tp_alloc.

Have you tried to read the source code (or go through an
allocation in a C debugger) to find out how it really works?

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 08:06

Message:
Logged In: YES 
user_id=495820

The class A does not know how to allocate the 'base part' of instances of itself
(i.e. what makes an instance of class _A). Thus sometime during instantiation 
of class A objects, the allocater of the base class must be called!
This will not happen, however, if the tp_new-slot function merely calls the 
allocator of the argument type.

You pointed out, that e.g. subclasses of 'int' won't inherit int's special allocator.
Does this mean, int's allocator will not be invoked on instantiation of the subclass?
Then, I don't understand why this works; I can only imagine, that PyType_GenericAlloc
is designed to deal with Python built-in types (and probably compostitions of these).




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 00:09

Message:
Logged In: YES 
user_id=6380

> PyType_GenericNew should also invoke all allocator 
> functions of the argument type's superclasses (in 
> reverse mro, I think).

No, this doesn't make sense; you can't invoke
more than one allocator. (Each allocator would
create a whole new object.)

The cause of your problem is in type_new(): it
always overrides tp_alloc with PyType_GenericAlloc.
You'd have to write a new metaclass (inheriting
from type) in C to change the tp_alloc (and tp_free)
settings.

But why do you want this? Why do you want
A instances to use the same allocator as _A?
This is not how subclassing built-in types works
elsewhere; e.g. int uses a special allocator,
but subclasses of int don't inherit that.

Before I do anything about this I'd like to
understand what you are trying to accomplish.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 14:59:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 06:59:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16x70b-0005eU-00@usw-sf-web3.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 08:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:59

Message:
Logged In: YES 
user_id=6380

I'm closing this now, because I don't see the bug in Python.
I do see the bug in your approach. You can't dynamically
grow the memory allocated for an object! That would move the
object in memory and would invalidate all pointers to the
object. The right approach is to have a fixed-size object
that contains a pointer to separately allocated memory.
(Like the list and dict object do.) BTW the tp_alloc slot is
needed because some types have a faster allocator, not to
improve upon the initial allocation size calculation.

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 09:46

Message:
Logged In: YES 
user_id=495820

The data structures used internally by class _A cannot
by cast into the 'basicsize\itemsize' scheme (i.e. a 
sparse matrix type). So tp_itemsize actually is set to 
zero for type _A and its allocator invokes malloc to
request memory for the initial data structure (which
is going to grow dynamically when a sparse matrix
is build up in a Python program).

Why would we need the tp_alloc slot at all, if the 
'memory demands' of any class (its instances 
respectively) would fit into the 'basicsize\itemsize'-
scheme?

I just looked into the source for the 'int' object.
The tp_alloc slot is set to zero, allocation is
done in 'int_new'. (so it didn't enlighten me...)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:01

Message:
Logged In: YES 
user_id=6380

Your understanding of instance allocation doesn't match
reality, *or* you're expressing yourself poorly. Allocation
does not include initialization; allocation simply requests
the memory for the object from malloc (or some other memory
allocator) and fills it with zeros, except for the reference
count, which is set to 1, and the ob_type field, which is
set to the type argument to the allocator. The amount of
memory allocated for the object is calculated by taking the
tp_basicsize of the type object, and adding nitems times the
tp_itemsize from the type object.

If you want to initialize your object, that should be done
in the tp_new slot, not in tp_alloc.

Have you tried to read the source code (or go through an
allocation in a C debugger) to find out how it really works?

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 04:06

Message:
Logged In: YES 
user_id=495820

The class A does not know how to allocate the 'base part' of instances of itself
(i.e. what makes an instance of class _A). Thus sometime during instantiation 
of class A objects, the allocater of the base class must be called!
This will not happen, however, if the tp_new-slot function merely calls the 
allocator of the argument type.

You pointed out, that e.g. subclasses of 'int' won't inherit int's special allocator.
Does this mean, int's allocator will not be invoked on instantiation of the subclass?
Then, I don't understand why this works; I can only imagine, that PyType_GenericAlloc
is designed to deal with Python built-in types (and probably compostitions of these).




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:09

Message:
Logged In: YES 
user_id=6380

> PyType_GenericNew should also invoke all allocator 
> functions of the argument type's superclasses (in 
> reverse mro, I think).

No, this doesn't make sense; you can't invoke
more than one allocator. (Each allocator would
create a whole new object.)

The cause of your problem is in type_new(): it
always overrides tp_alloc with PyType_GenericAlloc.
You'd have to write a new metaclass (inheriting
from type) in C to change the tp_alloc (and tp_free)
settings.

But why do you want this? Why do you want
A instances to use the same allocator as _A?
This is not how subclassing built-in types works
elsewhere; e.g. int uses a special allocator,
but subclasses of int don't inherit that.

Before I do anything about this I'd like to
understand what you are trying to accomplish.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 15:32:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 07:32:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16x7X1-0000NA-00@usw-sf-web1.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 12:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

>Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 14:32

Message:
Logged In: YES 
user_id=495820

> ...The right approach is to have a fixed-size object
> that contains a pointer to separately allocated memory.

This is how it works. I admit, I expressed myself 
poorly here.

Do you affirm at the end, that types with dynamic memory
requirements cannot be subclassed at the Python level,
unless one also implements a special function for the
tp_new slot -- to make sure that the base class 
allocator gets invoked...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 13:59

Message:
Logged In: YES 
user_id=6380

I'm closing this now, because I don't see the bug in Python.
I do see the bug in your approach. You can't dynamically
grow the memory allocated for an object! That would move the
object in memory and would invalidate all pointers to the
object. The right approach is to have a fixed-size object
that contains a pointer to separately allocated memory.
(Like the list and dict object do.) BTW the tp_alloc slot is
needed because some types have a faster allocator, not to
improve upon the initial allocation size calculation.

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 13:46

Message:
Logged In: YES 
user_id=495820

The data structures used internally by class _A cannot
by cast into the 'basicsize\itemsize' scheme (i.e. a 
sparse matrix type). So tp_itemsize actually is set to 
zero for type _A and its allocator invokes malloc to
request memory for the initial data structure (which
is going to grow dynamically when a sparse matrix
is build up in a Python program).

Why would we need the tp_alloc slot at all, if the 
'memory demands' of any class (its instances 
respectively) would fit into the 'basicsize\itemsize'-
scheme?

I just looked into the source for the 'int' object.
The tp_alloc slot is set to zero, allocation is
done in 'int_new'. (so it didn't enlighten me...)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 13:01

Message:
Logged In: YES 
user_id=6380

Your understanding of instance allocation doesn't match
reality, *or* you're expressing yourself poorly. Allocation
does not include initialization; allocation simply requests
the memory for the object from malloc (or some other memory
allocator) and fills it with zeros, except for the reference
count, which is set to 1, and the ob_type field, which is
set to the type argument to the allocator. The amount of
memory allocated for the object is calculated by taking the
tp_basicsize of the type object, and adding nitems times the
tp_itemsize from the type object.

If you want to initialize your object, that should be done
in the tp_new slot, not in tp_alloc.

Have you tried to read the source code (or go through an
allocation in a C debugger) to find out how it really works?

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 08:06

Message:
Logged In: YES 
user_id=495820

The class A does not know how to allocate the 'base part' of instances of itself
(i.e. what makes an instance of class _A). Thus sometime during instantiation 
of class A objects, the allocater of the base class must be called!
This will not happen, however, if the tp_new-slot function merely calls the 
allocator of the argument type.

You pointed out, that e.g. subclasses of 'int' won't inherit int's special allocator.
Does this mean, int's allocator will not be invoked on instantiation of the subclass?
Then, I don't understand why this works; I can only imagine, that PyType_GenericAlloc
is designed to deal with Python built-in types (and probably compostitions of these).




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 00:09

Message:
Logged In: YES 
user_id=6380

> PyType_GenericNew should also invoke all allocator 
> functions of the argument type's superclasses (in 
> reverse mro, I think).

No, this doesn't make sense; you can't invoke
more than one allocator. (Each allocator would
create a whole new object.)

The cause of your problem is in type_new(): it
always overrides tp_alloc with PyType_GenericAlloc.
You'd have to write a new metaclass (inheriting
from type) in C to change the tp_alloc (and tp_free)
settings.

But why do you want this? Why do you want
A instances to use the same allocator as _A?
This is not how subclassing built-in types works
elsewhere; e.g. int uses a special allocator,
but subclasses of int don't inherit that.

Before I do anything about this I'd like to
understand what you are trying to accomplish.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 15:37:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 07:37:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-540965 ] PyType_GenericNew broken
Message-ID: <E16x7c1-0000Qu-00@usw-sf-web1.sourceforge.net>

Bugs item #540965, was opened at 2002-04-08 08:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Closed
Resolution: Rejected
Priority: 5
Submitted By: Ralf Juengling (rjuengling)
Assigned to: Guido van Rossum (gvanrossum)
Summary: PyType_GenericNew broken

Initial Comment:
A new Python type/class _A is implemented in C.
It needs a special allocator function, thus
tp_alloc=_A_alloc for this type. There is no need
for a special new-method, however, thus
tp_new=PyType_GenericNew for this type.

The class A inherits from _A and is implemented
in Python:

class A(_A):
	pass

When an instance of _A is created, its allocator
function _A_alloc gets invoked. When an instance 
of A is created, the _A_alloc does not get invoked.


PyType_GenericNew should also invoke all allocator 
functions of the argument type's superclasses (in 
reverse mro, I think).



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 10:37

Message:
Logged In: YES 
user_id=6380

> Do you affirm...

Yes, but I would phrase it differently. Anything that
ploinks stuff in the object (even a pointer to additional
allocated memory) should be implemented as part of tp_new,
which is inherited, rather than tp_alloc. Allocating
additional memory is not part of tp_alloc's
responsibilities, it's part of tp_new.

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 10:32

Message:
Logged In: YES 
user_id=495820

> ...The right approach is to have a fixed-size object
> that contains a pointer to separately allocated memory.

This is how it works. I admit, I expressed myself 
poorly here.

Do you affirm at the end, that types with dynamic memory
requirements cannot be subclassed at the Python level,
unless one also implements a special function for the
tp_new slot -- to make sure that the base class 
allocator gets invoked...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:59

Message:
Logged In: YES 
user_id=6380

I'm closing this now, because I don't see the bug in Python.
I do see the bug in your approach. You can't dynamically
grow the memory allocated for an object! That would move the
object in memory and would invalidate all pointers to the
object. The right approach is to have a fixed-size object
that contains a pointer to separately allocated memory.
(Like the list and dict object do.) BTW the tp_alloc slot is
needed because some types have a faster allocator, not to
improve upon the initial allocation size calculation.

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 09:46

Message:
Logged In: YES 
user_id=495820

The data structures used internally by class _A cannot
by cast into the 'basicsize\itemsize' scheme (i.e. a 
sparse matrix type). So tp_itemsize actually is set to 
zero for type _A and its allocator invokes malloc to
request memory for the initial data structure (which
is going to grow dynamically when a sparse matrix
is build up in a Python program).

Why would we need the tp_alloc slot at all, if the 
'memory demands' of any class (its instances 
respectively) would fit into the 'basicsize\itemsize'-
scheme?

I just looked into the source for the 'int' object.
The tp_alloc slot is set to zero, allocation is
done in 'int_new'. (so it didn't enlighten me...)




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:01

Message:
Logged In: YES 
user_id=6380

Your understanding of instance allocation doesn't match
reality, *or* you're expressing yourself poorly. Allocation
does not include initialization; allocation simply requests
the memory for the object from malloc (or some other memory
allocator) and fills it with zeros, except for the reference
count, which is set to 1, and the ob_type field, which is
set to the type argument to the allocator. The amount of
memory allocated for the object is calculated by taking the
tp_basicsize of the type object, and adding nitems times the
tp_itemsize from the type object.

If you want to initialize your object, that should be done
in the tp_new slot, not in tp_alloc.

Have you tried to read the source code (or go through an
allocation in a C debugger) to find out how it really works?

----------------------------------------------------------------------

Comment By: Ralf Juengling (rjuengling)
Date: 2002-04-15 04:06

Message:
Logged In: YES 
user_id=495820

The class A does not know how to allocate the 'base part' of instances of itself
(i.e. what makes an instance of class _A). Thus sometime during instantiation 
of class A objects, the allocater of the base class must be called!
This will not happen, however, if the tp_new-slot function merely calls the 
allocator of the argument type.

You pointed out, that e.g. subclasses of 'int' won't inherit int's special allocator.
Does this mean, int's allocator will not be invoked on instantiation of the subclass?
Then, I don't understand why this works; I can only imagine, that PyType_GenericAlloc
is designed to deal with Python built-in types (and probably compostitions of these).




----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:09

Message:
Logged In: YES 
user_id=6380

> PyType_GenericNew should also invoke all allocator 
> functions of the argument type's superclasses (in 
> reverse mro, I think).

No, this doesn't make sense; you can't invoke
more than one allocator. (Each allocator would
create a whole new object.)

The cause of your problem is in type_new(): it
always overrides tp_alloc with PyType_GenericAlloc.
You'd have to write a new metaclass (inheriting
from type) in C to change the tp_alloc (and tp_free)
settings.

But why do you want this? Why do you want
A instances to use the same allocator as _A?
This is not how subclassing built-in types works
elsewhere; e.g. int uses a special allocator,
but subclasses of int don't inherit that.

Before I do anything about this I'd like to
understand what you are trying to accomplish.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540965&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 16:53:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 08:53:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-544234 ] httplib cannot talk SSL to MS IIS
Message-ID: <E16x8ms-0004Iq-00@usw-sf-web2.sourceforge.net>

Bugs item #544234, was opened at 2002-04-15 16:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544234&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib cannot talk SSL to MS IIS

Initial Comment:
This is a duplicate of bug 494762. That bug was closed 
as "invalid", however what I don't think was 
appreciated at the time is that it is not just that 
one server that has this problem, it is a generic 
problem with MS IIS servers.

The choices are:

  (a) leave the code like it is, Python can't talk SSL 
to MS IIS servers
  (b) persuade Microsoft to fix their code, and then 
persuade every MS IIS installation on the planet to 
upgrade
  (c) put a work-around in the Python code

Since I hope that both (a) and (b) are obviously 
unacceptable, I think a suitable work-around would be 
to add another clause to the except statement in 
FakeSocket.makefile as follows:

  if err[1] == "EOF occurred in violation of protocol":
    break

i.e. treat that error as EOF, because that's what it 
actually means.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544234&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 17:29:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 09:29:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-544248 ] gcc warning in unicodeobject.c
Message-ID: <E16x9Lu-0004kB-00@usw-sf-web2.sourceforge.net>

Bugs item #544248, was opened at 2002-04-15 18:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Walter D�rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: gcc warning in unicodeobject.c

Initial Comment:
gcc 2.96 on Linux (RedHat 7.1) issues the following 
warning when compiling Objects/unicodeobject.c 2.138 
(configured with --enable-unicode=ucs4)

Objects/unicodeobject.c: In function 
`PyUnicodeUCS4_Format':
Objects/unicodeobject.c:5574: warning: int format, 
long int 
arg (arg 3)
Objects/unicodeobject.c:5574: warning: unsigned int 
format, 
long unsigned int arg (arg 4)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544248&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 17:37:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 09:37:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-544255 ] gcc warning in Modules/posixmodule.c
Message-ID: <E16x9UA-0007AW-00@usw-sf-web4.sourceforge.net>

Bugs item #544255, was opened at 2002-04-15 18:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544255&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Walter D�rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: gcc warning in Modules/posixmodule.c

Initial Comment:
gcc 2.96 on Linux (RedHat 7.1) issues the following 
warning when compiling Modules/posixmodule.c 2.228:
libpython2.3.a(posixmodule.o): In function 
`posix_tmpnam':
/home/walter/Python-current-
readonly/dist/src/./Modules/posixmodule.c:5150: the 
use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.3.a(posixmodule.o): In function 
`posix_tempnam':
/home/walter/Python-current-
readonly/dist/src/./Modules/posixmodule.c:5100: the 
use of `tempnam' is dangerous, better use `mkstemp'

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544255&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 17:58:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 09:58:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-544265 ] gcc warning in Modules/readline.c
Message-ID: <E16x9oh-0007ia-00@usw-sf-web3.sourceforge.net>

Bugs item #544265, was opened at 2002-04-15 18:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544265&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 1
Submitted By: Walter D�rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: gcc warning in Modules/readline.c

Initial Comment:
gcc 2.96 on Linux (RedHat 7.1) issues the following 
warning when compiling Modules/readline 2.47:
Modules/readline.c: In function `set_completer_delims':
Modules/readline.c:273: warning: passing arg 1 of 
`free' 
discards qualifiers from pointer target type


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544265&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 18:12:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 10:12:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-540720 ] test_email fails on Mac in summer
Message-ID: <E16xA2E-0007th-00@usw-sf-web3.sourceforge.net>

Bugs item #540720, was opened at 2002-04-07 17:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470

Category: Python Library
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_email fails on Mac in summer

Initial Comment:
Yes, I kid you not:-)

The test of the date/time  parser in test_email tries to cater for the fact that the Mac uses localtime (at least, before OSX), but it fails to cater for DST. So, test_email passes in winter, but fails in summer.

I think the whole idea of comparing based on a numeric value is not so good. Why not try a roundtrip, or compare against another date coder (time.asctime)?

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 13:12

Message:
Logged In: YES 
user_id=12800

Actually, forget the patch.  I integrated email 2.0 into
Python 2.3's cvs and this included the proposed fix.  Take a
look at test_formatdate() and test_formatdate_localtime() in
Lib/test/test_email.py and let me know what you think.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-09 17:49

Message:
Logged In: YES 
user_id=45365

Barry,
I can't apply the patch, it seems to be against a different version of test_email than what's in the repository (I tried both the trunk and the 22 maintainance branch).

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-08 02:15

Message:
Logged In: YES 
user_id=12800

What do you think of the attached patch?  Is this still a
useful test to include?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 18:14:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 10:14:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-537484 ] SMTPLib sendmail fails on hyphenated adr
Message-ID: <E16xA3r-0007vY-00@usw-sf-web3.sourceforge.net>

Bugs item #537484, was opened at 2002-03-31 14:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537484&group_id=5470

Category: Python Library
Group: Python 2.1.1
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Bill Anderson (shadowlore)
Assigned to: Barry Warsaw (bwarsaw)
Summary: SMTPLib sendmail fails on hyphenated adr

Initial Comment:
When using smtplib's SMTP.sendmail, if the To: address
contains a hyphen, the To: header will be silently dropped.

To duplicate:

Follow the docstring for smtplib.SMTP.sendmail, and use
a hyphenated email address, such as foo-help@somewhere.org






----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 13:14

Message:
Logged In: YES 
user_id=12800

I'm moving this status to Pending; waiting on a response
from the submitter.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-01 00:35

Message:
Logged In: YES 
user_id=12800

I don't believe it.  I use smtplib all the time to send
messages to Mailman addresses that contain hyphens and I've
never seen a problem, going back to Python 1.5.2 and up to
Python 2.3(cvs).

Note that as far as the SMTP protocol is concerned, and
smtplib as well, the body of the message which contains the
To: header, really isn't part of the SMTP dialog.  The
envelope sender and recipients are the important determining
factors in where the message goes and where the message
comes from.  These are the first two arguments to
.sendmail().  The body of the message -- including the
headers -- is spit right out to the SMTP server, after
canonicalizing stuff like line endings as per the RFC.

Much more likely is that your MTA -- i.e. the thing you're
connected to (your SMTP server) -- is munging things.

If you can explain more about your environment, I might be
able to help.  You should also attach a .py file that
exactly reproduces your problem and I will test it with my MTA.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=537484&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 18:18:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 10:18:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-531205 ] Bugs in rfc822.parseaddr()
Message-ID: <E16xA7u-0007yk-00@usw-sf-web3.sourceforge.net>

Bugs item #531205, was opened at 2002-03-18 00:13
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
>Assigned to: Ben Gertzfield (che_fox)
Summary: Bugs in rfc822.parseaddr()

Initial Comment:
This bug is in rfc822.parseaddr(), and thus inherited
into email.Utils.parseaddr() since the latter does a
straight include of the former.  It has a nasty bug
when the email address contains embedded spaces: it
collapses the spaces:

>>> from email.Utils import parseaddr
>>> parseaddr('foo bar@wooz.org')
('', 'foobar@wooz.org')
>>> parseaddr('<foo bar@wooz.org>')
('', 'foobar@wooz.org')

Boo, hiss.  Of course parseaddr() would be more
involved to implement in an RFC 2822 compliant way, but
it would be very cool.

Note that I'm reporting this bug here instead of the
mimelib project because it's actually in rfc822.py. 
Once solution might include fixing it in the email
package only.




----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 13:18

Message:
Logged In: YES 
user_id=12800

Note further that "foo bar"@wooz.org is properly parsed. 
The question is, what should parseaddr() do in this
non-compliant situation?  I can think of a couple of things:

- it could raise an exception
- it could return ('', 'bar@wooz.org')
- it could return ('foo', 'bar@wooz.org')
- it could return ('' '"foo bar"@wooz.org')

I'm not sure what the right thing to do is.  I'm assigning
to Ben Gertzfield to get his opinion.  Ben, feel free to add
a comment and re-assign the bug to me.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=531205&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 18:28:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 10:28:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-504152 ] rfc822 long header continuation broken
Message-ID: <E16xAHM-0007ly-00@usw-sf-web4.sourceforge.net>

Bugs item #504152, was opened at 2002-01-15 20:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470

Category: Python Library
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Jones (richard)
>Assigned to: Ben Gertzfield (che_fox)
Summary: rfc822 long header continuation broken

Initial Comment:
I don't believe this is fixed in 2.1.2 or 2.2, but
haven't checked.

The code in rfc822.Message.readheaders incorrectly
unfolds long message headers. The relevant information
from rfc2822 is in section 2.2.3. In short:

"""
The process of moving from this folded multiple-line
representation of a header field to its single line
representation is called "unfolding". Unfolding is
accomplished by simply removing any CRLF that is
immediately followed by WSP.  Each header field should
be treated in its unfolded form for further syntactic
and semantic evaluation.
"""

This means that the code in readheaders:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = (self.dict[headerseen] + "\n " +
line.strip())
                self.dict[headerseen] = x.strip()
                continue

should be:

            if headerseen and line[0] in ' \t':
                # It's a continuation line.
                list.append(line)
                x = self.dict[headerseen] + line
                self.dict[headerseen] = x.strip()
                continue

ie. no stripping of the leading whitespace and no
adding the newline.


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 13:28

Message:
Logged In: YES 
user_id=12800

There is some value in not unfolding long lines by default.
 FWIW, the email package also retains the line breaks for
such multi-line headers.  The advantage to retaining this is
that message input/output can be idempotent (i.e. you get
the same thing in as you get out).  This can be useful when
using the message to generate a hash value, and for other
user-friendly reasons.

That being said, there is also some use in providing a way
to return the unfolded line.  I don't see a lot of benefit
in adding such a feature to the rfc822 module, but I could
see adding it to the email package.  Specifically, I would
propose to add it to the email.Header.Header class, either
as a separate method (e.g. Header.unfold()) or as a default
argument to the Header.encode() method (e.g.
Header.encode(self, unfold=0)).

If we did the latter, then I'd change Header.__str__() to
call .encode(unfold=1).

Assigning to Ben to get his feedback.  Ben, feel free to
comment and re-assign this bug to me.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-01-16 07:14

Message:
Logged In: YES 
user_id=21627

Even though it might not matter, I don't think changing it
would hurt, either, and the change brings it definitely
closer to following the word of RFC 2822. 

If no case is brought forward where it matters, fixing it
for 2.3 alone should be sufficient.

----------------------------------------------------------------------

Comment By: Richard Jones (richard)
Date: 2002-01-16 07:12

Message:
Logged In: YES 
user_id=6405

Yes, we had someone submit a bug report on the roundup 
users mailing list because someone had sent a message to 
the roundup mail gateway which was split. The client was 
extra-specially broken, since it split in the middle of a 
word (which is not to spec), but the more general case of 
folding on whitespace will cause roundup problems since I 
hadn't expected there to be any newlines in the header.

I can modify roundup to strip out the newline, but it'd be 
nice to have rfc822.Message not put it in there...



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-15 21:47

Message:
Logged In: YES 
user_id=6380

Richard, have you found a situation where it matters? I
thought that usually the next phase calls for normalizing
whitespace by squashing repeated spaces/tabs and removing
them from front and back.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=504152&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 20:42:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 12:42:35 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-536796 ] fchdir
Message-ID: <E16xCN1-0003yN-00@usw-sf-web1.sourceforge.net>

Feature Requests item #536796, was opened at 2002-03-29 11:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=536796&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Paul Jarc (prjsf)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fchdir

Initial Comment:
os.fchdir(fd) would be a welcome addition.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-15 15:42

Message:
Logged In: YES 
user_id=3066

Added for Python 2.3.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-13 12:54

Message:
Logged In: YES 
user_id=3066

Patch in development, but got interrupted.  Will finish
later & close this.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=536796&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 21:03:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 13:03:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-498572 ] smtplib.py AUTH mechanism
Message-ID: <E16xChK-0007A3-00@usw-sf-web2.sourceforge.net>

Bugs item #498572, was opened at 2002-01-02 11:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Mauro Cicognini (mcicogni)
Assigned to: Barry Warsaw (bwarsaw)
Summary: smtplib.py AUTH mechanism

Initial Comment:
Currently the AUTH implementation within smtplib.py does not fully comply to RFC 2554.
This RFC explicitly states on page 7:

   auth_command    = "AUTH" SPACE auth_type [SPACE (base64 / "=")]
                     *(CRLF [base64]) CRLF

Therefore, after the AUTH token there _must_ be an ASCII blank.

However, the ESMTP features parsing code uses a RE that will match any alphanumeric string, 
stopping at the first non-alphanumeric character (smtplib.py, line 394):

     '(?P<feature>[A-Za-z0-9][A-Za-z0-9\-]*)'

and will also match, for example, "AUTH=LOGIN", which it shouldn't.

This poses a problem when trying to authenticate against an iPlanet Messaging Server MTA, which 
responds to EHLO with 

... (other features)
AUTH PLAIN LOGIN
STARTTLS
AUTH=LOGIN

and obviously the second AUTH token "feature list" overwrites the first (we get just ['=LOGIN'], 
which isn't really useful in any case).

I suppose the MTA isn't telling the MUA a second set of AUTH features, but merely letting the 
MUA 
know that it may insert the AUTH=<...> parameter on the MAIL FROM command (see the same 
RFC 
2554, section 5, page 4).
Anyway, the RFC mandates for a space between the AUTH token and the implemented 
authentication mechanism list, so this should not be a problem in the first place (smtplib.py could 
just ignore the improperly-constructed feature line).

By the way, the AUTH LOGIN mechanism is iPlanet-Netscape proprietary, so the only well-known 
method to use in this case would be PLAIN.

This "bug" is trivial to fix (just add a space as the last character of the RE) but I don't know about 
other ESMTP service extensions, which may ask for characters other than space as delimiters.
However, I don't know of any existing ESMTP extensions not using the ASCII blank as a token 
separator, so I think the aforementioned correction could be put in place.

Thank you,
Mauro Cicognini
Siosistemi S.p.A., Italy


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 16:03

Message:
Logged In: YES 
user_id=12800

Actually, the relevant RFC is 1869 which describes ESTMP. 
This RFC requires that there be an ASCII space between
ehlo-keyword and the ehlo-param(eters).  Furthermore, `=' is
not a valid character in an ehlo-keyword so I believe a
response line that starts

250-AUTH=LOGIN

is non-conformant to the RFC and should be ignored.  Your
patch isn't quite right though, since the trailing space
will not exist if there are no ehlo-params for the
ehlo-keyword.  I'll check in a proper fix though, thanks!

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-01-02 22:28

Message:
Logged In: YES 
user_id=6380

Would you mind submitting a patch?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=498572&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 21:12:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 13:12:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-460357 ] test_time fails on Sparc64
Message-ID: <E16xCpw-0001T4-00@usw-sf-web3.sourceforge.net>

Bugs item #460357, was opened at 2001-09-10 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470

Category: Extension Modules
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Martin v. L�wis (loewis)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_time fails on Sparc64

Initial Comment:
On Solaris8, with the WS6U1 compiler, after setting CC
to 'cc -xarch=v9', test_time.py fails with

  File "Lib/test/test_time.py", line 46, in test_mktime
    time.mktime, (999999, 999999, 999999, 999999,
  File
"/vol/marvin-vol8/loewis/python/dist/src/Lib/unittest.py",
line 273, in failUnlessRaises
    raise self.failureException, excName
AssertionError: OverflowError

The problem is that the test doesn't overflow. Instead,
it gives the value 34214554704339.0.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 16:12

Message:
Logged In: YES 
user_id=12800

I'm inclined to remove the whole test.  Certainly testing
for OverflowError isn't useful (and if I ever thought it
was, I can't remember why), so about the only useful thing I
can think to test would be that a localtime() to mktime()
roundtrip is idempotent.

If we really wanted to test for OverflowError (or ValueError
as the docs specify /could/ occur instead), then would using
(sys.maxint,)*9 be better?  That still seems icky to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-03 14:27

Message:
Logged In: YES 
user_id=31435

Raised priority and changed Group to 2.2.1 candidate.  We 
can't assume that time_t is too feeble to represent the 
date being tested, and Barry should rework the test so that 
it doesn't fail on 64-bit boxes (I recall that he wanted to 
test *something* here for Mailman's purposes, so it's up to 
him to figure out what he really wants -- testing that the 
platform has a feeble time_t ain't it).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 04:39

Message:
Logged In: YES 
user_id=21627

Assigned to Barry, since Tim assigned #538369 to Barry.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 04:34

Message:
Logged In: YES 
user_id=21627

This was reported for alpha as well, as #538369.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 22:22:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 14:22:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-543244 ] installation atop 2.2 fails
Message-ID: <E16xDvj-0007vU-00@usw-sf-web2.sourceforge.net>

Bugs item #543244, was opened at 2002-04-13 00:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470

Category: Installation
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: David Abrahams (david_abrahams)
Assigned to: Nobody/Anonymous (nobody)
Summary: installation atop 2.2 fails

Initial Comment:
Installing Python 2.2.1 atop Python 2.2 on cygwin 
fails at the last stage when it tries to create a 
link from /usr/bin/python.exe -> /usr/bin/python-
2.2.exe. Since the link already exists, installation 
stops.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-15 23:22

Message:
Logged In: YES 
user_id=21627

The ln I quoted was actually from a Linux 'make install'; I
cannot reproduce the cygwin install since I don't have
cygwin - but it *should* only differ in the BINDIR. Since
there is only one ln invocation in the makefile, it is hard
to believe that 'make install' tries to create a link in the
reverse direction.

----------------------------------------------------------------------

Comment By: David Abrahams (david_abrahams)
Date: 2002-04-15 02:31

Message:
Logged In: YES 
user_id=52572

No, it's not that ln. Read my report again. It's 
linking /usr/bin/python -> /usr/bin/python2.2.exe. 
No "local" in the path. Since I've already installed 
2.2.1, I can't reproduce the behavior anymore without 
building myself a fresh 2.2... but it happened twice, once 
on a pydebug installation of 2.2.1 over 2.2 and once on a 
regular build.


-Dave


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-14 01:13

Message:
Logged In: YES 
user_id=21627

Can you report the precise sequence of commands being 
executed? Normally, it should be 
 
if test -f /usr/local/bin/python; \ 
then rm -f /usr/local/bin/python; \ 
else true; \ 
fi 
(cd /usr/local/bin; ln python2.2 python) 
 
If this is the ln that fails, it is not clear why the 
target already exists: the rm command is supposed to 
delete it. 

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 01:09

Message:
Logged In: YES 
user_id=31435

Change Group to Platform-specific.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543244&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 22:24:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 14:24:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-544234 ] httplib cannot talk SSL to MS IIS
Message-ID: <E16xDxI-0007wZ-00@usw-sf-web2.sourceforge.net>

Bugs item #544234, was opened at 2002-04-15 17:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544234&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib cannot talk SSL to MS IIS

Initial Comment:
This is a duplicate of bug 494762. That bug was closed 
as "invalid", however what I don't think was 
appreciated at the time is that it is not just that 
one server that has this problem, it is a generic 
problem with MS IIS servers.

The choices are:

  (a) leave the code like it is, Python can't talk SSL 
to MS IIS servers
  (b) persuade Microsoft to fix their code, and then 
persuade every MS IIS installation on the planet to 
upgrade
  (c) put a work-around in the Python code

Since I hope that both (a) and (b) are obviously 
unacceptable, I think a suitable work-around would be 
to add another clause to the except statement in 
FakeSocket.makefile as follows:

  if err[1] == "EOF occurred in violation of protocol":
    break

i.e. treat that error as EOF, because that's what it 
actually means.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-15 23:24

Message:
Logged In: YES 
user_id=21627

Can you please try http://python.org/sf/500311? Feedback on
this patch would be much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544234&group_id=5470



From noreply@sourceforge.net  Mon Apr 15 22:27:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 14:27:50 -0700
Subject: [Python-bugs-list] [ python-Bugs-544255 ] gcc warning in Modules/posixmodule.c
Message-ID: <E16xE0s-0007yd-00@usw-sf-web2.sourceforge.net>

Bugs item #544255, was opened at 2002-04-15 18:37
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544255&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 3
Submitted By: Walter D�rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: gcc warning in Modules/posixmodule.c

Initial Comment:
gcc 2.96 on Linux (RedHat 7.1) issues the following 
warning when compiling Modules/posixmodule.c 2.228:
libpython2.3.a(posixmodule.o): In function 
`posix_tmpnam':
/home/walter/Python-current-
readonly/dist/src/./Modules/posixmodule.c:5150: the 
use of `tmpnam_r' is dangerous, better use `mkstemp'
libpython2.3.a(posixmodule.o): In function 
`posix_tempnam':
/home/walter/Python-current-
readonly/dist/src/./Modules/posixmodule.c:5100: the 
use of `tempnam' is dangerous, better use `mkstemp'

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-15 23:27

Message:
Logged In: YES 
user_id=21627

This is a duplicate of #486434.


From noreply@sourceforge.net  Tue Apr 16 00:45:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 16:45:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-542737 ] Build unable to import w/gcc 3.0.4
Message-ID: <E16xG9i-0003Zt-00@usw-sf-web3.sourceforge.net>

Bugs item #542737, was opened at 2002-04-11 19:06
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Henderson (blueronin)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build unable to import w/gcc 3.0.4

Initial Comment:
I'm building on SunOS 5.8 with gcc 3.0.4. I needed to 
recompile 2.2 to add threads for Zope and am not 
having any of the build 'xxx' extensions succeed. My 
original compile with gcc 3.0.2 had succeeded. I've 
tried it with --with-threads and without, same 
results. I downloaded 2.2.1, same results.

Configured with --------------------
 ./configure  --prefix=/ftp/lmp/local

Make output ------------------------

/ftp/lmp/local/src/gnu/python/Python-2.2.1/
 tin/prodfix/dev > make
case $MAKEFLAGS in \
*-s*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -
g -O3 -Wall -Wstrict-prototypes' ./python -
E ./setup.py -q build;; \
*) CC='gcc' LDSHARED='gcc -shared' OPT='-DNDEBUG -g -
O3 -Wall -Wstrict-prototypes' ./python -E ./setup.py 
build;; \
esac
running build
running build_ext
building 'struct' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -
I. -I/ftp/lmphr/local/src/gnu/python/Python-
2.2.1/./Include -I/usr/local/include -IInclude/ -
c /ftp/lmphr/local/src/gnu/python/Python-
2.2.1/Modules/structmodule.c -o build/temp.solaris-2.8-
sun4u-2.2/structmodule.o
gcc -shared build/temp.solaris-2.8-sun4u-
2.2/structmodule.o -L/usr/local/lib -o 
build/lib.solaris-2.8-sun4u-2.2/struct.so
WARNING: removing "struct" since importing it failed


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-15 19:45

Message:
Logged In: YES 
user_id=33168

I had the same problem until I added the location of
libgcc_s.so.1 (I don't have gcc 3.0.4 installed in
/usr/local) to LD_LIBRARY_PATH.

In my case, this fixed the problem:
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$HOME/local/lib

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 03:30

Message:
Logged In: YES 
user_id=21627

Can you please manually invoke the gcc command lines to
build struct? Then please try to import it in the
interpreter, and report any error messages you get in doing so.

----------------------------------------------------------------------

Comment By: Mike Henderson (blueronin)
Date: 2002-04-11 20:05

Message:
Logged In: YES 
user_id=201694

The release candidate downloaded from SourceForge compiled 
w/o problems. The download with the problems came from the 
www.python.org site.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542737&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 03:04:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 19:04:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-518985 ] Ellipsis semantics undefined
Message-ID: <E16xIKq-0002Vb-00@usw-sf-web2.sourceforge.net>

Bugs item #518985, was opened at 2002-02-18 01:43
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518985&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Wayne C. Smith (wcsmith)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Ellipsis semantics undefined

Initial Comment:
The Python Reference Manual 2/4/02 2.3a0 does not
describe the effect of the ellipsis in a list
expression.  Either that or one of the two entries in
the Index is misdirected.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-15 22:04

Message:
Logged In: YES 
user_id=3066

Removed extraneous index entry in Doc/ref/ref3.tex revisions
1.87, 1.82.4.1, and 1.64.2.3.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=518985&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 03:09:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 19:09:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-544473 ] Queue module can deadlock
Message-ID: <E16xIPP-00050u-00@usw-sf-web3.sourceforge.net>

Bugs item #544473, was opened at 2002-04-16 12:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Queue module can deadlock

Initial Comment:
Prompted by a users experimentation where he was able
to show Pythonwin hanging, I have found a case where
the Queue module deadlocks.  It appears that if a
RuntimeError is generated while queueing data, the
queue lock will remain held.

Attaching a test script.  This hangs on Win2k and
Linux.  Win2k callstack shows Queue is waiting for the
following lock (line 53)

        if block:
            self.fsema.acquire()

Presumably (but untested at the moment), the previous
call to q.put(), which triggered a "RuntimeError:
maximum recursion depth exceeded", left the lock acquired.

It seems a few choice try/finally statements in the
Queue module would go along way :)  I will try and get
to this soon.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 03:47:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 15 Apr 2002 19:47:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-544473 ] Queue module can deadlock
Message-ID: <E16xJ0T-0002xO-00@usw-sf-web2.sourceforge.net>

Bugs item #544473, was opened at 2002-04-15 22:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Queue module can deadlock

Initial Comment:
Prompted by a users experimentation where he was able
to show Pythonwin hanging, I have found a case where
the Queue module deadlocks.  It appears that if a
RuntimeError is generated while queueing data, the
queue lock will remain held.

Attaching a test script.  This hangs on Win2k and
Linux.  Win2k callstack shows Queue is waiting for the
following lock (line 53)

        if block:
            self.fsema.acquire()

Presumably (but untested at the moment), the previous
call to q.put(), which triggered a "RuntimeError:
maximum recursion depth exceeded", left the lock acquired.

It seems a few choice try/finally statements in the
Queue module would go along way :)  I will try and get
to this soon.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-15 22:47

Message:
Logged In: YES 
user_id=31435

Yup, it hangs on Win98 too.  Nice job of whittling it down, 
Mark!  We've been looking for an excuse to make Queue 
slower too <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 10:16:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 02:16:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-460357 ] test_time fails on Sparc64
Message-ID: <E16xP55-000436-00@usw-sf-web1.sourceforge.net>

Bugs item #460357, was opened at 2001-09-10 17:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470

Category: Extension Modules
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 7
Submitted By: Martin v. L�wis (loewis)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_time fails on Sparc64

Initial Comment:
On Solaris8, with the WS6U1 compiler, after setting CC
to 'cc -xarch=v9', test_time.py fails with

  File "Lib/test/test_time.py", line 46, in test_mktime
    time.mktime, (999999, 999999, 999999, 999999,
  File
"/vol/marvin-vol8/loewis/python/dist/src/Lib/unittest.py",
line 273, in failUnlessRaises
    raise self.failureException, excName
AssertionError: OverflowError

The problem is that the test doesn't overflow. Instead,
it gives the value 34214554704339.0.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-16 11:16

Message:
Logged In: YES 
user_id=21627

Removing the test sounds good to me; feel free to close this
report afterwards.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 22:12

Message:
Logged In: YES 
user_id=12800

I'm inclined to remove the whole test.  Certainly testing
for OverflowError isn't useful (and if I ever thought it
was, I can't remember why), so about the only useful thing I
can think to test would be that a localtime() to mktime()
roundtrip is idempotent.

If we really wanted to test for OverflowError (or ValueError
as the docs specify /could/ occur instead), then would using
(sys.maxint,)*9 be better?  That still seems icky to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-03 21:27

Message:
Logged In: YES 
user_id=31435

Raised priority and changed Group to 2.2.1 candidate.  We 
can't assume that time_t is too feeble to represent the 
date being tested, and Barry should rework the test so that 
it doesn't fail on 64-bit boxes (I recall that he wanted to 
test *something* here for Mailman's purposes, so it's up to 
him to figure out what he really wants -- testing that the 
platform has a feeble time_t ain't it).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:39

Message:
Logged In: YES 
user_id=21627

Assigned to Barry, since Tim assigned #538369 to Barry.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 11:34

Message:
Logged In: YES 
user_id=21627

This was reported for alpha as well, as #538369.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 12:10:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 04:10:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-544609 ] cant encode unicode string to iso-8859-2
Message-ID: <E16xQrD-0002Gj-00@usw-sf-web4.sourceforge.net>

Bugs item #544609, was opened at 2002-04-16 13:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544609&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Pavel Stehule (okbob)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cant encode unicode string to iso-8859-2

Initial Comment:
>>> import sys
>>> sys.getdefaultencoding()
'ISO8859-2'
>>> s = u"P��li&#353; &#382;lu�ou�k� k�� se napil &#382;lut� vody"
>>> s.encode("iso-8859-2")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  
File "/usr/local/lib/python2.2/encodings/iso8859_2.py",
 line 18, in encode
    return codecs.charmap_encode
(input,errors,encoding_map)
UnicodeError: charmap encoding error: character maps 
to <undefined>

But I used only chars from iso-8859-2. But If didn't 
use czech chars, encoding is successfull

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544609&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 13:18:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 05:18:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-544473 ] Queue module can deadlock
Message-ID: <E16xRvB-00069q-00@usw-sf-web1.sourceforge.net>

Bugs item #544473, was opened at 2002-04-16 12:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Queue module can deadlock

Initial Comment:
Prompted by a users experimentation where he was able
to show Pythonwin hanging, I have found a case where
the Queue module deadlocks.  It appears that if a
RuntimeError is generated while queueing data, the
queue lock will remain held.

Attaching a test script.  This hangs on Win2k and
Linux.  Win2k callstack shows Queue is waiting for the
following lock (line 53)

        if block:
            self.fsema.acquire()

Presumably (but untested at the moment), the previous
call to q.put(), which triggered a "RuntimeError:
maximum recursion depth exceeded", left the lock acquired.

It seems a few choice try/finally statements in the
Queue module would go along way :)  I will try and get
to this soon.



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-16 22:18

Message:
Logged In: YES 
user_id=14198

This patch seems reasonable to me.  Tim, a quick look would 
be appreciated.  Writing a reasonable test case seems 
difficult :(  It doesn't seem worth adding this little test 
script to the test suite.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-16 12:47

Message:
Logged In: YES 
user_id=31435

Yup, it hangs on Win98 too.  Nice job of whittling it down, 
Mark!  We've been looking for an excuse to make Queue 
slower too <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 13:38:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 05:38:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-460357 ] test_time fails on Sparc64
Message-ID: <E16xSDp-0003Hg-00@usw-sf-web3.sourceforge.net>

Bugs item #460357, was opened at 2001-09-10 11:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470

Category: Extension Modules
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Martin v. L�wis (loewis)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_time fails on Sparc64

Initial Comment:
On Solaris8, with the WS6U1 compiler, after setting CC
to 'cc -xarch=v9', test_time.py fails with

  File "Lib/test/test_time.py", line 46, in test_mktime
    time.mktime, (999999, 999999, 999999, 999999,
  File
"/vol/marvin-vol8/loewis/python/dist/src/Lib/unittest.py",
line 273, in failUnlessRaises
    raise self.failureException, excName
AssertionError: OverflowError

The problem is that the test doesn't overflow. Instead,
it gives the value 34214554704339.0.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-16 08:38

Message:
Logged In: YES 
user_id=12800

Done.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-16 05:16

Message:
Logged In: YES 
user_id=21627

Removing the test sounds good to me; feel free to close this
report afterwards.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 16:12

Message:
Logged In: YES 
user_id=12800

I'm inclined to remove the whole test.  Certainly testing
for OverflowError isn't useful (and if I ever thought it
was, I can't remember why), so about the only useful thing I
can think to test would be that a localtime() to mktime()
roundtrip is idempotent.

If we really wanted to test for OverflowError (or ValueError
as the docs specify /could/ occur instead), then would using
(sys.maxint,)*9 be better?  That still seems icky to me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-03 14:27

Message:
Logged In: YES 
user_id=31435

Raised priority and changed Group to 2.2.1 candidate.  We 
can't assume that time_t is too feeble to represent the 
date being tested, and Barry should rework the test so that 
it doesn't fail on 64-bit boxes (I recall that he wanted to 
test *something* here for Mailman's purposes, so it's up to 
him to figure out what he really wants -- testing that the 
platform has a feeble time_t ain't it).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 04:39

Message:
Logged In: YES 
user_id=21627

Assigned to Barry, since Tim assigned #538369 to Barry.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-03 04:34

Message:
Logged In: YES 
user_id=21627

This was reported for alpha as well, as #538369.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=460357&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 14:01:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 06:01:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-544647 ] Inplace multiply by float
Message-ID: <E16xSaE-0003Z1-00@usw-sf-web4.sourceforge.net>

Bugs item #544647, was opened at 2002-04-16 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544647&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jay T Miller (jaytmiller)
Assigned to: Nobody/Anonymous (nobody)
Summary: Inplace multiply by float

Initial Comment:
When I import the following from "example.py":

class test1(object):
   def __init__(self):
        object.__init__(self)

   def __imul__(self, other):
       print "no luck here!"

class test2:
   def __imul__(self, other):
       print "cool!"

t = test1()
u = test2()
t *= 1.0
u *= 1.0

The following happens:

Python 2.3a0 (#6, Apr 15 2002, 17:34:04)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import example
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "example.py", line 18, in ?
   t *= 1.0
TypeError: can't multiply sequence to non-int
>>>

I take this to mean that python does not (currently)
support inplace multiply by
floats for new style classes.  Is this a bug?  A
permanent limitation?

<speculation>
Looking into this a little, my impression was that the
problem is a result of two things:

1. PyNumber_InPlaceMultiply gives "priority" to
sequence behavior if it is defined (the slot is filled
in) in a C type.

PyObject *
PyNumber_InPlaceMultiply(PyObject *v, PyObject *w)
{
        PyObject * (*g)(PyObject *, int) = NULL;
        if (HASINPLACE(v) && v->ob_type->tp_as_sequence &&
                (g =
v->ob_type->tp_as_sequence->sq_inplace_repeat)) {
                long n;
                if (PyInt_Check(w)) {
                        n  = PyInt_AsLong(w);
                }
                else if (PyLong_Check(w)) {
                        n = PyLong_AsLong(w);
                        if (n == -1 && PyErr_Occurred())
                                return NULL;
                }
                else {
                        return type_error("can't
multiply sequence to non-int");
                }
                return (*g)(v, (int)n);
        }
        return binary_iop(v, w,
NB_SLOT(nb_inplace_multiply),
                                NB_SLOT(nb_multiply),
"*=");
}


2. New style classes define all or nearly all slots.  
This means that a new style class is both a sequence
and a number.
</speculation>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544647&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 14:02:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 06:02:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-544647 ] Inplace multiply by float
Message-ID: <E16xSbR-0001N3-00@usw-sf-web2.sourceforge.net>

Bugs item #544647, was opened at 2002-04-16 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544647&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jay T Miller (jaytmiller)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Inplace multiply by float

Initial Comment:
When I import the following from "example.py":

class test1(object):
   def __init__(self):
        object.__init__(self)

   def __imul__(self, other):
       print "no luck here!"

class test2:
   def __imul__(self, other):
       print "cool!"

t = test1()
u = test2()
t *= 1.0
u *= 1.0

The following happens:

Python 2.3a0 (#6, Apr 15 2002, 17:34:04)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import example
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "example.py", line 18, in ?
   t *= 1.0
TypeError: can't multiply sequence to non-int
>>>

I take this to mean that python does not (currently)
support inplace multiply by
floats for new style classes.  Is this a bug?  A
permanent limitation?

<speculation>
Looking into this a little, my impression was that the
problem is a result of two things:

1. PyNumber_InPlaceMultiply gives "priority" to
sequence behavior if it is defined (the slot is filled
in) in a C type.

PyObject *
PyNumber_InPlaceMultiply(PyObject *v, PyObject *w)
{
        PyObject * (*g)(PyObject *, int) = NULL;
        if (HASINPLACE(v) && v->ob_type->tp_as_sequence &&
                (g =
v->ob_type->tp_as_sequence->sq_inplace_repeat)) {
                long n;
                if (PyInt_Check(w)) {
                        n  = PyInt_AsLong(w);
                }
                else if (PyLong_Check(w)) {
                        n = PyLong_AsLong(w);
                        if (n == -1 && PyErr_Occurred())
                                return NULL;
                }
                else {
                        return type_error("can't
multiply sequence to non-int");
                }
                return (*g)(v, (int)n);
        }
        return binary_iop(v, w,
NB_SLOT(nb_inplace_multiply),
                                NB_SLOT(nb_multiply),
"*=");
}


2. New style classes define all or nearly all slots.  
This means that a new style class is both a sequence
and a number.
</speculation>

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544647&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 16:25:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 08:25:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-544609 ] cant encode unicode string to iso-8859-2
Message-ID: <E16xUpa-0005Cs-00@usw-sf-web3.sourceforge.net>

Bugs item #544609, was opened at 2002-04-16 13:10
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544609&group_id=5470

Category: Unicode
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Pavel Stehule (okbob)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cant encode unicode string to iso-8859-2

Initial Comment:
>>> import sys
>>> sys.getdefaultencoding()
'ISO8859-2'
>>> s = u"P��li&#353; &#382;lu�ou�k� k�� se napil &#382;lut� vody"
>>> s.encode("iso-8859-2")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  
File "/usr/local/lib/python2.2/encodings/iso8859_2.py",
 line 18, in encode
    return codecs.charmap_encode
(input,errors,encoding_map)
UnicodeError: charmap encoding error: character maps 
to <undefined>

But I used only chars from iso-8859-2. But If didn't 
use czech chars, encoding is successfull

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-16 17:25

Message:
Logged In: YES 
user_id=21627

You are confused about the meaning of Unicode literals. Even
though it might appear to you that the literal denotes
Latin-2 characters, Python has no way of knowing that the
bytes between the u" and the " are meant as Latin-2. So it
always takes them as Latin-1. This will be fixed with PEP 263.

However, once you constructed the string s, it is not
surprising that you cannot encode it: You did *not* use
characters from Latin-2, you've used characters from
Latin-1; some of those cannot be encoded in Latin-2, hence
the UnicodeError.

In Python 2.2, the proper solution is to avoid Unicode
literals, and use the unicode function to construct Unicode
strings:

s = unicode("your text", "latin-2")

So this is, strictly speaking, not a bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544609&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 17:00:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 09:00:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-544740 ] test_commands test fails under Cygwin
Message-ID: <E16xVO5-0000Ne-00@usw-sf-web1.sourceforge.net>

Bugs item #544740, was opened at 2002-04-16 08:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544740&group_id=5470

Category: None
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Jason Tishler (jlt63)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_commands test fails under Cygwin

Initial Comment:
The Python 2.2.1 test_commands regression test
fails under Cygwin 1.3.10 because the regular
expression is pickier now and because Cygwin can
have spaces in user and/or group names. See the
following for some more details:

http://cygwin.com/ml/cygwin/2002-04/msg00774.html

and a workaround.

I'm submitting this as a bug report instead of a
patch because I don't know the best way to fix
this issue.  Can test_commands use numeric IDs
instead of names?  Should I discuss this issue
on python-dev instead of here?

BTW, please add a "Test" category to the
available choices for Bugs.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544740&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 17:55:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 09:55:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-544647 ] Inplace multiply by float
Message-ID: <E16xWEp-0006If-00@usw-sf-web4.sourceforge.net>

Bugs item #544647, was opened at 2002-04-16 09:01
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544647&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jay T Miller (jaytmiller)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Inplace multiply by float

Initial Comment:
When I import the following from "example.py":

class test1(object):
   def __init__(self):
        object.__init__(self)

   def __imul__(self, other):
       print "no luck here!"

class test2:
   def __imul__(self, other):
       print "cool!"

t = test1()
u = test2()
t *= 1.0
u *= 1.0

The following happens:

Python 2.3a0 (#6, Apr 15 2002, 17:34:04)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-98)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import example
Traceback (most recent call last):
 File "<stdin>", line 1, in ?
 File "example.py", line 18, in ?
   t *= 1.0
TypeError: can't multiply sequence to non-int
>>>

I take this to mean that python does not (currently)
support inplace multiply by
floats for new style classes.  Is this a bug?  A
permanent limitation?

<speculation>
Looking into this a little, my impression was that the
problem is a result of two things:

1. PyNumber_InPlaceMultiply gives "priority" to
sequence behavior if it is defined (the slot is filled
in) in a C type.

PyObject *
PyNumber_InPlaceMultiply(PyObject *v, PyObject *w)
{
        PyObject * (*g)(PyObject *, int) = NULL;
        if (HASINPLACE(v) && v->ob_type->tp_as_sequence &&
                (g =
v->ob_type->tp_as_sequence->sq_inplace_repeat)) {
                long n;
                if (PyInt_Check(w)) {
                        n  = PyInt_AsLong(w);
                }
                else if (PyLong_Check(w)) {
                        n = PyLong_AsLong(w);
                        if (n == -1 && PyErr_Occurred())
                                return NULL;
                }
                else {
                        return type_error("can't
multiply sequence to non-int");
                }
                return (*g)(v, (int)n);
        }
        return binary_iop(v, w,
NB_SLOT(nb_inplace_multiply),
                                NB_SLOT(nb_multiply),
"*=");
}


2. New style classes define all or nearly all slots.  
This means that a new style class is both a sequence
and a number.
</speculation>

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-16 12:55

Message:
Logged In: YES 
user_id=6380

Fixed in current CVS (abstract.c 2.100). Also marked as
bugfix candidate for 2.2.2. Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544647&group_id=5470



From noreply@sourceforge.net  Tue Apr 16 23:10:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 15:10:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-541257 ] link to index.html from modindex.html
Message-ID: <E16xb9b-0007gg-00@usw-sf-web2.sourceforge.net>

Bugs item #541257, was opened at 2002-04-08 17:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Pending
Resolution: None
Priority: 5
Submitted By: Chris Liechti (cliechti)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: link to index.html from modindex.html

Initial Comment:
could you please link to "index.html" from modindex.html instead 
of just "./"?

other candidates are about.html and 
acks.html

this makes local-copy navigation better. if one has 
modindex bookmarked, the uparrow gives a filelisting instead of 
the document index :-(


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-16 18:10

Message:
Logged In: YES 
user_id=3066

What version of the documentation are you using?  The
current version seems to get this right already, but I might
be missing an instance that doesn't.

Marked as pending, waiting for submitter response.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 01:13:42 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 17:13:42 -0700
Subject: [Python-bugs-list] [ python-Bugs-541257 ] link to index.html from modindex.html
Message-ID: <E16xd4w-0000WV-00@usw-sf-web2.sourceforge.net>

Bugs item #541257, was opened at 2002-04-08 23:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Open
Resolution: None
Priority: 5
Submitted By: Chris Liechti (cliechti)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: link to index.html from modindex.html

Initial Comment:
could you please link to "index.html" from modindex.html instead 
of just "./"?

other candidates are about.html and 
acks.html

this makes local-copy navigation better. if one has 
modindex bookmarked, the uparrow gives a filelisting instead of 
the document index :-(


----------------------------------------------------------------------

>Comment By: Chris Liechti (cliechti)
Date: 2002-04-17 02:13

Message:
Logged In: YES 
user_id=403744

Python 2.2, Win32 HTML files shiped with the installer.

and it is 
indeed fixed in the "in-development" version (CSS) for the modindex, but 
there is a "./" left in about.html.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-17 00:10

Message:
Logged In: YES 
user_id=3066

What version of the documentation are you using?  The
current version seems to get this right already, but I might
be missing an instance that doesn't.

Marked as pending, waiting for submitter response.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 02:44:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 18:44:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-541257 ] link to index.html from modindex.html
Message-ID: <E16xeUs-0003mD-00@usw-sf-web3.sourceforge.net>

Bugs item #541257, was opened at 2002-04-08 17:45
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470

Category: Documentation
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Chris Liechti (cliechti)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: link to index.html from modindex.html

Initial Comment:
could you please link to "index.html" from modindex.html instead 
of just "./"?

other candidates are about.html and 
acks.html

this makes local-copy navigation better. if one has 
modindex bookmarked, the uparrow gives a filelisting instead of 
the document index :-(


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-16 21:44

Message:
Logged In: YES 
user_id=3066

Ok, fixed in Doc/html/about.html revisions 1.5, 1.3.24.1,
and 1.3.6.1.

----------------------------------------------------------------------

Comment By: Chris Liechti (cliechti)
Date: 2002-04-16 20:13

Message:
Logged In: YES 
user_id=403744

Python 2.2, Win32 HTML files shiped with the installer.

and it is 
indeed fixed in the "in-development" version (CSS) for the modindex, but 
there is a "./" left in about.html.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-16 18:10

Message:
Logged In: YES 
user_id=3066

What version of the documentation are you using?  The
current version seems to get this right already, but I might
be missing an instance that doesn't.

Marked as pending, waiting for submitter response.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=541257&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 05:17:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 21:17:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16xgsR-0005FT-00@usw-sf-web4.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 05:43:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 21:43:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16xhHY-0005ZX-00@usw-sf-web3.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 00:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-17 00:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 06:22:44 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 22:22:44 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E16xhu0-0000e4-00@usw-sf-web1.sourceforge.net>

Bugs item #457114, was opened at 2001-08-31 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-17 01:22

Message:
Logged In: YES 
user_id=116038

I'd be interested in integrating the two modules if no one
has tackled this yet. Seems like it would make a cool
feature.

I'm a little unclear on where you think the best integration
(and I'm a little new to the interpreter source :) ) point
would be - in the python module interface socket.py or the
lower level c interface socketmodule.c.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-05 16:46

Message:
Logged In: YES 
user_id=44345

While the offer is tempting, I almost certainly don't
understand the various bits associated with sockets and
don't have the time to learn them, so I'm unassigning.
Hopefully someone else will pick it up for 2.3...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:26

Message:
Logged In: YES 
user_id=6380

Skip, want to work on this? If not, please unassign it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 09:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 07:56:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 16 Apr 2002 23:56:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16xjMH-0006to-00@usw-sf-web4.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 16:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 14:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 09:49:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 01:49:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-545059 ] Internet Config -666 error
Message-ID: <E16xl8T-00087n-00@usw-sf-web4.sourceforge.net>

Bugs item #545059, was opened at 2002-04-17 10:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545059&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Internet Config -666 error

Initial Comment:
If IC can't find the extension->creator/type mapping for a file (and maybe the reverse too?) it raises a MacOS.Error -666. The value -666 isn't in the error string list (it's apparently not in the Apple header files, at least not the ones we parse). It should be added by hand, somehow, this error is rather common.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545059&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 13:14:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 05:14:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E16xoKY-0001ww-00@usw-sf-web4.sourceforge.net>

Bugs item #457114, was opened at 2001-08-31 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 08:14

Message:
Logged In: YES 
user_id=6380

Bernard Yue is considering to tackle this. See the thread in
python-dev starting at
http://mail.python.org/pipermail/python-dev/2002-April/023278.html
Maybe you two can work on this together?


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-17 01:22

Message:
Logged In: YES 
user_id=116038

I'd be interested in integrating the two modules if no one
has tackled this yet. Seems like it would make a cool
feature.

I'm a little unclear on where you think the best integration
(and I'm a little new to the interpreter source :) ) point
would be - in the python module interface socket.py or the
lower level c interface socketmodule.c.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-05 16:46

Message:
Logged In: YES 
user_id=44345

While the offer is tempting, I almost certainly don't
understand the various bits associated with sockets and
don't have the time to learn them, so I'm unassigning.
Hopefully someone else will pick it up for 2.3...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:26

Message:
Logged In: YES 
user_id=6380

Skip, want to work on this? If not, please unassign it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 09:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 13:35:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 05:35:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-545149 ] pydoc is said to be there since 2.1
Message-ID: <E16xoeM-0002KF-00@usw-sf-web3.sourceforge.net>

Bugs item #545149, was opened at 2002-04-17 14:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545149&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pydoc is said to be there since 2.1

Initial Comment:
Nothing much, I know, but let's try to keep the 
standard as high as possible. And it's easy to fix. 

http://www.python.org/doc/current/lib/module-
pydoc.html says that pydoc is there since Python2.1. 
Unless I'm mistaken, this module arrived in 2.2. 

Cheers,

Alexandre Fayolle

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545149&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 13:45:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 05:45:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-545149 ] pydoc is said to be there since 2.1
Message-ID: <E16xoo2-0008PS-00@usw-sf-web2.sourceforge.net>

Bugs item #545149, was opened at 2002-04-17 14:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545149&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
Resolution: None
>Priority: 1
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pydoc is said to be there since 2.1

Initial Comment:
Nothing much, I know, but let's try to keep the 
standard as high as possible. And it's easy to fix. 

http://www.python.org/doc/current/lib/module-
pydoc.html says that pydoc is there since Python2.1. 
Unless I'm mistaken, this module arrived in 2.2. 

Cheers,

Alexandre Fayolle

----------------------------------------------------------------------

>Comment By: Alexandre Fayolle (afayolle)
Date: 2002-04-17 14:45

Message:
Logged In: YES 
user_id=116727

Well sorry I am. Pydoc is there in python 2.1. The help() 
builtin function mentionned in the documentation is not 
there though (this one arrived in python2.2). And I could 
not find the doc for the pydoc module in the 2.1 
documentation, which added to my confusion. 

I'll try to close the bug (not sure if I can do that, since 
I'm not a developper on the project...)

Cheers,

Alexandre Fayolle

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545149&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 13:58:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 05:58:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-545149 ] pydoc is said to be there since 2.1
Message-ID: <E16xp0e-0008VM-00@usw-sf-web2.sourceforge.net>

Bugs item #545149, was opened at 2002-04-17 08:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545149&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Closed
Resolution: None
Priority: 1
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: pydoc is said to be there since 2.1

Initial Comment:
Nothing much, I know, but let's try to keep the 
standard as high as possible. And it's easy to fix. 

http://www.python.org/doc/current/lib/module-
pydoc.html says that pydoc is there since Python2.1. 
Unless I'm mistaken, this module arrived in 2.2. 

Cheers,

Alexandre Fayolle

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-17 08:58

Message:
Logged In: YES 
user_id=3066

I've added a version annotation to the description of the
help() function in Doc/lib/libfuncs.tex revisions 1.104 and
1.100.4.3.  I don't think adding a note in the pydoc
documentation that integration with the help() function was
in Python 2.2 is warrented, as pydoc is just an
implementation detail as far as help() is concerned.

----------------------------------------------------------------------

Comment By: Alexandre Fayolle (afayolle)
Date: 2002-04-17 08:45

Message:
Logged In: YES 
user_id=116727

Well sorry I am. Pydoc is there in python 2.1. The help() 
builtin function mentionned in the documentation is not 
there though (this one arrived in python2.2). And I could 
not find the doc for the pydoc module in the 2.1 
documentation, which added to my confusion. 

I'll try to close the bug (not sure if I can do that, since 
I'm not a developper on the project...)

Cheers,

Alexandre Fayolle

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545149&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 15:30:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 07:30:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-513572 ] isdir behavior getting odder on UNC path
Message-ID: <E16xqS8-0006PV-00@usw-sf-web1.sourceforge.net>

Bugs item #513572, was opened at 2002-02-06 13:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Mark Hammond (mhammond)
Summary: isdir behavior getting odder on UNC path

Initial Comment:
It's been documented in earlier version of Python on 
windows that os.path.isdir returns true on a UNC 
directory only if there was an extra backslash at the 
end of the argument.  In Python2.2 (at least on 
windows 2000) it appears that *TWO* extra backslashes 
are needed.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>>
>>> import os
>>> os.path.isdir('\\trainer\island')
0
>>> os.path.isdir('\\trainer\island\')
0
>>> os.path.isdir('\\trainer\island\\')
1
>>>

In a perfect world, the first call should return 1, 
but never has.  In older versions of python, the 
second returned 1, but no longer.

In limited tests, appending 2 or more backslashes to 
the end of any pathname returns the correct answer in 
both isfile and isdir.


----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 00:30

Message:
Logged In: YES 
user_id=14198

I have done a little analysis of how we use stat and how it
performs by instrumenting posixmodule.c.

It seems that Tim's concern about Python starup/import is
largely unfounded.  While Python does call stat() repeatedly
at startup, it does so from C rather than os.stat().  Thus,
starting and stopping Python yields the following (with my
instrumentation):

Success: 9    in 1.47592ms, avg 0.164
Failure: 2    in 0.334504ms, avg 0.1673

(ie, os.stat() is called with a valid file 9 times, and
invalid file twice.  Average time for stat() is 0.16ms per
call.)

python -c "import os, string, httplib, urllib"
shows the same results (ie, no extra stats for imports)

However, this is not the typical case.  The Python test
suite  (which takes ~110 seconds wall time on my PC) yields
the following:

Success: 383  in 84.3571ms, avg 0.2203
Failure: 1253 in 3805.52ms, avg 3.037

egads - 4 seconds spent in failed stat calls, averaging 3ms
each!!  Further instrumentation shows that stat() can be
very slow on directories with many files.  In this case,
os.stat() in the %TEMP% directory for tempfiles()
occasionally took extremely long.

OK - so assuming this tempfile behaviour is also not
"typical", I tried the COM test suite:

Success: 972  in 303.856ms, avg 0.3126
Failure: 16   in 2.60549ms, avg 0.1628

(also with some extremely long times on files that did exist
in a directory with many files)

So - all this implies to me that:
* stat() can be quite slow in some cases, success or failure
* We probably shouldn't make this twice as long in every
case that fails!

So, I am moving back to trying to outguess the stat()
implementation.  Looking at it shows that indeed UNC roots
are treated specially along with the root directory case
already handled by Python (courtesy of Tim).  Adding an
extra check for a UNC root shouldn't be too hard, and can't
possibly be as expensive as an extra stat() :)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-05 11:51

Message:
Logged In: YES 
user_id=31435

Nice to see you, Mark!  If you want to pursue this, the 
caution I had about my idea, but forgot to write down, is 
that Python does lots of stats during imports, and 
especially stats on things that usually don't exist (is it 
there with a .pyd suffix?  a .dll suffix?  a .py suffix?  
a .pyw suffix?  a .pyc suffix?).  If the idea has a bad 
effect on startup time, that may kill it; startup time is 
already a sore point for some.  OTOH, on Windows we should 
really, say, be using FindFirstFile() with a wildcard 
extension for that purpose anyway.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-05 10:46

Message:
Logged In: YES 
user_id=14198

Sorry - I missed this bug.  It is not that I wasn't paying
attention, but rather that SF's Tracker didn't get my
attention :(  Have I mentioned how much I have SF and love
Bugzilla yet? :)

I quite like Tim's algorithm.  One extra stat in that case
is OK IMO.  I can't imagine too many speed sensitive bits of
code that continuously check for a non-existent directory.

Everyone still OK with that?

----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2002-04-05 04:08

Message:
Logged In: YES 
user_id=34892

I have struggled with this too. Currently I tend to use 
this _isdir(). Hopefully this is helpful.

def _isdir(dirname):
    """os.path.isdir() doesn't work for UNC mount points. 
Fake it.
    
    # For an existing mount point
    # (want: _isdir() == 1)
    os.path.ismount(r"\crimper\apps") -> 1
    os.path.exists(r"\crimper\apps") -> 0
    os.path.isdir(r"\crimper\apps") -> 0
    os.listdir(r"\crimper\apps") -> [...contents...]
    # For a non-existant mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\foo") -> 1
    os.path.exists(r"\crimper\foo") -> 0
    os.path.isdir(r"\crimper\foo") -> 0
    os.listdir(r"\crimper\foo") -> WindowsError
    # For an existing dir under a mount point
    # (want: _isdir() == 1)
    os.path.mount(r"\crimper\apps\Komodo") -> 0
    os.path.exists(r"\crimper\apps\Komodo") -> 1
    os.path.isdir(r"\crimper\apps\Komodo") -> 1
    os.listdir(r"\crimper\apps\Komodo") -> [...contents...]
    # For a non-existant dir/file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\foo") -> 0
    os.path.exists(r"\crimper\apps\foo") -> 0
    os.path.isdir(r"\crimper\apps\foo") -> 0
    os.listdir(r"\crimper\apps\foo") -> []  # as if empty 
contents
    # For an existing file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\Komodo\exists.txt") -> 
0
    os.path.exists(r"\crimper\apps\Komodo\exists.txt") -> 1
    os.path.isdir(r"\crimper\apps\Komodo\exists.txt") -> 0
    os.listdir(r"\crimper\apps\Komodo\exists.txt") -> 
WindowsError
    """
    if sys.platform[:3] == 'win' and dirname[:2] == r'\':
        if os.path.exists(dirname):
            return os.path.isdir(dirname)
        try:
            os.listdir(dirname)
        except WindowsError:
            return 0
        else:
            return os.path.ismount(dirname)
    else:
        return os.path.isdir(dirname)



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 20:03

Message:
Logged In: YES 
user_id=31435

Gordon, none of those are UNC roots -- they follow the 
rules exactly as stated for non-UNC paths:  MS stat() 
recognizes \ME\E\java if and only if there's no trailing 
backslash.  That's why your first example succeeds.  The 
complication is that Python removes one trailing 
backslash "by magic" unless the path "looks like a root", 
and none of these do.  That's why your third example 
works.  Your second and fourth examples fail because you 
specified two trailing backslashes in those, and Python 
only removes one of them by magic.

An example of "a UNC root" would be \ME\E.  The MS stat() 
recognizes a root directory if and only if it *does* have a 
trailing backslash, and Python's magical backslash removal 
doesn't know UNC roots from a Euro symbol.  So the only way 
to get Python's isdir() (etc) to recognize \ME\E is to 
follow it with two backslashes, one because Python strips 
one away (due to not realizing "it looks like a root"), and 
another else MS stat() refuses to recognize it.

Anyway, I'm unassigning this now, cuz MarkH isn't paying 
any attentino.  If someone wants to write a pile of tedious 
code to "recognize a UNC root when it sees one", I'd accept 
the patch.  I doubt I'll get it to it myself in this 
lifetime.

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-08 02:31

Message:
Logged In: YES 
user_id=4923

Data point:
 run on a win2k box, where \ME is an NT box
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.isdir(r"\ME\E\java")
1
>>> os.path.isdir(r"\ME\E\java\")
0
>>> os.path.isdir("\\ME\E\java\")
1
>>> os.path.isdir("\\ME\E\java\\")
0


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 19:28

Message:
Logged In: YES 
user_id=31435

Mark, what do you think about a different approach here?

1. Leave the string alone and *try* stat.  If it   
succeeds, great, we're done.

2. Else if the string doesn't have a trailing (back)slash, 
append one and try again.  Win or lose, that's the end.

3. Else the string does have a trailing (back)slash.  If 
the string has more than one character, strip a trailing 
(back)slash and try again.  Win or lose, that's the end.

4. Else the string is a single (back)slash, yet stat() 
failed.  This shouldn't be possible.

It doubles the number of stats in cases where the file path 
doesn't correspond to anything that exists.  OTOH, MS's 
(back)slash rules are undocumented and incomprehensible 
(read their implementation of stat() for the whole truth -- 
we're not out-thinking lots of it now, and the gimmick 
added after 1.5.2 to out-think part of it is at least 
breaking Gary's thoroughly sensible use).

----------------------------------------------------------------------

Comment By: Gary Herron (herron)
Date: 2002-02-11 19:03

Message:
Logged In: YES 
user_id=395736

Sorry, but I don't have much of an idea which versions I 
was refering to.  I picked up the idea of an extra 
backslashes in a faq from a web site, the search for which 
I can't seem to reproduce.  It claimed one backslash was 
enough, but did not specify a python version.  It *might* 
have been old enough to be pre 1.5.2.
 
The two versions I can test are 1.5.1 (where one backslash 
is enough) and 2.2 (where two are required).  This seems 
to me to support (or at least not contradict) Tim's 
hypothesis.

Gary


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 05:57

Message:
Logged In: YES 
user_id=31435

Gary, exactly what do you mean by "older versions of 
Python"?  That is, specifically which versions?

The Microsoft stat() function is extremely picky about 
trailing (back)slashes.  For example, if you have a 
directory c:/python, and pass "c:/python/" to the MS stat
(), it claims no such thing exists.  This isn't documented 
by MS, but that's how it works:  a trailing (back)slash is 
required if and only if the path passed in "is a root".  So 
MS stat() doesn't understand "/python/", and doesn't 
understand "d:" either.  The former doesn't tolerate a 
(back)slash, while the latter requires one.

This is impossible for people to keep straight, so after 
1.5.2 Python started removing (back)slashes on its own to 
make MS stat() happy.  The code currently leaves a trailing 
(back)slash alone if and only if one exists, and in 
addition of these obtains:

1) The (back)slash is the only character in the path.
or
2) The path has 3 characters, and the middle one is a colon.

UNC roots don't fit either of those, so do get one (back)
slash chopped off.  However, just as for any other roots, 
the MS stat() refuses to recognize them as valid unless 
they do have a trailing (back)slash.  Indeed, the last time 
I applied a contributed patch to this code, I added a

/* XXX UNC root drives should also be exempted? */

comment there.

However, this explanation doesn't make sense unless by 
"older versions of Python" you mean nothing more recent 
than 1.5.2.  If I'm understanding the source of the 
problem, it should exist in all Pythons after 1.5.2.  So if 
you don't see the same problem in 1.6, 2.0 or 2.1, I'm on 
the wrong track.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-09 10:33

Message:
Logged In: YES 
user_id=31435

BTW, it occurs to me that this *may* be a consequence of 
whatever was done in 2.2 to encode/decode filename strings 
for system calls on Windows.  I didn't follow that, and 
Mark may be the only one who fully understands the details.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-09 10:17

Message:
Logged In: YES 
user_id=31435

Here's the implementation of Windows isdir():

def isdir(path):
.    """Test whether a path is a directory"""
.    try:
.        st = os.stat(path)
.    except os.error:
.        return 0
.    return stat.S_ISDIR(st[stat.ST_MODE])

That is, we return whatever Microsoft's stat() tells us, 
and our code is the same in 2.2 as in 2.1.  I don't have 
Win2K here, and my Win98 box isn't on a Windows network so 
I can't even try real UNC paths here.  Reassigning to MarkH 
in case he can do better on either count.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-09 09:05

Message:
Logged In: YES 
user_id=6380

Tim, I hate to do this to you, but you're the only person I
trust with researching this. (My laptop is currently off the
net again. :-( )


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 16:32:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 08:32:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E16xrQF-00079V-00@usw-sf-web1.sourceforge.net>

Bugs item #457114, was opened at 2001-08-31 00:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-04-17 10:32

Message:
Logged In: YES 
user_id=44345

Check the python-dev mailing list archive for the past few
days.  There is an active thread about this topic.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 07:14

Message:
Logged In: YES 
user_id=6380

Bernard Yue is considering to tackle this. See the thread in
python-dev starting at
http://mail.python.org/pipermail/python-dev/2002-April/023278.html
Maybe you two can work on this together?


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-17 00:22

Message:
Logged In: YES 
user_id=116038

I'd be interested in integrating the two modules if no one
has tackled this yet. Seems like it would make a cool
feature.

I'm a little unclear on where you think the best integration
(and I'm a little new to the interpreter source :) ) point
would be - in the python module interface socket.py or the
lower level c interface socketmodule.c.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-05 15:46

Message:
Logged In: YES 
user_id=44345

While the offer is tempting, I almost certainly don't
understand the various bits associated with sockets and
don't have the time to learn them, so I'm unassigning.
Hopefully someone else will pick it up for 2.3...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 13:26

Message:
Logged In: YES 
user_id=6380

Skip, want to work on this? If not, please unassign it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 08:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470



From noreply@sourceforge.net  Wed Apr 17 23:09:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 15:09:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-545388 ] walk() walks aliases
Message-ID: <E16xxc2-00060F-00@usw-sf-web2.sourceforge.net>

Bugs item #545388, was opened at 2002-04-17 17:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545388&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Jack Jansen (jackjansen)
Summary: walk() walks aliases

Initial Comment:
>> macpath.walk() (or actually os.path.walk) is 
explicitly define *not* to
>> do special things for symlinks or aliases. But 
still: the functionality
>> is nice, so maybe we should put it in a new 
function macostools.walk.
>
> By "special things" you don't mean that walk() is 
suppose to skip over
> aliases, do you?

Yes, that's what I mean. Do I understand from your 
comment that it walks 
aliases? That would be a bug, please file it at 
sourceforge.


-----

I am just filing the above correspondence as a 
reminder that walk() in macpath walks aliases.

/c

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545388&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 00:15:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 16:15:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-545410 ] corefile: python 2.1.3, zope 2.5.0
Message-ID: <E16xydu-0006i9-00@usw-sf-web2.sourceforge.net>

Bugs item #545410, was opened at 2002-04-17 23:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Gerrietts (ggerrietts)
Assigned to: Nobody/Anonymous (nobody)
Summary: corefile: python 2.1.3, zope 2.5.0

Initial Comment:
I regularly get a corefile out of Zope 2.5.0, running
on RedHat 6.2 and Python 2.1.3, usually within 5 or 6
page views.

Reproducing the problem requires (for me) starting up
Zope, going to the management interface, and bouncing
around on a few of the different objects. Sometimes the
first attempt to render the page will cause a crash,
but sometimes it takes a few clicks. After the crash,
Zope dumps core and politely restarts itself.

Traceback files are largely the same from one crash to
the next, with the only variation I've noted being the
addresses of variables -- this fits with the fact that
it takes a different number of steps each time.

Traceback files (infuriatingly enough) do not show line
number information for select.so, even though
selectmodule.o was compiled with -g specified.

Examination of the traceback shows that in stack frame
2, print ((PyCFunctionObject *)func) -> m_ml -> ml_name
reveals "select". In that same frame, print ((PyObject
*)arg) -> ob_type -> tp_name yields "Cannot  access
memory at address 0x1f".

One traceback has been provided. Others, and other
info, available on request.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 00:47:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 16:47:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-545425 ] No output from extension modules
Message-ID: <E16xz8v-00017Z-00@usw-sf-web3.sourceforge.net>

Bugs item #545425, was opened at 2002-04-18 01:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545425&group_id=5470

Category: IDLE
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Bienstman (pbienst)
Assigned to: Nobody/Anonymous (nobody)
Summary: No output from extension modules

Initial Comment:
When running a python script calling a C extension 
module under IDLE, any output the C code generates to 
stdout is not displayed in the interactive window, at 
least not on Windows.

Running the same code from the command line works 
fine.

This happens even with the simplest 'Hello world' 
module.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545425&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 01:19:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 17:19:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-542984 ] allow use of descriptors for __doc_ attr
Message-ID: <E16xzdt-0001Uu-00@usw-sf-web4.sourceforge.net>

Bugs item #542984, was opened at 2002-04-12 09:18
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470

Category: Type/class unification
>Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Guido van Rossum (gvanrossum)
Summary: allow use of descriptors for __doc_ attr

Initial Comment:
In bug #504343, I proposed a patch that made the
__doc__ attribute of new style types to things other
than strings.  That bug was about unicode doc strings,
but my main aim was to use a descriptor for __doc__
(the original bug I submitted was #507394, which got
marked as a dup).

The patch I proposed in that bug turned out to cause
some problems for pydoc in another bit of code, as
documented in bug #530070 (specifically, getting the
help for __builtin__.property).

The patch on that bug broke things again, so that my
classes (which were non heap type classes defined in
extension modules) started returning None when trying
to get the documentation, because their tp_doc slot was
NULL (they had a __doc__ in the type dict though).

Additionally, for heap type classes, it appears that it
won't call the tp_descr_get slot of the __doc__ object
found in the module dictionary, so you end up getting
the descriptor itself :(

The sample program attached to bug #507394 (my first
one on this topic) demonstrates part of the problem. 
With the current 2.2.1 candidate, for NewClass.__doc__,
it returns the descriptor object itself.

A translation of the type and descriptor to a C
extension would demonstrate the problem in the non heap
type case (I haven't written this test case yet).  The
development releases of pygtk can act as a test case
though (running "import gtk; print gtk.Widget.__doc__").

Maybe the best fix would be to get pydoc to handle non
string __doc__ by running str() on it, and ignoring the
docstring if an exception occurs during the conversion.
 This would allow display of some unicode docstrings
provided they could be represented in the system
codeset (if you are using a utf8 system encoding, all
unicode strings should be representable).

I would like to see this working okay for python 2.2.1,
but if the change is too big, maybe it could be moved
out to python 2.3.  I would like to see this issue
considered.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 20:19

Message:
Logged In: YES 
user_id=6380

After some email exchanged with James, I've decided to check
something in that does what he wants, makes Martin's example
work, and doesn't break property.__doc__, without having to
change the property implementation.

Coming soon to a CVS HEAD near you.  I'll check this into
the 2.2 maint branch too.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:38

Message:
Logged In: YES 
user_id=6380

I like Martin's summary better. :-)

Some remarks: 

- property.__doc__ works fine, it's
property.__dict__['__doc__'] that behaves strange (but
nobody should care)

- I can't get help() to break by setting __doc__ = 42 on
either an old or a new class

- I think I'd rather not lose the __doc__ descriptor in
type, but I can make it look for __dict__['__doc__'] first,
*and* call that if it appears a descriptor.

I'll post a patch here once I've had breakfast.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-15 07:09

Message:
Logged In: YES 
user_id=21627

I would summarize this differently: For the attached
descr.py, Python currently prints in the third line

NewClass.__doc__   = <__main__.DocDescr object at 0x1094d0>

James requests that it prints

NewClass.__doc__   = 'object=None    type=NewClass'

instead.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-15 00:12

Message:
Logged In: YES 
user_id=146903

Okay.  Here is a summary of the story so far:

I am working on the bindings for the GTK 2.0 gui toolkit. 
Gtk widgets can have properties (basically a combination of
the name, type, some documentation and getters/setters;
similar to python), and signals (part of gtk's notification
framework).

I wanted to provide documentation on the signals and
properties of each widget, and putting them in the __doc__
attribute seemed natural.  As information on the properties
and signals can be read via gtk's introspection APIs, it
seemed natural to want to generate this documentation at
runtime.

Now gtk tries to delay initialisation as much as possible
(classes are only initialised on first use).  So generating
documentation for every class on module initialisation would
mean initialising every class in gtk, which is a fairly big
speed hit I don't want to incur -- especially since online
documentation is mainly used during development.

This is why I wanted to use a descriptor -- so that the
signal and property documentation only gets generated when
the user asks for it.

Unfortunately this didn't work in python 2.2, as the
type.__doc__ member descriptor (which returns tp_doc) would
take precedence over the __doc__ attribute in the class itself.

To me, this seemed like a needless difference between new
and old style classes.  My initial patch made __doc__ act
more like the old style classes by getting rid of the
type.__doc__ descriptor and getting PyType_Ready to set
__doc__ appropriately from tp_doc, if it hadn't already been
set.

This allowed me to use descriptors to generate
signal/property documentation, and also allowed other non
string __doc__ attributes (such as unicode strings).

This fix was applied to head and the 2.2 branch but
unfortunately, it also caused pydoc to raise an exception
when displaying the documentation for __builtin__.property,
as its __doc__ attribute was now being returned when you
asked for property.__doc__ (rather than the type.__doc__
descriptor taking precedence and returning tp_doc).

property.__doc__ is a descriptor which returns a string for
property instances, but returns itself in the class context
(ie. getting property.__doc__).  As this is not a string or
unicode string, pydoc gets an error.

The fix (again, checked into both head and 2.2 branches)
that was checked in added a __doc__ descriptor again.  This
descriptor returns tp_doc for non heap type classes, and
looks up __doc__ in the class dictionary for heap type classes.

This causes problems for both heap and non heap classes: for
non heap classes, __doc__ in the class dict is never
accessed.  For heap classes, the tp_descr_get method of
__doc__ is never called.

Here is my prefered way to fix the problem (which you may
disagree with):

1. remove the type.__doc__ descriptor again

2. make the property.__doc__ descriptor return something
meaningful in the class context

3. make pydoc handle non string-like __doc__ attributes
better (either ignoring them or converting them to strings).
 Currently I can get help() to error out with a simple class
like:
    class foo:
        __doc__ = 42

(I am not saying that people should use integers as __doc__;
just that pydoc should handle things like this more gracefully).


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-14 20:31

Message:
Logged In: YES 
user_id=6380

James, can you please explain the problem again, but without
referring to other existing patches?  With all the
references to pydoc, inspect, properties, descriptors, other
patches and SF bug reports I have completely lost the trail,
and I don't think it's productive for me to try and gather
all the separate bits together.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 11:29

Message:
Logged In: YES 
user_id=21627

This is not (primarily) a pydoc issue: with your change,
property.__doc__ gets changed. pydoc could ignore the object
returned, but then property would have no documentation at
all - even though there is a tp_doc in it. So I don't see
any easy solution. If you do, please attach a patch for the
current CVS (we can then decide whether to backport it to
2.2.2).

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 11:06

Message:
Logged In: YES 
user_id=146903

Maybe getting pydoc to ignore any __doc__ attributes (that
is, what gets returned by getattr) that weren't strings or
unicode would work.

As for using a different metatype, a reason for getting this
into the the standard metatype is that it is also an
inconsistency between how new and old style classes act, and
is fairly easy to reconcile (granted descriptors didn't
exist in python < 2.2, but everytime new style classes act a
bit differently, people seem to start submitting pygtk bug
reports).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 10:33

Message:
Logged In: YES 
user_id=21627

Also, if you want to have types with computed doc strings,
couldn't you use a different metatype?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-12 10:23

Message:
Logged In: YES 
user_id=21627

Invoking str() on all doc strings has been considered and
rejected; it is desirable that Unicode doc strings come out
as-is.

I'm not sure what kind of patch you are suggesting; if I
merely revert typeobject.c 2.130 (i.e. removing the
type.__doc__ getter), then property.__doc__ will not be the
doc string of property, but the __doc__ member. This is
undesirable.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 09:39

Message:
Logged In: YES 
user_id=146903

damn.  I was on the plane back from GUADEC then and am still
catching up with things :(  Sorry about that.

----------------------------------------------------------------------

Comment By: James Henstridge (jhenstridge)
Date: 2002-04-12 09:37

Message:
Logged In: YES 
user_id=146903

Here is a patch for inspect.py that fixes the bug reported
in #530070 without breaking the use of descriptors for
__doc__.  I think this patch would be a good candidate for
2.2.1 (along with backing out the patch on #530070).

I am sorry that I didn't bring this up earlier -- I hadn't
realised there was any other patches to the __doc__ handling
in the 2.2 maintenance branch.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-12 09:35

Message:
Logged In: YES 
user_id=6656

James, Python 2.2.1 was released two days ago.  Nothing can
change that now...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=542984&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 01:25:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 17:25:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-545436 ] py-execute-string doesn't work
Message-ID: <E16xzjv-0001ZU-00@usw-sf-web4.sourceforge.net>

Bugs item #545436, was opened at 2002-04-17 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry Warsaw (bwarsaw)
Summary: py-execute-string doesn't work

Initial Comment:
The python-mode function py-execute-string appears 
not to work.  In XEmacs 21.4.6 I executed

    M-x py-execute-string
    print "hello world"

and got a "No output." message.

Stepping through the code using edebug it appears 
that in py-execute-region the local variable cmd
(right after the "horrible hack" comment) is set to
the empty string.  I think it's because that chunk
of code uses buffer-local info to determine what
command to run.  Executing py-execute-region from
a fundamental-mode buffer also fails.  Executing
python-mode and then running it again succeeds.

Adding

	(if (equal cmd "")
	    (setq cmd "python"))

right after cmd is set seems to make things work
regardless of the buffer's mode.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 02:03:31 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 18:03:31 -0700
Subject: [Python-bugs-list] [ python-Bugs-545446 ] cPickle problem with sockets (Windows)
Message-ID: <E16y0Kh-0001xk-00@usw-sf-web4.sourceforge.net>

Bugs item #545446, was opened at 2002-04-17 21:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545446&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Muller (mikemuller)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle problem with sockets (Windows)

Initial Comment:
[someone found this bug in using one of my projects
(DOPY), I can not recreate it myself since I don't run
Windows.  I am reporting it second-hand based on having
narrowed it down to this via e-mail]

Apparently, under some circumstances when a socket
stream closes in Windows, a cPickle.Unpickler that is
reading from the stream reads a garbage character and
attempts to interpret it as a key, raising
"cPickle.UnpicklingError: invalid load key ' '" instead
of EOFError.

This behavior has been reproduced on both Windows 98SE
and Windows 2000.  It does not happen when the client
and server are running on the same computer.  It has
been observed to occur with the server running on
Windows and the client running on Linux.

The following server and client scripts can be used to
reproduce it:

server.py:
  import cPickle
  import socket

  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
  s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
  s.bind(('', 9600))
  s.listen(5)
  c, addr = s.accept()

  src = cPickle.Unpickler(c.makefile('r'))

  first = src.load()

  # should raise EOFError
  try:
     second = src.load()
  except EOFError:
     pass

client.py:
  import cPickle
  import socket, sys

  s = socket.socket(socket.AF  _INET,
socket.SOCK_STREAM, 0)
  s.connect((sys.argv[1], 9600))

  dst = s.makefile('w')

  # send just one item
  cPickle.Pickler(dst).dump(100)

Note that this error does not occur with "pickle", only
cPickle.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545446&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 02:07:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 18:07:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16y0Op-0001uI-00@usw-sf-web3.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 00:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
>Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-17 21:07

Message:
Logged In: YES 
user_id=31435

Mark, looks good to me, but I'd really like to see someone 
on Linux dig into this too.  Is this an ancient bug that 
just never surfaced before?  Or does it have something to 
do with moving to zlib 1.1.4 on Windows?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 02:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 00:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 02:10:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 18:10:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-513572 ] isdir behavior getting odder on UNC path
Message-ID: <E16y0RH-0007rk-00@usw-sf-web2.sourceforge.net>

Bugs item #513572, was opened at 2002-02-05 21:07
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Gary Herron (herron)
Assigned to: Mark Hammond (mhammond)
Summary: isdir behavior getting odder on UNC path

Initial Comment:
It's been documented in earlier version of Python on 
windows that os.path.isdir returns true on a UNC 
directory only if there was an extra backslash at the 
end of the argument.  In Python2.2 (at least on 
windows 2000) it appears that *TWO* extra backslashes 
are needed.

Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>>
>>> import os
>>> os.path.isdir('\\trainer\island')
0
>>> os.path.isdir('\\trainer\island\')
0
>>> os.path.isdir('\\trainer\island\\')
1
>>>

In a perfect world, the first call should return 1, 
but never has.  In older versions of python, the 
second returned 1, but no longer.

In limited tests, appending 2 or more backslashes to 
the end of any pathname returns the correct answer in 
both isfile and isdir.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-17 21:10

Message:
Logged In: YES 
user_id=31435

Sounds good to me!  I agree it shouldn't be all that hard 
to special-case UNC roots too -- what I wonder about is how 
many other forms of "root" syntax MS will make up out of 
thin air next year <wink>.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 10:30

Message:
Logged In: YES 
user_id=14198

I have done a little analysis of how we use stat and how it
performs by instrumenting posixmodule.c.

It seems that Tim's concern about Python starup/import is
largely unfounded.  While Python does call stat() repeatedly
at startup, it does so from C rather than os.stat().  Thus,
starting and stopping Python yields the following (with my
instrumentation):

Success: 9    in 1.47592ms, avg 0.164
Failure: 2    in 0.334504ms, avg 0.1673

(ie, os.stat() is called with a valid file 9 times, and
invalid file twice.  Average time for stat() is 0.16ms per
call.)

python -c "import os, string, httplib, urllib"
shows the same results (ie, no extra stats for imports)

However, this is not the typical case.  The Python test
suite  (which takes ~110 seconds wall time on my PC) yields
the following:

Success: 383  in 84.3571ms, avg 0.2203
Failure: 1253 in 3805.52ms, avg 3.037

egads - 4 seconds spent in failed stat calls, averaging 3ms
each!!  Further instrumentation shows that stat() can be
very slow on directories with many files.  In this case,
os.stat() in the %TEMP% directory for tempfiles()
occasionally took extremely long.

OK - so assuming this tempfile behaviour is also not
"typical", I tried the COM test suite:

Success: 972  in 303.856ms, avg 0.3126
Failure: 16   in 2.60549ms, avg 0.1628

(also with some extremely long times on files that did exist
in a directory with many files)

So - all this implies to me that:
* stat() can be quite slow in some cases, success or failure
* We probably shouldn't make this twice as long in every
case that fails!

So, I am moving back to trying to outguess the stat()
implementation.  Looking at it shows that indeed UNC roots
are treated specially along with the root directory case
already handled by Python (courtesy of Tim).  Adding an
extra check for a UNC root shouldn't be too hard, and can't
possibly be as expensive as an extra stat() :)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-04 20:51

Message:
Logged In: YES 
user_id=31435

Nice to see you, Mark!  If you want to pursue this, the 
caution I had about my idea, but forgot to write down, is 
that Python does lots of stats during imports, and 
especially stats on things that usually don't exist (is it 
there with a .pyd suffix?  a .dll suffix?  a .py suffix?  
a .pyw suffix?  a .pyc suffix?).  If the idea has a bad 
effect on startup time, that may kill it; startup time is 
already a sore point for some.  OTOH, on Windows we should 
really, say, be using FindFirstFile() with a wildcard 
extension for that purpose anyway.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-04 19:46

Message:
Logged In: YES 
user_id=14198

Sorry - I missed this bug.  It is not that I wasn't paying
attention, but rather that SF's Tracker didn't get my
attention :(  Have I mentioned how much I have SF and love
Bugzilla yet? :)

I quite like Tim's algorithm.  One extra stat in that case
is OK IMO.  I can't imagine too many speed sensitive bits of
code that continuously check for a non-existent directory.

Everyone still OK with that?

----------------------------------------------------------------------

Comment By: Trent Mick (tmick)
Date: 2002-04-04 13:08

Message:
Logged In: YES 
user_id=34892

I have struggled with this too. Currently I tend to use 
this _isdir(). Hopefully this is helpful.

def _isdir(dirname):
    """os.path.isdir() doesn't work for UNC mount points. 
Fake it.
    
    # For an existing mount point
    # (want: _isdir() == 1)
    os.path.ismount(r"\crimper\apps") -> 1
    os.path.exists(r"\crimper\apps") -> 0
    os.path.isdir(r"\crimper\apps") -> 0
    os.listdir(r"\crimper\apps") -> [...contents...]
    # For a non-existant mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\foo") -> 1
    os.path.exists(r"\crimper\foo") -> 0
    os.path.isdir(r"\crimper\foo") -> 0
    os.listdir(r"\crimper\foo") -> WindowsError
    # For an existing dir under a mount point
    # (want: _isdir() == 1)
    os.path.mount(r"\crimper\apps\Komodo") -> 0
    os.path.exists(r"\crimper\apps\Komodo") -> 1
    os.path.isdir(r"\crimper\apps\Komodo") -> 1
    os.listdir(r"\crimper\apps\Komodo") -> [...contents...]
    # For a non-existant dir/file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\foo") -> 0
    os.path.exists(r"\crimper\apps\foo") -> 0
    os.path.isdir(r"\crimper\apps\foo") -> 0
    os.listdir(r"\crimper\apps\foo") -> []  # as if empty 
contents
    # For an existing file under a mount point
    # (want: _isdir() == 0)
    os.path.ismount(r"\crimper\apps\Komodo\exists.txt") -> 
0
    os.path.exists(r"\crimper\apps\Komodo\exists.txt") -> 1
    os.path.isdir(r"\crimper\apps\Komodo\exists.txt") -> 0
    os.listdir(r"\crimper\apps\Komodo\exists.txt") -> 
WindowsError
    """
    if sys.platform[:3] == 'win' and dirname[:2] == r'\':
        if os.path.exists(dirname):
            return os.path.isdir(dirname)
        try:
            os.listdir(dirname)
        except WindowsError:
            return 0
        else:
            return os.path.ismount(dirname)
    else:
        return os.path.isdir(dirname)



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 04:03

Message:
Logged In: YES 
user_id=31435

Gordon, none of those are UNC roots -- they follow the 
rules exactly as stated for non-UNC paths:  MS stat() 
recognizes \ME\E\java if and only if there's no trailing 
backslash.  That's why your first example succeeds.  The 
complication is that Python removes one trailing 
backslash "by magic" unless the path "looks like a root", 
and none of these do.  That's why your third example 
works.  Your second and fourth examples fail because you 
specified two trailing backslashes in those, and Python 
only removes one of them by magic.

An example of "a UNC root" would be \ME\E.  The MS stat() 
recognizes a root directory if and only if it *does* have a 
trailing backslash, and Python's magical backslash removal 
doesn't know UNC roots from a Euro symbol.  So the only way 
to get Python's isdir() (etc) to recognize \ME\E is to 
follow it with two backslashes, one because Python strips 
one away (due to not realizing "it looks like a root"), and 
another else MS stat() refuses to recognize it.

Anyway, I'm unassigning this now, cuz MarkH isn't paying 
any attentino.  If someone wants to write a pile of tedious 
code to "recognize a UNC root when it sees one", I'd accept 
the patch.  I doubt I'll get it to it myself in this 
lifetime.

----------------------------------------------------------------------

Comment By: Gordon B. McMillan (gmcm)
Date: 2002-03-07 10:31

Message:
Logged In: YES 
user_id=4923

Data point:
 run on a win2k box, where \ME is an NT box
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit 
(Intel)] on win32
>>> os.path.isdir(r"\ME\E\java")
1
>>> os.path.isdir(r"\ME\E\java\")
0
>>> os.path.isdir("\\ME\E\java\")
1
>>> os.path.isdir("\\ME\E\java\\")
0


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 03:28

Message:
Logged In: YES 
user_id=31435

Mark, what do you think about a different approach here?

1. Leave the string alone and *try* stat.  If it   
succeeds, great, we're done.

2. Else if the string doesn't have a trailing (back)slash, 
append one and try again.  Win or lose, that's the end.

3. Else the string does have a trailing (back)slash.  If 
the string has more than one character, strip a trailing 
(back)slash and try again.  Win or lose, that's the end.

4. Else the string is a single (back)slash, yet stat() 
failed.  This shouldn't be possible.

It doubles the number of stats in cases where the file path 
doesn't correspond to anything that exists.  OTOH, MS's 
(back)slash rules are undocumented and incomprehensible 
(read their implementation of stat() for the whole truth -- 
we're not out-thinking lots of it now, and the gimmick 
added after 1.5.2 to out-think part of it is at least 
breaking Gary's thoroughly sensible use).

----------------------------------------------------------------------

Comment By: Gary Herron (herron)
Date: 2002-02-11 03:03

Message:
Logged In: YES 
user_id=395736

Sorry, but I don't have much of an idea which versions I 
was refering to.  I picked up the idea of an extra 
backslashes in a faq from a web site, the search for which 
I can't seem to reproduce.  It claimed one backslash was 
enough, but did not specify a python version.  It *might* 
have been old enough to be pre 1.5.2.
 
The two versions I can test are 1.5.1 (where one backslash 
is enough) and 2.2 (where two are required).  This seems 
to me to support (or at least not contradict) Tim's 
hypothesis.

Gary


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-10 13:57

Message:
Logged In: YES 
user_id=31435

Gary, exactly what do you mean by "older versions of 
Python"?  That is, specifically which versions?

The Microsoft stat() function is extremely picky about 
trailing (back)slashes.  For example, if you have a 
directory c:/python, and pass "c:/python/" to the MS stat
(), it claims no such thing exists.  This isn't documented 
by MS, but that's how it works:  a trailing (back)slash is 
required if and only if the path passed in "is a root".  So 
MS stat() doesn't understand "/python/", and doesn't 
understand "d:" either.  The former doesn't tolerate a 
(back)slash, while the latter requires one.

This is impossible for people to keep straight, so after 
1.5.2 Python started removing (back)slashes on its own to 
make MS stat() happy.  The code currently leaves a trailing 
(back)slash alone if and only if one exists, and in 
addition of these obtains:

1) The (back)slash is the only character in the path.
or
2) The path has 3 characters, and the middle one is a colon.

UNC roots don't fit either of those, so do get one (back)
slash chopped off.  However, just as for any other roots, 
the MS stat() refuses to recognize them as valid unless 
they do have a trailing (back)slash.  Indeed, the last time 
I applied a contributed patch to this code, I added a

/* XXX UNC root drives should also be exempted? */

comment there.

However, this explanation doesn't make sense unless by 
"older versions of Python" you mean nothing more recent 
than 1.5.2.  If I'm understanding the source of the 
problem, it should exist in all Pythons after 1.5.2.  So if 
you don't see the same problem in 1.6, 2.0 or 2.1, I'm on 
the wrong track.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 18:33

Message:
Logged In: YES 
user_id=31435

BTW, it occurs to me that this *may* be a consequence of 
whatever was done in 2.2 to encode/decode filename strings 
for system calls on Windows.  I didn't follow that, and 
Mark may be the only one who fully understands the details.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-08 18:17

Message:
Logged In: YES 
user_id=31435

Here's the implementation of Windows isdir():

def isdir(path):
.    """Test whether a path is a directory"""
.    try:
.        st = os.stat(path)
.    except os.error:
.        return 0
.    return stat.S_ISDIR(st[stat.ST_MODE])

That is, we return whatever Microsoft's stat() tells us, 
and our code is the same in 2.2 as in 2.1.  I don't have 
Win2K here, and my Win98 box isn't on a Windows network so 
I can't even try real UNC paths here.  Reassigning to MarkH 
in case he can do better on either count.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-08 17:05

Message:
Logged In: YES 
user_id=6380

Tim, I hate to do this to you, but you're the only person I
trust with researching this. (My laptop is currently off the
net again. :-( )


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513572&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 02:13:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 18:13:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16y0UH-0007tS-00@usw-sf-web2.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Andrew Bennetts (spiv)
Date: 2002-04-18 11:13

Message:
Logged In: YES 
user_id=50945

Tim, I'm using Debian's 1.1.4 on Linux, but Linux is working
fine (perhaps you misread my bug report, which was rather
terse?).  The example I gave segfaults on Windows 2000.  It
should instead raise a zlib.error, which it does on Linux. 
The docs say that you cannot do anything useful with a
compressobj opened in mode Z_FINISH (the default) after
calling flush, so the zlib.error is expected.

I can't test Mark's patch, but at a glance it looks good.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 11:07

Message:
Logged In: YES 
user_id=31435

Mark, looks good to me, but I'd really like to see someone 
on Linux dig into this too.  Is this an ancient bug that 
just never surfaced before?  Or does it have something to 
do with moving to zlib 1.1.4 on Windows?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 16:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 14:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 02:29:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 18:29:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16y0jb-00083d-00@usw-sf-web2.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 11:29

Message:
Logged In: YES 
user_id=14198

Oh ye of little faith <wink>

Looks to me like a Python CVS problem.  My Linux build also 
crashes:

Python 2.3a0 (#13, Apr  6 2002, 13:45:37)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-79)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()
Segmentation fault (core dumped)

My patch also fixes it :)

A quick scan of CVS shows the following checkin responsible:

----------------------------
Revision : 2.49
Date : 2001/10/16 23:2:32
Author : 'jhylton'
State : 'Exp'
Lines : +115 -169
Description :
Simplify and fix error handling for most cases.


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-04-18 11:13

Message:
Logged In: YES 
user_id=50945

Tim, I'm using Debian's 1.1.4 on Linux, but Linux is working
fine (perhaps you misread my bug report, which was rather
terse?).  The example I gave segfaults on Windows 2000.  It
should instead raise a zlib.error, which it does on Linux. 
The docs say that you cannot do anything useful with a
compressobj opened in mode Z_FINISH (the default) after
calling flush, so the zlib.error is expected.

I can't test Mark's patch, but at a glance it looks good.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 11:07

Message:
Logged In: YES 
user_id=31435

Mark, looks good to me, but I'd really like to see someone 
on Linux dig into this too.  Is this an ancient bug that 
just never surfaced before?  Or does it have something to 
do with moving to zlib 1.1.4 on Windows?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 16:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 14:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 02:36:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 18:36:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16y0qB-0005A1-00@usw-sf-web1.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 00:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Nobody/Anonymous (nobody)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-17 21:36

Message:
Logged In: YES 
user_id=31435

Andrew, right, I understood the bug report.  The question 
I'm wondering about is why you don't see a problem on 
Linux, because the code Mark patched has nothing to do with 
Windows specifically.  Your bug report didn't say which 
version of zlib you were using, so that was a possibly 
relevant difference -- turns out it wasn't.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 21:29

Message:
Logged In: YES 
user_id=14198

Oh ye of little faith <wink>

Looks to me like a Python CVS problem.  My Linux build also 
crashes:

Python 2.3a0 (#13, Apr  6 2002, 13:45:37)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-79)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()
Segmentation fault (core dumped)

My patch also fixes it :)

A quick scan of CVS shows the following checkin responsible:

----------------------------
Revision : 2.49
Date : 2001/10/16 23:2:32
Author : 'jhylton'
State : 'Exp'
Lines : +115 -169
Description :
Simplify and fix error handling for most cases.


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-04-17 21:13

Message:
Logged In: YES 
user_id=50945

Tim, I'm using Debian's 1.1.4 on Linux, but Linux is working
fine (perhaps you misread my bug report, which was rather
terse?).  The example I gave segfaults on Windows 2000.  It
should instead raise a zlib.error, which it does on Linux. 
The docs say that you cannot do anything useful with a
compressobj opened in mode Z_FINISH (the default) after
calling flush, so the zlib.error is expected.

I can't test Mark's patch, but at a glance it looks good.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 21:07

Message:
Logged In: YES 
user_id=31435

Mark, looks good to me, but I'd really like to see someone 
on Linux dig into this too.  Is this an ancient bug that 
just never surfaced before?  Or does it have something to 
do with moving to zlib 1.1.4 on Windows?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 02:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 00:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 02:37:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 18:37:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16y0rI-0005Am-00@usw-sf-web1.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 00:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
>Assigned to: Jeremy Hylton (jhylton)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-17 21:37

Message:
Logged In: YES 
user_id=31435

Good show, Mark!  Assigning to Jeremy.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 21:36

Message:
Logged In: YES 
user_id=31435

Andrew, right, I understood the bug report.  The question 
I'm wondering about is why you don't see a problem on 
Linux, because the code Mark patched has nothing to do with 
Windows specifically.  Your bug report didn't say which 
version of zlib you were using, so that was a possibly 
relevant difference -- turns out it wasn't.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 21:29

Message:
Logged In: YES 
user_id=14198

Oh ye of little faith <wink>

Looks to me like a Python CVS problem.  My Linux build also 
crashes:

Python 2.3a0 (#13, Apr  6 2002, 13:45:37)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-79)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()
Segmentation fault (core dumped)

My patch also fixes it :)

A quick scan of CVS shows the following checkin responsible:

----------------------------
Revision : 2.49
Date : 2001/10/16 23:2:32
Author : 'jhylton'
State : 'Exp'
Lines : +115 -169
Description :
Simplify and fix error handling for most cases.


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-04-17 21:13

Message:
Logged In: YES 
user_id=50945

Tim, I'm using Debian's 1.1.4 on Linux, but Linux is working
fine (perhaps you misread my bug report, which was rather
terse?).  The example I gave segfaults on Windows 2000.  It
should instead raise a zlib.error, which it does on Linux. 
The docs say that you cannot do anything useful with a
compressobj opened in mode Z_FINISH (the default) after
calling flush, so the zlib.error is expected.

I can't test Mark's patch, but at a glance it looks good.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 21:07

Message:
Logged In: YES 
user_id=31435

Mark, looks good to me, but I'd really like to see someone 
on Linux dig into this too.  Is this an ancient bug that 
just never surfaced before?  Or does it have something to 
do with moving to zlib 1.1.4 on Windows?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 02:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 00:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 03:18:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 19:18:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-545446 ] cPickle problem with sockets (Windows)
Message-ID: <E16y1Uw-0002jc-00@usw-sf-web4.sourceforge.net>

Bugs item #545446, was opened at 2002-04-18 01:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545446&group_id=5470

>Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Michael Muller (mikemuller)
Assigned to: Nobody/Anonymous (nobody)
Summary: cPickle problem with sockets (Windows)

Initial Comment:
[someone found this bug in using one of my projects
(DOPY), I can not recreate it myself since I don't run
Windows.  I am reporting it second-hand based on having
narrowed it down to this via e-mail]

Apparently, under some circumstances when a socket
stream closes in Windows, a cPickle.Unpickler that is
reading from the stream reads a garbage character and
attempts to interpret it as a key, raising
"cPickle.UnpicklingError: invalid load key ' '" instead
of EOFError.

This behavior has been reproduced on both Windows 98SE
and Windows 2000.  It does not happen when the client
and server are running on the same computer.  It has
been observed to occur with the server running on
Windows and the client running on Linux.

The following server and client scripts can be used to
reproduce it:

server.py:
  import cPickle
  import socket

  s = socket.socket(socket.AF_INET, socket.SOCK_STREAM, 0)
  s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
  s.bind(('', 9600))
  s.listen(5)
  c, addr = s.accept()

  src = cPickle.Unpickler(c.makefile('r'))

  first = src.load()

  # should raise EOFError
  try:
     second = src.load()
  except EOFError:
     pass

client.py:
  import cPickle
  import socket, sys

  s = socket.socket(socket.AF  _INET,
socket.SOCK_STREAM, 0)
  s.connect((sys.argv[1], 9600))

  dst = s.makefile('w')

  # send just one item
  cPickle.Pickler(dst).dump(100)

Note that this error does not occur with "pickle", only
cPickle.

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-18 02:18

Message:
Logged In: YES 
user_id=35752

Duplicate of #523020.  Already fixed in CVS.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545446&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 03:19:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 19:19:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-459160 ] Py closes COM instances not loaded by Py
Message-ID: <E16y1Wa-0002kY-00@usw-sf-web4.sourceforge.net>

Bugs item #459160, was opened at 2001-09-06 23:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459160&group_id=5470

Category: Windows
Group: Python 2.1.1
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Mark Hammond (mhammond)
Summary: Py closes COM instances not loaded by Py

Initial Comment:
I have a script using win32com. An instance of a COM 
object is loaded. As part of the load, the server 
loads an instance of another com object. The server 
has a get property returning the IDisp of the server 
loaded object. In a def, the get property is used 
thus:- ocp.Msg1001.Data where, ocp is the Python loaded
ocject and Msg1001 is the serverloaded object. As soon 
as the def ends, Python garbage collects ocp.Msg1001 
rendering it unusable. If I create a variable in 
__main of ocp.Msg1001, all is well.

The problem is caused by the fact that Python cannot 
tell between a com instance it created and one it has 
been passed. 

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 12:19

Message:
Logged In: YES 
user_id=14198

I am afraid I can't understand this.  What I do understand 
seems to be working correctly.  There is no email address 
where I can get further information.

Anonymous - please either add a bug in the ActivePython bug 
database (please include sample code) or mail me directly.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-09-07 16:07

Message:
Logged In: YES 
user_id=31435

Reassigned to Mark.  Anonymous, you should really report 
this to ActiveState instead (the SourceForge Python project 
doesn't supply the Win32 extensions).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=459160&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 06:09:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 22:09:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-544473 ] Queue module can deadlock
Message-ID: <E16y4Ax-0007G5-00@usw-sf-web1.sourceforge.net>

Bugs item #544473, was opened at 2002-04-15 22:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Queue module can deadlock

Initial Comment:
Prompted by a users experimentation where he was able
to show Pythonwin hanging, I have found a case where
the Queue module deadlocks.  It appears that if a
RuntimeError is generated while queueing data, the
queue lock will remain held.

Attaching a test script.  This hangs on Win2k and
Linux.  Win2k callstack shows Queue is waiting for the
following lock (line 53)

        if block:
            self.fsema.acquire()

Presumably (but untested at the moment), the previous
call to q.put(), which triggered a "RuntimeError:
maximum recursion depth exceeded", left the lock acquired.

It seems a few choice try/finally statements in the
Queue module would go along way :)  I will try and get
to this soon.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-18 01:09

Message:
Logged In: YES 
user_id=31435

The patch looks good to me, but I would like to see a test 
case.  Note that you can build a reliable test case by 
subclassing Queue and overriding its _put and/or _get 
methods, arranging to raise an exception deliberately from 
them.  Any exception in these would leave a semaphore and 
self.mutex held forever in the current Queue.py.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-16 08:18

Message:
Logged In: YES 
user_id=14198

This patch seems reasonable to me.  Tim, a quick look would 
be appreciated.  Writing a reasonable test case seems 
difficult :(  It doesn't seem worth adding this little test 
script to the test suite.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-15 22:47

Message:
Logged In: YES 
user_id=31435

Yup, it hangs on Win98 too.  Nice job of whittling it down, 
Mark!  We've been looking for an excuse to make Queue 
slower too <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 06:44:47 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 22:44:47 -0700
Subject: [Python-bugs-list] [ python-Bugs-545410 ] corefile: python 2.1.3, zope 2.5.0
Message-ID: <E16y4it-0004n5-00@usw-sf-web4.sourceforge.net>

Bugs item #545410, was opened at 2002-04-18 01:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Gerrietts (ggerrietts)
Assigned to: Nobody/Anonymous (nobody)
Summary: corefile: python 2.1.3, zope 2.5.0

Initial Comment:
I regularly get a corefile out of Zope 2.5.0, running
on RedHat 6.2 and Python 2.1.3, usually within 5 or 6
page views.

Reproducing the problem requires (for me) starting up
Zope, going to the management interface, and bouncing
around on a few of the different objects. Sometimes the
first attempt to render the page will cause a crash,
but sometimes it takes a few clicks. After the crash,
Zope dumps core and politely restarts itself.

Traceback files are largely the same from one crash to
the next, with the only variation I've noted being the
addresses of variables -- this fits with the fact that
it takes a different number of steps each time.

Traceback files (infuriatingly enough) do not show line
number information for select.so, even though
selectmodule.o was compiled with -g specified.

Examination of the traceback shows that in stack frame
2, print ((PyCFunctionObject *)func) -> m_ml -> ml_name
reveals "select". In that same frame, print ((PyObject
*)arg) -> ob_type -> tp_name yields "Cannot  access
memory at address 0x1f".

One traceback has been provided. Others, and other
info, available on request.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-18 07:44

Message:
Logged In: YES 
user_id=21627

In that backtrace, it is clear that arg in stackframe 2 is
bogus: 0x405d7ffc points into an area that appears to be
used for shared libraries (please do "info shared" to
support this theory).

Now, arg presumably is the return value of load_args, where
it was created through PyTuple_New. This suggests that the
memory management got corrupted; something that likely
happened much earlier.

I recommend to set MALLOC_CHECK_ before starting Python. The
documentation in malloc(3) says that setting it to 2 will
cause an abort() when an error is found; from expecting the
implementation, it appears that setting it to 3 will combine
the debug traces printed and the call to abort; please
experiment with all three values (1,2,3).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 06:49:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 22:49:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-545425 ] No output from extension modules
Message-ID: <E16y4n9-0004qL-00@usw-sf-web4.sourceforge.net>

Bugs item #545425, was opened at 2002-04-18 01:47
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545425&group_id=5470

Category: IDLE
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Peter Bienstman (pbienst)
Assigned to: Nobody/Anonymous (nobody)
Summary: No output from extension modules

Initial Comment:
When running a python script calling a C extension 
module under IDLE, any output the C code generates to 
stdout is not displayed in the interactive window, at 
least not on Windows.

Running the same code from the command line works 
fine.

This happens even with the simplest 'Hello world' 
module.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-18 07:49

Message:
Logged In: YES 
user_id=21627

That is not a bug: Python does not replace the C library;
printf does whatever the C library thinks it should do.

If you want to write to sys.stdout, use PySys_WriteStdout.

To see your printf output on Windows in IDLE, try starting
IDLE from a console window (whether this helps or not
depends on the Windows version).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545425&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 07:38:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 23:38:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E16y5Yo-0002Tb-00@usw-sf-web2.sourceforge.net>

Bugs item #216388, was opened at 2000-10-09 11:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
Resolution: Later
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 16:38

Message:
Logged In: YES 
user_id=29957

Hm. This no longer produces the above error. However, it
now produces:
>>> import cStringIO 
>>> s=cStringIO.StringIO(u"abcdefgh") 
>>> s.getvalue()
'a\x00b\x00c\x00d\x00e\x00f\x00g\x00h\x00'

Should it produce a unicode string back? 
(thought I'd go through some of the older sf bugs)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-04 21:18

Message:
Logged In: NO 

9;lo;;99999999999999999999999

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-02 09:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-17 13:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-11 03:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-08 14:56

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-13 08:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 19:34

Message:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 07:47:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 17 Apr 2002 23:47:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions
Message-ID: <E16y5hN-0005MY-00@usw-sf-web3.sourceforge.net>

Bugs item #413582, was opened at 2001-04-04 10:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: g++ must be called for c++ extensions

Initial Comment:
When building c++ extension using distutils setup,
the compiler that was used to build python distribution
is always called. On Linux, it is normally gcc.
When gcc is called to link shared library, it does not
link certain c++ runtime stuff. As a result, when
extension is imported, missing symbols are reported,
e.g.:
>>> import ex_ext1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./ex_ext1.so: undefined symbol:
__vt_13runtime_error
>>>
I tried to use "extra_link_args = ['-x c++']" in
setup.py (it tells gcc to link as c++), but that gets
added to the end of compiler's command line, which
results in:
gcc -shared build/temp.linux-i686-2.1/ex_ext1.o
-L../boost/libs/python -lboost_python -o
build/lib.linux-i686-2.1/ex_ext1.so -x c++
gcc: Warning: `-x  c++' after last input file has no
effect

Proposed solution: either use CXX= variable from Python
Makefile when c++ files are involved, or prepend
extra_link_args to compiler's arguments instead of
appending them.


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 16:47

Message:
Logged In: YES 
user_id=29957

can this be closed as a duplicate of 454030? That one
has a real submitter, and some more info...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-11 01:51

Message:
Logged In: YES 
user_id=6380

Assigning this to Andrew, who is the current distutils
maintainer.


----------------------------------------------------------------------

Comment By: Andrei Tovtchigretchko (andreitd)
Date: 2001-04-05 10:23

Message:
Logged In: YES 
user_id=189208

Follow-up:
If I link with a static library (-lboost_python is
libboost_python.a in bug post example), the problem shows.
If I link with shared c++ library (libboost_python.so),
everything is ok.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 08:40:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 00:40:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-514433 ] bsddb: enable dbopen (file==NULL)
Message-ID: <E16y6X1-0000QU-00@usw-sf-web1.sourceforge.net>

Bugs item #514433, was opened at 2002-02-08 06:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514433&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Sam Rushing (rushing)
>Assigned to: Anthony Baxter (anthonybaxter)
Summary: bsddb: enable dbopen (file==NULL)

Initial Comment:
dbopen(): if the file argument is NULL, the library 
will use a temporary file.  this is useful if you want 
that, or if you want to specify a large cache so that 
it never actually touches the disk. [i.e., in-memory 
hash/bt]
I've done this by replacing the "s" with a "z" in the 
arg specs for the three open functions.  Seems to work.

-Sam


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 17:40

Message:
Logged In: YES 
user_id=29957

see patch #545523

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-09 08:49

Message:
Logged In: YES 
user_id=6380

Can you submit a patch to the patch manager?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514433&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 12:28:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 04:28:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-545600 ] IDLE doesn't save 8bit files
Message-ID: <E16yA5T-0000LS-00@usw-sf-web4.sourceforge.net>

Bugs item #545600, was opened at 2002-04-18 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE doesn't save 8bit files

Initial Comment:
This bug seems to be related to #527022. 

Short version is: IDLE won't save files containing 8bit
characters (for instance in comments or in litteral
strings). No error dialog is displayed, only a
traceback on stderr or in the interactive window if
it's available:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.1/lib-tk/Tkinter.py", line
1285, in __call__
    return apply(self.func, args)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
126, in save
    self.save_as(event)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
136, in save_as
    if self.writefile(filename):
  File "/usr/lib/idle-python2.1/IOBinding.py", line
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in
range(128)

Possible solution:

 * at least warn the user that the file could not be
saved with an error dialog
 * try using the locale to guess the encoding and do
appropriate conversions
 * ask the user wich encoding should be used to save
the file

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 12:30:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 04:30:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-544473 ] Queue module can deadlock
Message-ID: <E16yA7C-00009R-00@usw-sf-web3.sourceforge.net>

Bugs item #544473, was opened at 2002-04-16 12:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Queue module can deadlock

Initial Comment:
Prompted by a users experimentation where he was able
to show Pythonwin hanging, I have found a case where
the Queue module deadlocks.  It appears that if a
RuntimeError is generated while queueing data, the
queue lock will remain held.

Attaching a test script.  This hangs on Win2k and
Linux.  Win2k callstack shows Queue is waiting for the
following lock (line 53)

        if block:
            self.fsema.acquire()

Presumably (but untested at the moment), the previous
call to q.put(), which triggered a "RuntimeError:
maximum recursion depth exceeded", left the lock acquired.

It seems a few choice try/finally statements in the
Queue module would go along way :)  I will try and get
to this soon.



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 21:30

Message:
Logged In: YES 
user_id=14198

Good idea re subclassing to provoke the deadlock!  Attaching
the exact same Queue.py patch, plus a reasonable test case -
both blocking and non-blocking gets and puts are tested in
the succeeding and failing cases.  Without the Queue.py
patch, both Linux and Windows deadlock in the tests.  With
the patch, both succeed.  If no objections I will check it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 15:09

Message:
Logged In: YES 
user_id=31435

The patch looks good to me, but I would like to see a test 
case.  Note that you can build a reliable test case by 
subclassing Queue and overriding its _put and/or _get 
methods, arranging to raise an exception deliberately from 
them.  Any exception in these would leave a semaphore and 
self.mutex held forever in the current Queue.py.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-16 22:18

Message:
Logged In: YES 
user_id=14198

This patch seems reasonable to me.  Tim, a quick look would 
be appreciated.  Writing a reasonable test case seems 
difficult :(  It doesn't seem worth adding this little test 
script to the test suite.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-16 12:47

Message:
Logged In: YES 
user_id=31435

Yup, it hangs on Win98 too.  Nice job of whittling it down, 
Mark!  We've been looking for an excuse to make Queue 
slower too <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 13:53:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 05:53:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E16yBQF-0000Oo-00@usw-sf-web2.sourceforge.net>

Bugs item #216388, was opened at 2000-10-08 20:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
>Resolution: Remind
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-18 08:53

Message:
Logged In: YES 
user_id=6380

Hm, that's bad. An error on write(u"...") is much preferred
over wreiting garbage. :-(

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 02:38

Message:
Logged In: YES 
user_id=29957

Hm. This no longer produces the above error. However, it
now produces:
>>> import cStringIO 
>>> s=cStringIO.StringIO(u"abcdefgh") 
>>> s.getvalue()
'a\x00b\x00c\x00d\x00e\x00f\x00g\x00h\x00'

Should it produce a unicode string back? 
(thought I'd go through some of the older sf bugs)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-04 06:18

Message:
Logged In: NO 

9;lo;;99999999999999999999999

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-16 21:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-10 11:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-07 22:56

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 16:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 04:34

Message:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 13:55:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 05:55:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-413582 ] g++ must be called for c++ extensions
Message-ID: <E16yBRE-0001CB-00@usw-sf-web3.sourceforge.net>

Bugs item #413582, was opened at 2001-04-03 20:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: A.M. Kuchling (akuchling)
Summary: g++ must be called for c++ extensions

Initial Comment:
When building c++ extension using distutils setup,
the compiler that was used to build python distribution
is always called. On Linux, it is normally gcc.
When gcc is called to link shared library, it does not
link certain c++ runtime stuff. As a result, when
extension is imported, missing symbols are reported,
e.g.:
>>> import ex_ext1
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ImportError: ./ex_ext1.so: undefined symbol:
__vt_13runtime_error
>>>
I tried to use "extra_link_args = ['-x c++']" in
setup.py (it tells gcc to link as c++), but that gets
added to the end of compiler's command line, which
results in:
gcc -shared build/temp.linux-i686-2.1/ex_ext1.o
-L../boost/libs/python -lboost_python -o
build/lib.linux-i686-2.1/ex_ext1.so -x c++
gcc: Warning: `-x  c++' after last input file has no
effect

Proposed solution: either use CXX= variable from Python
Makefile when c++ files are involved, or prepend
extra_link_args to compiler's arguments instead of
appending them.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-18 08:55

Message:
Logged In: YES 
user_id=6380

reassigned to amk who should know

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 02:47

Message:
Logged In: YES 
user_id=29957

can this be closed as a duplicate of 454030? That one
has a real submitter, and some more info...


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-04-10 11:51

Message:
Logged In: YES 
user_id=6380

Assigning this to Andrew, who is the current distutils
maintainer.


----------------------------------------------------------------------

Comment By: Andrei Tovtchigretchko (andreitd)
Date: 2001-04-04 20:23

Message:
Logged In: YES 
user_id=189208

Follow-up:
If I link with a static library (-lboost_python is
libboost_python.a in bug post example), the problem shows.
If I link with shared c++ library (libboost_python.so),
everything is ok.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=413582&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 14:52:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 06:52:21 -0700
Subject: [Python-bugs-list] [ python-Bugs-545655 ] cannot save buffer
Message-ID: <E16yCKj-0004j8-00@usw-sf-web1.sourceforge.net>

Bugs item #545655, was opened at 2002-04-18 13:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545655&group_id=5470

Category: Tkinter
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Didier (dalais_dj)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot save buffer

Initial Comment:
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python21\lib\lib-tk\Tkinter.py", line 1285, 
in __call__
    return apply(self.func, args)
  File "C:\Python21\Tools\idle\IOBinding.py", line 
126, in save
    self.save_as(event)
  File "C:\Python21\Tools\idle\IOBinding.py", line 
136, in save_as
    if self.writefile(filename):
  File "C:\Python21\Tools\idle\IOBinding.py", line 
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in 
range(128)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545655&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 17:08:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 09:08:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16yESw-0007B7-00@usw-sf-web2.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 14:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 11:08

Message:
Logged In: YES 
user_id=366473

On Mac OS X which is also a BSD derivative the mode argument to mkdir()is completely ignored.  This becomes more of an issue when makedirs() is used because a simple chmod (which does work) is not sufficient if multiple directories were created.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 18:50

Message:
Logged In: YES 
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 18:40:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 10:40:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16yFtP-0004fl-00@usw-sf-web4.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 14:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-18 13:40

Message:
Logged In: YES 
user_id=12800

It's also quite inconvenient for cross platform portability
because now you have to either always call os.chmod()
everytime you call os.mkdir(), or replace os.mkdir() with a
function that does that (so all call sites, even in library
modules actually DTRT).

IWBNI Python's default os.mkdir() provided that cross
platform compatibility.


----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 12:08

Message:
Logged In: YES 
user_id=366473

On Mac OS X which is also a BSD derivative the mode argument to mkdir()is completely ignored.  This becomes more of an issue when makedirs() is used because a simple chmod (which does work) is not sufficient if multiple directories were created.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 18:50

Message:
Logged In: YES 
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 19:04:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 11:04:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16yGGh-0004g1-00@usw-sf-web3.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 21:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2002-04-18 20:04

Message:
Logged In: YES 
user_id=92689

For the record: I cannot reproduce what dgrassi
reports; the mod argument to os.mkdir() works for
me on MacOSX.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-18 19:40

Message:
Logged In: YES 
user_id=12800

It's also quite inconvenient for cross platform portability
because now you have to either always call os.chmod()
everytime you call os.mkdir(), or replace os.mkdir() with a
function that does that (so all call sites, even in library
modules actually DTRT).

IWBNI Python's default os.mkdir() provided that cross
platform compatibility.


----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 18:08

Message:
Logged In: YES 
user_id=366473

On Mac OS X which is also a BSD derivative the mode argument to mkdir()is completely ignored.  This becomes more of an issue when makedirs() is used because a simple chmod (which does work) is not sufficient if multiple directories were created.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 01:50

Message:
Logged In: YES 
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 19:20:53 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 11:20:53 -0700
Subject: [Python-bugs-list] [ python-Bugs-544473 ] Queue module can deadlock
Message-ID: <E16yGWb-00058k-00@usw-sf-web4.sourceforge.net>

Bugs item #544473, was opened at 2002-04-15 22:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470

Category: Python Library
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Queue module can deadlock

Initial Comment:
Prompted by a users experimentation where he was able
to show Pythonwin hanging, I have found a case where
the Queue module deadlocks.  It appears that if a
RuntimeError is generated while queueing data, the
queue lock will remain held.

Attaching a test script.  This hangs on Win2k and
Linux.  Win2k callstack shows Queue is waiting for the
following lock (line 53)

        if block:
            self.fsema.acquire()

Presumably (but untested at the moment), the previous
call to q.put(), which triggered a "RuntimeError:
maximum recursion depth exceeded", left the lock acquired.

It seems a few choice try/finally statements in the
Queue module would go along way :)  I will try and get
to this soon.



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-18 14:20

Message:
Logged In: YES 
user_id=31435

Changed to Accepted to encourage you to check it in <wink>.

Note that expected-output files are not *required* for 
tests anymore, and indeed are discouraged.  Better to print 
purely informational msgs under a

if test_support.verbose:
    print "yadda, yadda"

guard, and not create any expected-output file.

In the checkin msg(s), be sure to say this is a "bugfix 
candidate" patch.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 07:30

Message:
Logged In: YES 
user_id=14198

Good idea re subclassing to provoke the deadlock!  Attaching
the exact same Queue.py patch, plus a reasonable test case -
both blocking and non-blocking gets and puts are tested in
the succeeding and failing cases.  Without the Queue.py
patch, both Linux and Windows deadlock in the tests.  With
the patch, both succeed.  If no objections I will check it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 01:09

Message:
Logged In: YES 
user_id=31435

The patch looks good to me, but I would like to see a test 
case.  Note that you can build a reliable test case by 
subclassing Queue and overriding its _put and/or _get 
methods, arranging to raise an exception deliberately from 
them.  Any exception in these would leave a semaphore and 
self.mutex held forever in the current Queue.py.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-16 08:18

Message:
Logged In: YES 
user_id=14198

This patch seems reasonable to me.  Tim, a quick look would 
be appreciated.  Writing a reasonable test case seems 
difficult :(  It doesn't seem worth adding this little test 
script to the test suite.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-15 22:47

Message:
Logged In: YES 
user_id=31435

Yup, it hangs on Win98 too.  Nice job of whittling it down, 
Mark!  We've been looking for an excuse to make Queue 
slower too <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 20:28:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 12:28:40 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16yHaC-0005fn-00@usw-sf-web3.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Walter D�rwald (doerwalter)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-18 21:28

Message:
Logged In: YES 
user_id=89016

I have a patch ready that implements the unicode version, 
and the mixed versions, i.e. str.strip(unicode) and 
unicode.strip(str), but CVS doesn't like me today.

Maybe tomorrow!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-13 04:43

Message:
Logged In: YES 
user_id=3066

(I'd say this is a good reason not to use separate trackers
for features, bugs, & patches -- they're too closely related
to keep them separate, and links between them too tedious
when written only in tracker comments!)

I've updated the documentation for these methods in
Doc/lib/libstdtypes.tex revision 1.87.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-13 03:02

Message:
Logged In: YES 
user_id=6380

Oops, I saw your remark too late.

I've checked in my own version of this for regular
strings...

Feel free to check in your version of this for Unicode
strings, and the docs etc.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 17:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 16:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 11:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 10:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 09:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 23:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 21:23:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 13:23:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16yIRb-0006Jj-00@usw-sf-web3.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 14:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 15:23

Message:
Logged In: YES 
user_id=366473

Indeed MAC OS X mkdir() is correct, it abides by umask.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-04-18 13:04

Message:
Logged In: YES 
user_id=92689

For the record: I cannot reproduce what dgrassi
reports; the mod argument to os.mkdir() works for
me on MacOSX.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-18 12:40

Message:
Logged In: YES 
user_id=12800

It's also quite inconvenient for cross platform portability
because now you have to either always call os.chmod()
everytime you call os.mkdir(), or replace os.mkdir() with a
function that does that (so all call sites, even in library
modules actually DTRT).

IWBNI Python's default os.mkdir() provided that cross
platform compatibility.


----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 11:08

Message:
Logged In: YES 
user_id=366473

On Mac OS X which is also a BSD derivative the mode argument to mkdir()is completely ignored.  This becomes more of an issue when makedirs() is used because a simple chmod (which does work) is not sufficient if multiple directories were created.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 18:50

Message:
Logged In: YES 
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Thu Apr 18 23:22:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 15:22:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-545855 ] Wrong exception from re.compile()
Message-ID: <E16yKIi-0000VK-00@usw-sf-web2.sourceforge.net>

Bugs item #545855, was opened at 2002-04-18 18:22
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545855&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Fredrik Lundh (effbot)
Summary: Wrong exception from re.compile()

Initial Comment:
re.compile('foo[a-') raises a TypeError exception
instead of re.error.

Python 2.2.1 (#1, Apr  4 2002, 17:22:15) 
[GCC 2.96 20000731 (Mandrake Linux 8.2 2.96-0.76mdk)]
on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import re
>>> re.compile('foo[a-')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/lib/python2.2/sre.py", line 178, in
compile
    return _compile(pattern, flags)
  File "/usr/local/lib/python2.2/sre.py", line 226, in
_compile
    p = sre_compile.compile(pattern, flags)
  File "/usr/local/lib/python2.2/sre_compile.py", line
430, in compile
    p = sre_parse.parse(p, flags)
  File "/usr/local/lib/python2.2/sre_parse.py", line
623, in parse
    p = _parse_sub(source, pattern, 0)
  File "/usr/local/lib/python2.2/sre_parse.py", line
318, in _parse_sub
    items.append(_parse(source, state))
  File "/usr/local/lib/python2.2/sre_parse.py", line
424, in _parse
    if this[0] == "\":
TypeError: unsubscriptable object


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545855&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 01:12:51 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 17:12:51 -0700
Subject: [Python-bugs-list] [ python-Bugs-544473 ] Queue module can deadlock
Message-ID: <E16yM1D-0000Xt-00@usw-sf-web4.sourceforge.net>

Bugs item #544473, was opened at 2002-04-16 12:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: Queue module can deadlock

Initial Comment:
Prompted by a users experimentation where he was able
to show Pythonwin hanging, I have found a case where
the Queue module deadlocks.  It appears that if a
RuntimeError is generated while queueing data, the
queue lock will remain held.

Attaching a test script.  This hangs on Win2k and
Linux.  Win2k callstack shows Queue is waiting for the
following lock (line 53)

        if block:
            self.fsema.acquire()

Presumably (but untested at the moment), the previous
call to q.put(), which triggered a "RuntimeError:
maximum recursion depth exceeded", left the lock acquired.

It seems a few choice try/finally statements in the
Queue module would go along way :)  I will try and get
to this soon.



----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-19 10:12

Message:
Logged In: YES 
user_id=14198

Checking in Queue.py;
/cvsroot/python/python/dist/src/Lib/Queue.py,v  <--  Queue.py
new revision: 1.15; previous revision: 1.14
Checking in test/test_queue.py;
/cvsroot/python/python/dist/src/Lib/test/test_queue.py,v 
<--  test_queue.py
initial revision: 1.1

bugfix candidate.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-19 04:20

Message:
Logged In: YES 
user_id=31435

Changed to Accepted to encourage you to check it in <wink>.

Note that expected-output files are not *required* for 
tests anymore, and indeed are discouraged.  Better to print 
purely informational msgs under a

if test_support.verbose:
    print "yadda, yadda"

guard, and not create any expected-output file.

In the checkin msg(s), be sure to say this is a "bugfix 
candidate" patch.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 21:30

Message:
Logged In: YES 
user_id=14198

Good idea re subclassing to provoke the deadlock!  Attaching
the exact same Queue.py patch, plus a reasonable test case -
both blocking and non-blocking gets and puts are tested in
the succeeding and failing cases.  Without the Queue.py
patch, both Linux and Windows deadlock in the tests.  With
the patch, both succeed.  If no objections I will check it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 15:09

Message:
Logged In: YES 
user_id=31435

The patch looks good to me, but I would like to see a test 
case.  Note that you can build a reliable test case by 
subclassing Queue and overriding its _put and/or _get 
methods, arranging to raise an exception deliberately from 
them.  Any exception in these would leave a semaphore and 
self.mutex held forever in the current Queue.py.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-16 22:18

Message:
Logged In: YES 
user_id=14198

This patch seems reasonable to me.  Tim, a quick look would 
be appreciated.  Writing a reasonable test case seems 
difficult :(  It doesn't seem worth adding this little test 
script to the test suite.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-16 12:47

Message:
Logged In: YES 
user_id=31435

Yup, it hangs on Win98 too.  Nice job of whittling it down, 
Mark!  We've been looking for an excuse to make Queue 
slower too <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544473&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 02:48:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 18:48:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16yNWC-0004CG-00@usw-sf-web1.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 14:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Jeremy Hylton (jhylton)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-19 11:48

Message:
Logged In: YES 
user_id=14198

Jeremy - if you prefer, just assign it back and I will check
it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 11:37

Message:
Logged In: YES 
user_id=31435

Good show, Mark!  Assigning to Jeremy.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 11:36

Message:
Logged In: YES 
user_id=31435

Andrew, right, I understood the bug report.  The question 
I'm wondering about is why you don't see a problem on 
Linux, because the code Mark patched has nothing to do with 
Windows specifically.  Your bug report didn't say which 
version of zlib you were using, so that was a possibly 
relevant difference -- turns out it wasn't.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 11:29

Message:
Logged In: YES 
user_id=14198

Oh ye of little faith <wink>

Looks to me like a Python CVS problem.  My Linux build also 
crashes:

Python 2.3a0 (#13, Apr  6 2002, 13:45:37)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-79)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()
Segmentation fault (core dumped)

My patch also fixes it :)

A quick scan of CVS shows the following checkin responsible:

----------------------------
Revision : 2.49
Date : 2001/10/16 23:2:32
Author : 'jhylton'
State : 'Exp'
Lines : +115 -169
Description :
Simplify and fix error handling for most cases.


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-04-18 11:13

Message:
Logged In: YES 
user_id=50945

Tim, I'm using Debian's 1.1.4 on Linux, but Linux is working
fine (perhaps you misread my bug report, which was rather
terse?).  The example I gave segfaults on Windows 2000.  It
should instead raise a zlib.error, which it does on Linux. 
The docs say that you cannot do anything useful with a
compressobj opened in mode Z_FINISH (the default) after
calling flush, so the zlib.error is expected.

I can't test Mark's patch, but at a glance it looks good.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 11:07

Message:
Logged In: YES 
user_id=31435

Mark, looks good to me, but I'd really like to see someone 
on Linux dig into this too.  Is this an ancient bug that 
just never surfaced before?  Or does it have something to 
do with moving to zlib 1.1.4 on Windows?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 16:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 14:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 04:34:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 20:34:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-441279 ] ConfigParser.options return default opts
Message-ID: <E16yPA1-0002fc-00@usw-sf-web4.sourceforge.net>

Bugs item #441279, was opened at 2001-07-14 07:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441279&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: eXom (jkuan)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: ConfigParser.options return default opts

Initial Comment:
I have a config file which has the following sections

------------------
[DEFAULT]

logLevel = 9
port = 17870

[SECURITY]
user = hello

-------------------

On python, if I do the followings:

Python 2.0 (#1, Oct 16 2000, 18:10:03) 
[GCC 2.95.2 19991024 (release)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> from ConfigParser import *
>>> f = open('/tmp/testrc', 'r')
>>> a = ConfigParser()
>>> a.defaults()
{}
>>> a.readfp(f)
>>> a.defaults()
{'port': '17870', 'loglevel': '9'}
>>> a.options("SECURITY")    
['port', 'user', 'loglevel']     <<<<<<<<!!!!!!!!!
>>> 

I thought a.options("SECURITY") will only return
['user'], however it returns everything including the
default options.

I am a bit confused.

Thanks
Joe

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-18 23:33

Message:
Logged In: YES 
user_id=3066

Based on a discussion with Guido, we think the right thing
is to avoid changing the ConfigParser module when the "bug"
can be worked around.  We need a better way to handle this
kind of configuration data, and that's on my shoulders now
(I kinda volunteered ;).

Closing this as "Won't Fix" since it doesn't appear that the
submitter had a problem with the workaround.

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 16:51

Message:
Logged In: YES 
user_id=37132

how do you see the implementation being changed?  Looking through the python bug list, it is not always 
clear where help is desired or able to be accepted.


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-07-19 10:36

Message:
Logged In: YES 
user_id=3066

This is an accident of the implementation; had your DEFAULT
section been named anything else (such as DEFAULT-OPTIONS),
you would not have been bitten by this.  It should not be
hard to rearrange the implementation to make the acquistion
of information from the set of default values less prone to
accidental interactions.

Assigning to myself.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=441279&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 05:06:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 21:06:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-225003 ] Extension manual: Windows DLL/C++ info needs review
Message-ID: <E16yPfE-0005cF-00@usw-sf-web1.sourceforge.net>

Bugs item #225003, was opened at 2000-12-08 10:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Extension manual: Windows DLL/C++ info needs review

Initial Comment:
The section on building extensions on Windows needs to be updated.  A single section, shared for Unix & Windows, needs to point out the distutils approach and point to the appropriate manual.

Information about linking, DLLs/shared libraries, and use of C++ needs to be reviewed and updated.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-19 00:06

Message:
Logged In: YES 
user_id=3066

Abstracted the version numbers in file names in
Doc/ext/windows.tex revisions 1.6 and 1.3.6.2.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-09 05:12

Message:
Logged In: YES 
user_id=21627

Information on building with distutils has been added in a
separate section now.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-09 05:12

Message:
Logged In: YES 
user_id=21627

Information on building with distutils has been added in a
separate section now.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:38

Message:
Logged In: YES 
user_id=31392

Fred, It sounds like this task is done or almost done.  Can 
we close the bug report?


----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2001-12-14 07:44

Message:
Logged In: YES 
user_id=60314

I have reviewed Doc/ext/windows.tex, rev=1.3.  Every issue I
had noticed seems fixed very well.  The only remaining
problem I can see are many mentions of python15.lib at the
end of the documents; these should presumably be changed
to python22.lib (a mention of version dependency of these
numbers would probably be a good idea).

Great job!



----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-13 12:23

Message:
Logged In: YES 
user_id=3066

The instructions for building extensions on Windows have
been completely replaced in Doc/ext/windows.tex revision
1.3.  The DLL discussion and C++ usage documentation still
needs to be reviewed, but the known-broken docs have been
corrected.

Lowering the priority of the remaining aspects of this
report, and changing the summary line.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-12-12 00:53

Message:
Logged In: YES 
user_id=3066

This is closely related to SF bug #221671.  Bumping the
priority to match.

I'll plan to get this done for 2.2rc1; Alex, I'll expect you
to review the updated material once the release candidate is
out so I can get your comments before the final release.  ;-)

----------------------------------------------------------------------

Comment By: Alex Martelli (aleax)
Date: 2001-08-17 03:52

Message:
Logged In: YES 
user_id=60314

Yes, I fully agree -- the information in the manual at 
http://python.sourceforge.net/devel-docs/ext/win-
cookbook.html is positively wrong, and one of the major 
causes of help requests in my experience -- people look for 
inexistent http://starship.python.net/crew/da/compile/, 
download the sources to get a pyconfig.h they don't need 
and look for a PC\pyconfig.h that doesn't exist, and get 
tied into knots writing a Setup file.  Seems a very serious 
situation to me.

While we wait to do it 'just right', couldn't at least the 
present erroneous text be replaced with some temporary 
pointer e.g. to some of the various posts on the subject 
(cfr http://groups.google.com/groups?
as_q=setup.py&as_uauthors=alex%20martelli for many 
examples, or my apparently popular recipe at 
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/6650
9, or...?) -- I'll be happy to write/rewrite this stuff 
with whatever mods you require, Fred, except that I can't 
seem to use the 'official' way to write Python docs (LaTex 
etc etc -- I thought a Linux box would make it easy but i'm 
still having problems setting it up, sigh).

Let me know if I can be of help in any way, but I think 
that, particularly now with the nice new material in 
chapter 2, it's a positive ill to leave chapter 4 as it is 
now...:-(


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=225003&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 06:16:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 18 Apr 2002 22:16:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-416526 ] Regular expression tests: SEGV on Mac OS
Message-ID: <E16yQkr-0004oO-00@usw-sf-web2.sourceforge.net>

Bugs item #416526, was opened at 2001-04-16 14:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470

Category: Regular Expressions
Group: Platform-specific
Status: Open
Resolution: None
Priority: 6
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Fredrik Lundh (effbot)
Summary: Regular expression tests: SEGV on Mac OS

Initial Comment:
The regular expression regression tests 'test_re' 
causes a SEGV failure on Mac OS X version 10.0.1 
when using Python 2.1c2 (and earlier). This is 
caused by the test trying to recurse 50,000 levels 
deep.

Workaround: A workaround is to limit how deep the 
regular expression library can recurse (this is 
already done for Win32). This can be achieved by 
changing file './Modules/_sre.c' using the following 
patch:

--- ./orig/_sre.c   Sun Apr 15 19:00:58 2001
+++ ./new/_sre.c    Mon Apr 16 21:39:29 2001
@@ -75,6 +75,9 @@
    Win64 (MS_WIN64), Linux64 (__LP64__), 
Monterey (64-bit AIX) (_LP64) */
 /* FIXME: maybe the limit should be 40000 / 
sizeof(void*) ? */
 #define USE_RECURSION_LIMIT 7500
+#elif defined(__APPLE_CC__)
+/* Apple 'cc' compiler eg. for Mac OS X */
+#define USE_RECURSION_LIMIT 4000
 #else
 #define USE_RECURSION_LIMIT 10000
 #endif


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-18 22:16

Message:
Logged In: NO 

same problem on 10.1.4

james@i-mech.com



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-20 20:49

Message:
Logged In: YES 
user_id=6380

/F is unavailable, I don't want this to hold up the 2.2a2
release, so I'm lowering the priority because it doesn't
affect Linux or Windows.

(Remember, no bugs/patches with priority >= 7 should be left
when doing a release.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-06-01 17:41

Message:
Logged In: NO 


>An alternate (and perhaps better) workaround could be
to increase the stack size on Mac OS X.

it's been tried and shot down as a will not fix. :-(

instead of +#elif defined(__APPLE_CC__) perhaps we should use __APPLE__ as per the documentation:

There are two relatively new macros: __APPLE__ and __APPLE_CC__.The former refers to any Apple platform, though at present it is only predefined in Apple's gcc-based Mac OS X and Mac OS X Server compilers. The value of the latter is an integer that corresponds to the version number of the compiler. This should allow one to distinguish, for example, between compilers based on the same version of gcc, but with different bug fixes or features. At present, larger values denote (chronologically) later compilers.

- D



----------------------------------------------------------------------

Comment By: Fredrik Lundh (effbot)
Date: 2001-04-26 15:01

Message:
Logged In: YES 
user_id=38376

An alternate (and perhaps better) workaround could be
to increase the stack size on Mac OS X.

But in either case, my plan is to get rid of the recursion
limit in 2.2 (stackless SRE may still run out of memory,
but it shouldn't have to run out of stack).

Cheers /F

----------------------------------------------------------------------

Comment By: Dan Wolfe (dkwolfe)
Date: 2001-04-17 16:52

Message:
Logged In: YES 
user_id=80173

Instead of relying on a compiler variable, we should probably 
set a environment variable as part of the ./configure and use 
that to determine when to reduce the USE_RECURSION_LIMIT.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=416526&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 09:21:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 01:21:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16yTe8-0006go-00@usw-sf-web2.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 21:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 10:21

Message:
Logged In: YES 
user_id=21627

POSIX specifies

  The file permission bits of the new directory shall be 
  initialized from mode. These file permission bits of 
  the mode shall be modified by the process' file creation 
  mask. When bits in mode other than the file permission
  bits are set, the meaning of these additional bits is 
  implementation-defined.

(see
http://www.opengroup.org/onlinepubs/007904975/functions/mkdir.html)

S_ISGID is such an additional bit, so its meaning is
implementation defined. Portability with respect to S_ISGID
cannot be achieved by implicitly invoking chmod afterwards:
S_ISGID might not be supported for directories at all, or
its meaning might vary from system to system.

So I'd rather honor system policies than trying to cheat them.

*If* somebody tries to produce a patch to provide that
feature, I'd require that a) there is an autoconf test for
it, instead of merely checking whether the system is
FreeBSD; b) no additional system call is made on systems
where mkdir already has the desired effect; and c) that this
deviation from the system's mkdir(2) is properly documented.



----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 22:23

Message:
Logged In: YES 
user_id=366473

Indeed MAC OS X mkdir() is correct, it abides by umask.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-04-18 20:04

Message:
Logged In: YES 
user_id=92689

For the record: I cannot reproduce what dgrassi
reports; the mod argument to os.mkdir() works for
me on MacOSX.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-18 19:40

Message:
Logged In: YES 
user_id=12800

It's also quite inconvenient for cross platform portability
because now you have to either always call os.chmod()
everytime you call os.mkdir(), or replace os.mkdir() with a
function that does that (so all call sites, even in library
modules actually DTRT).

IWBNI Python's default os.mkdir() provided that cross
platform compatibility.


----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 18:08

Message:
Logged In: YES 
user_id=366473

On Mac OS X which is also a BSD derivative the mode argument to mkdir()is completely ignored.  This becomes more of an issue when makedirs() is used because a simple chmod (which does work) is not sufficient if multiple directories were created.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-06 01:50

Message:
Logged In: YES 
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 09:23:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 01:23:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-545600 ] IDLE doesn't save 8bit files
Message-ID: <E16yTg1-0006iD-00@usw-sf-web2.sourceforge.net>

Bugs item #545600, was opened at 2002-04-18 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE doesn't save 8bit files

Initial Comment:
This bug seems to be related to #527022. 

Short version is: IDLE won't save files containing 8bit
characters (for instance in comments or in litteral
strings). No error dialog is displayed, only a
traceback on stderr or in the interactive window if
it's available:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.1/lib-tk/Tkinter.py", line
1285, in __call__
    return apply(self.func, args)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
126, in save
    self.save_as(event)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
136, in save_as
    if self.writefile(filename):
  File "/usr/lib/idle-python2.1/IOBinding.py", line
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in
range(128)

Possible solution:

 * at least warn the user that the file could not be
saved with an error dialog
 * try using the locale to guess the encoding and do
appropriate conversions
 * ask the user wich encoding should be used to save
the file

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 10:23

Message:
Logged In: YES 
user_id=21627

In this form, this is not a bug. IDLE cannot know what
encoding you want to use the file.

Under PEP 263, you will need to declare the encoding inside
the file; then IDLE will use the declared encoding. See

http://sourceforge.net/tracker/index.php?func=detail&aid=508973&group_id=9579&atid=309579

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 10:30:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 02:30:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-545600 ] IDLE doesn't save 8bit files
Message-ID: <E16yUig-0006Pk-00@usw-sf-web4.sourceforge.net>

Bugs item #545600, was opened at 2002-04-18 13:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexandre Fayolle (afayolle)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE doesn't save 8bit files

Initial Comment:
This bug seems to be related to #527022. 

Short version is: IDLE won't save files containing 8bit
characters (for instance in comments or in litteral
strings). No error dialog is displayed, only a
traceback on stderr or in the interactive window if
it's available:

Exception in Tkinter callback
Traceback (most recent call last):
  File "/usr/lib/python2.1/lib-tk/Tkinter.py", line
1285, in __call__
    return apply(self.func, args)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
126, in save
    self.save_as(event)
  File "/usr/lib/idle-python2.1/IOBinding.py", line
136, in save_as
    if self.writefile(filename):
  File "/usr/lib/idle-python2.1/IOBinding.py", line
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in
range(128)

Possible solution:

 * at least warn the user that the file could not be
saved with an error dialog
 * try using the locale to guess the encoding and do
appropriate conversions
 * ask the user wich encoding should be used to save
the file

----------------------------------------------------------------------

>Comment By: Alexandre Fayolle (afayolle)
Date: 2002-04-19 11:30

Message:
Logged In: YES 
user_id=116727

I like the solution proposed in the reference.

However, having just a traceback printed on the console
looks like a bug to me. I expect IDLE to complain loudly in
case it cannot save my file. If it could give me a hint as
to what to add to the file to be able to save it, that'd be
even better. 

Cheers 

Alexandre 

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 10:23

Message:
Logged In: YES 
user_id=21627

In this form, this is not a bug. IDLE cannot know what
encoding you want to use the file.

Under PEP 263, you will need to declare the encoding inside
the file; then IDLE will use the declared encoding. See

http://sourceforge.net/tracker/index.php?func=detail&aid=508973&group_id=9579&atid=309579

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545600&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 11:51:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 03:51:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-546059 ] regex segfault on Mac OS X
Message-ID: <E16yVz3-0006kD-00@usw-sf-web3.sourceforge.net>

Bugs item #546059, was opened at 2002-04-19 12:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
Assigned to: Fredrik Lundh (effbot)
Summary: regex segfault on Mac OS X

Initial Comment:
I attach a Python script and a data file.

Run it this way to reproduce the segfault:
	./bug.py data.txt

I can't reproduce the bug on Solaris or Linux, only Mac
OS X.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 11:53:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 03:53:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-546059 ] regex segfault on Mac OS X
Message-ID: <E16yW1A-0006lj-00@usw-sf-web3.sourceforge.net>

Bugs item #546059, was opened at 2002-04-19 12:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
Assigned to: Fredrik Lundh (effbot)
Summary: regex segfault on Mac OS X

Initial Comment:
I attach a Python script and a data file.

Run it this way to reproduce the segfault:
	./bug.py data.txt

I can't reproduce the bug on Solaris or Linux, only Mac
OS X.


----------------------------------------------------------------------

>Comment By: Dimitri Papadopoulos (papadopo)
Date: 2002-04-19 12:53

Message:
Logged In: YES 
user_id=52414

This was reproduced using the Python 2.2 for Mac OS X from
Fink, version (#1 Jan 9, 2002)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 12:38:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 04:38:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16yWiY-0000UN-00@usw-sf-web2.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 11:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Booth (duncanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 13:43:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 05:43:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-546059 ] regex segfault on Mac OS X
Message-ID: <E16yXjj-0001Hz-00@usw-sf-web2.sourceforge.net>

Bugs item #546059, was opened at 2002-04-19 12:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470

Category: Regular Expressions
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Dimitri Papadopoulos (papadopo)
Assigned to: Fredrik Lundh (effbot)
Summary: regex segfault on Mac OS X

Initial Comment:
I attach a Python script and a data file.

Run it this way to reproduce the segfault:
	./bug.py data.txt

I can't reproduce the bug on Solaris or Linux, only Mac
OS X.


----------------------------------------------------------------------

>Comment By: Dimitri Papadopoulos (papadopo)
Date: 2002-04-19 14:43

Message:
Logged In: YES 
user_id=52414

I've run the same program with MacPython instead of Python
for Mac OS X from Fink and I now get a "maximum recursion
limit exceeded" so this may be a duplicate of similar bug
reports:
418626
437472
493252
except that I can reproduce this with Python 2.2.


----------------------------------------------------------------------

Comment By: Dimitri Papadopoulos (papadopo)
Date: 2002-04-19 12:53

Message:
Logged In: YES 
user_id=52414

This was reproduced using the Python 2.2 for Mac OS X from
Fink, version (#1 Jan 9, 2002)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546059&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 14:23:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 06:23:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-546117 ] readlines() bombs - last line incomplete
Message-ID: <E16yYM2-0000h8-00@usw-sf-web4.sourceforge.net>

Bugs item #546117, was opened at 2002-04-19 13:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: readlines() bombs - last line incomplete

Initial Comment:
HP-UX 11 64bit, compiled with HP ansi c compiler.
Python version 2.2.1rc2

>>> f=open(some_big_file)
>>> f.readlines()
Pid 23292 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

Happens when last line of file lacks a terminating \n,
also the file has to be big enough (my example is about
2K in size)

Oddly, xreadlines() can be created, but attempting to
iterate over it crashes before the first line is 
returned:
>>> f=open(some_big_file)
>>> lines=f.xreadlines()    # OK so far
>>> for line in lines:
...    print line      # never gets here
...

Pid 23257 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

I'll try 2.2.1 final.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 14:25:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 06:25:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16yYOD-0001m8-00@usw-sf-web2.sourceforge.net>

Bugs item #534153, was opened at 2002-03-23 18:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Martin v. L�wis (loewis)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

Comment By: Matt Behrens (mattbehrens)
Date: 2002-04-19 09:25

Message:
Logged In: YES 
user_id=240525

This was indeed backported to 2.2.1 by mwh and it is
breaking the build on OpenBSD.  We don't have CODESET, but
we do have T_FMT_AMPM; however we don't have ERA, ERA_D_FMT,
ERA_D_T_FMT, ERA_T_FMT, or ALT_DIGITS.

I don't understand locale well enough to tell what I do and
do not need out of these.  Prior to this, the fact that
CODESET was not defined was sufficient to take out everything.

I'd like to coordinate to get a proper fix that can
hopefully be in 2.2.2. (I'm the OpenBSD package maintainer
for python.)  Perhaps it is more proper to nest the
T_FMT_AMPM-tested stuff inside the CODESET ifdef?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:17

Message:
Logged In: YES 
user_id=21627

This has been fixed in _localemodule.c 2.28. IMO, it is not
critical enough for 2.2.1, but a backport of the patch to
2.2.2 will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 14:37:08 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 06:37:08 -0700
Subject: [Python-bugs-list] [ python-Bugs-506349 ] Zope crashing with signal 11
Message-ID: <E16yYZY-0000JG-00@usw-sf-web3.sourceforge.net>

Bugs item #506349, was opened at 2002-01-21 01:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470

Category: Python Interpreter Core
Group: Python 2.1.2
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Harald Koschinski (astir)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Zope crashing with signal 11

Initial Comment:
after switching to python 2.1.2 compiled with GC
(intranet:/usr/local/src/Python-2.1.2 # ./configure
--without-pymalloc)
the crashes are back again :-(((((((((((((((((((((((

-------------------------------------------------------------------------------------
2002-01-04T06:23:51 ERROR(200) zdaemon zdaemon: Fri Jan
 4 07:23:51 2002: Aiieee! 9671 exited with error code: 11
2002-01-04T07:25:48 ERROR(200) zdaemon zdaemon: Fri Jan
 4 08:25:48 2002: Aiieee! 10107 exited with error code: 11
2002-01-04T07:30:45 ERROR(200) zdaemon zdaemon: Fri Jan
 4 08:30:45 2002: Aiieee! 10412 exited with error code: 11
2002-01-21T08:30:43 ERROR(200) zdaemon zdaemon: Mon Jan
21 09:30:43 2002: Aiieee! 6749 exited with error code: 11
-----------------------------------------------------------------------------------

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-19 06:37

Message:
Logged In: NO 

Currently it has been fixed : 
python 2.1.3 at http://www.python.org

The zope beta packages are already updated with this 
version of python.


----------------------------------------------------------------------

Comment By: Harald Koschinski (astir)
Date: 2002-03-13 05:02

Message:
Logged In: YES 
user_id=321375

Many people have this problem but nobody has as real
solution. I can fix the problem in to way's:
1. -t1
2. compiling python without gc

Both are no real solutions and have big disadvantages :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-03-13 03:08

Message:
Logged In: NO 

I also have this problem. I have Zope 2.5.1 beta 1, and
it crashes on linux and on windows. It DOESN't crash,
however, with the -t1 option. 

I thought this could be a c extension we are using (ming),
but it also crashes without this library installed.

Does SOMEBODY have any idea? 
(ZOPE_SECURITY_POLICY=PYTHON doens't work also)
mart@eastsite.nl

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-22 20:28

Message:
Logged In: YES 
user_id=29957

This is a bug in the current Zope 2.4.3 release. Either
upgrade to the current 2.4 branch of CVS, grab the current
2.5 beta, or else wait until 2.4.4 is out.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-21 02:23

Message:
Logged In: YES 
user_id=29957

Which version of Zope are you running?
Does it have the RestrictedCompiler fix?

As far as I am aware, Zope 2.4 includes it's own 
version of the Compiler code, and the current release 
of 2.4 still has the stacksize bug.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-01-21 01:39

Message:
Logged In: YES 
user_id=29957

Which version of Zope are you running?
Does it have the RestrictedCompiler fix?

As far as I am aware, Zope 2.4 includes it's own 
version of the Compiler code, and the current release 
of 2.4 still has the stacksize bug.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=506349&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 14:43:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 06:43:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16yYfH-0003Sp-00@usw-sf-web1.sourceforge.net>

Bugs item #534153, was opened at 2002-03-23 23:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
Group: Python 2.3
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Martin v. L�wis (loewis)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-04-19 13:43

Message:
Logged In: YES 
user_id=6656

I love unix.

Can you come up with a patch?

Sorry, lets try and get this right for 222...

----------------------------------------------------------------------

Comment By: Matt Behrens (mattbehrens)
Date: 2002-04-19 13:25

Message:
Logged In: YES 
user_id=240525

This was indeed backported to 2.2.1 by mwh and it is
breaking the build on OpenBSD.  We don't have CODESET, but
we do have T_FMT_AMPM; however we don't have ERA, ERA_D_FMT,
ERA_D_T_FMT, ERA_T_FMT, or ALT_DIGITS.

I don't understand locale well enough to tell what I do and
do not need out of these.  Prior to this, the fact that
CODESET was not defined was sufficient to take out everything.

I'd like to coordinate to get a proper fix that can
hopefully be in 2.2.2. (I'm the OpenBSD package maintainer
for python.)  Perhaps it is more proper to nest the
T_FMT_AMPM-tested stuff inside the CODESET ifdef?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 12:17

Message:
Logged In: YES 
user_id=21627

This has been fixed in _localemodule.c 2.28. IMO, it is not
critical enough for 2.2.1, but a backport of the patch to
2.2.2 will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:13:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:13:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-539942 ] os.mkdir() handles SETGID inconsistently
Message-ID: <E16yZ8X-0001Hv-00@usw-sf-web4.sourceforge.net>

Bugs item #539942, was opened at 2002-04-05 14:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470

Category: Python Library
Group: Python 2.1.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Les Niles (lniles)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.mkdir() handles SETGID inconsistently

Initial Comment:
Under FreeBSD 4.4, with the 2.1.2, 2.1.1 or 1.5.2 
library, os.mkdir() does NOT set the SETGID or SETUID 
bits, regardless of whether they're specified in the 
mode argument to os.mkdir().  The bits can be set via 
a call to os.chmod().  This behavior appears to be 
inherited from FreeBSD's mkdir() os call.  On Linux, 
the SETGID/SETUID bits are set via os.mkdir()'s mode 
argument.  (As near as I can tell, POSIX.1 specifies 
yet a different behavior.)  This is a bug from the 
standpoint of Python's os module providing a uniform 
interface.
 

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-19 10:13

Message:
Logged In: YES 
user_id=12800

Martin, I agree with all your requirements (this shouldn't
be construed as an offer to produce such a patch!)

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 04:21

Message:
Logged In: YES 
user_id=21627

POSIX specifies

  The file permission bits of the new directory shall be 
  initialized from mode. These file permission bits of 
  the mode shall be modified by the process' file creation 
  mask. When bits in mode other than the file permission
  bits are set, the meaning of these additional bits is 
  implementation-defined.

(see
http://www.opengroup.org/onlinepubs/007904975/functions/mkdir.html)

S_ISGID is such an additional bit, so its meaning is
implementation defined. Portability with respect to S_ISGID
cannot be achieved by implicitly invoking chmod afterwards:
S_ISGID might not be supported for directories at all, or
its meaning might vary from system to system.

So I'd rather honor system policies than trying to cheat them.

*If* somebody tries to produce a patch to provide that
feature, I'd require that a) there is an autoconf test for
it, instead of merely checking whether the system is
FreeBSD; b) no additional system call is made on systems
where mkdir already has the desired effect; and c) that this
deviation from the system's mkdir(2) is properly documented.



----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 16:23

Message:
Logged In: YES 
user_id=366473

Indeed MAC OS X mkdir() is correct, it abides by umask.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-04-18 14:04

Message:
Logged In: YES 
user_id=92689

For the record: I cannot reproduce what dgrassi
reports; the mod argument to os.mkdir() works for
me on MacOSX.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-18 13:40

Message:
Logged In: YES 
user_id=12800

It's also quite inconvenient for cross platform portability
because now you have to either always call os.chmod()
everytime you call os.mkdir(), or replace os.mkdir() with a
function that does that (so all call sites, even in library
modules actually DTRT).

IWBNI Python's default os.mkdir() provided that cross
platform compatibility.


----------------------------------------------------------------------

Comment By: Dan Grassi (dgrassi)
Date: 2002-04-18 12:08

Message:
Logged In: YES 
user_id=366473

On Mac OS X which is also a BSD derivative the mode argument to mkdir()is completely ignored.  This becomes more of an issue when makedirs() is used because a simple chmod (which does work) is not sufficient if multiple directories were created.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-05 18:50

Message:
Logged In: YES 
user_id=21627

This is not a bug. The posix module exposes functions from
the OS as-is, not trying to unify them. The os module
re-exposes those functions where available. Minor details of
the behaviour of those functions across platforms are
acceptable. For example, on Windows, os.mkdir does not set
any bits. Instead, ACLs are inherited according to the OS
semantics (i.e. it does on NTFS, but doesn't on FAT32).

If you need a function that makes certain additional
guarantees, write a new function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539942&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:31:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:31:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-546155 ] posix_int() is not used
Message-ID: <E16yZQ0-0000wp-00@usw-sf-web3.sourceforge.net>

Bugs item #546155, was opened at 2002-04-19 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546155&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: posix_int() is not used

Initial Comment:
Fred, in the cleanup you made on 4/15 in posixmodule,
you re-orged a lot.  posix_int() is no longer used.
Was this intentional?  If not, assign the bug to me and
I'll remove the function.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546155&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:34:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:34:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-546156 ] load_false/true() not used
Message-ID: <E16yZSx-0000z6-00@usw-sf-web3.sourceforge.net>

Bugs item #546156, was opened at 2002-04-19 10:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546156&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Guido van Rossum (gvanrossum)
Summary: load_false/true() not used

Initial Comment:
Guido, in cPickle, load_false() & load_true() aren't
used.  I suspect this was due to the late change to
pickling.  Is there any reason to keep these?  If not,
assign back to be and I'll remove them.

Neal


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546156&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:45:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:45:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-546155 ] posix_int() is not used
Message-ID: <E16yZe4-0002k7-00@usw-sf-web2.sourceforge.net>

Bugs item #546155, was opened at 2002-04-19 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546155&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: posix_int() is not used

Initial Comment:
Fred, in the cleanup you made on 4/15 in posixmodule,
you re-orged a lot.  posix_int() is no longer used.
Was this intentional?  If not, assign the bug to me and
I'll remove the function.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-19 10:45

Message:
Logged In: YES 
user_id=3066

It was not a specific goal, not something I checked
afterward.  I don't think I saw a warning about that from
GCC, which is odd, but grep can't find it.

Feel free to remove dead code!  Thanks for spotting it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546155&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:47:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:47:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-544995 ] zlib crash on win32
Message-ID: <E16yZfj-0001gp-00@usw-sf-web4.sourceforge.net>

Bugs item #544995, was opened at 2002-04-17 04:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Jeremy Hylton (jhylton)
Summary: zlib crash on win32

Initial Comment:
On Win2k:

>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()    # This crashes.

This occurs both from the command line and from IDLE.

I cannot reproduce this on Linux (it just raises a
zlib.error, as you would expect).

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-19 01:48

Message:
Logged In: YES 
user_id=14198

Jeremy - if you prefer, just assign it back and I will check
it in.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 01:37

Message:
Logged In: YES 
user_id=31435

Good show, Mark!  Assigning to Jeremy.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 01:36

Message:
Logged In: YES 
user_id=31435

Andrew, right, I understood the bug report.  The question 
I'm wondering about is why you don't see a problem on 
Linux, because the code Mark patched has nothing to do with 
Windows specifically.  Your bug report didn't say which 
version of zlib you were using, so that was a possibly 
relevant difference -- turns out it wasn't.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-18 01:29

Message:
Logged In: YES 
user_id=14198

Oh ye of little faith <wink>

Looks to me like a Python CVS problem.  My Linux build also 
crashes:

Python 2.3a0 (#13, Apr  6 2002, 13:45:37)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-79)] on linux2
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import zlib
>>> c = zlib.compressobj()
>>> c.flush()
'x\x9c\x03\x00\x00\x00\x00\x01'
>>> c.flush()
Segmentation fault (core dumped)

My patch also fixes it :)

A quick scan of CVS shows the following checkin responsible:

----------------------------
Revision : 2.49
Date : 2001/10/16 23:2:32
Author : 'jhylton'
State : 'Exp'
Lines : +115 -169
Description :
Simplify and fix error handling for most cases.


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-04-18 01:13

Message:
Logged In: YES 
user_id=50945

Tim, I'm using Debian's 1.1.4 on Linux, but Linux is working
fine (perhaps you misread my bug report, which was rather
terse?).  The example I gave segfaults on Windows 2000.  It
should instead raise a zlib.error, which it does on Linux. 
The docs say that you cannot do anything useful with a
compressobj opened in mode Z_FINISH (the default) after
calling flush, so the zlib.error is expected.

I can't test Mark's patch, but at a glance it looks good.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-18 01:07

Message:
Logged In: YES 
user_id=31435

Mark, looks good to me, but I'd really like to see someone 
on Linux dig into this too.  Is this an ancient bug that 
just never surfaced before?  Or does it have something to 
do with moving to zlib 1.1.4 on Windows?

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-17 06:56

Message:
Logged In: YES 
user_id=14198

Crashes for me too.  Attaching patch to zlibmodule, and
addition to test suite that demonstrates the crash.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-17 04:43

Message:
Logged In: YES 
user_id=31435

Andrew, which version of zlib were you using on Linux?  
Windows ships with zlib 1.1.4, which is a very recent 
release produced by the zlib folks to plug a zlib security 
hole.  On Linux we don't ship any version of zlib, so you 
get whatever zlib happens to be sitting on your box.  If 
you haven't done something to upgrade your Linux zlib 
version, you probably have 1.1.3.  Can you check?  (And no, 
sorry, I don't know how you can check -- but since you're 
closer to your box than I am, you've got a better shot than 
I do <wink>).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544995&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:50:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:50:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16yZiL-0001AF-00@usw-sf-web3.sourceforge.net>

Bugs item #534153, was opened at 2002-03-24 00:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Martin v. L�wis (loewis)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 16:50

Message:
Logged In: YES 
user_id=21627

I think the proper fix is to not group them at all, but to
check each of them individually. A patch would be
appreciated: Just split the T_FMT_AMPM block; I'd still
delay ifdefing the others until we get problem reports for
those as well.

If you can, please port the patch for both 2.3 and 2.2. Put
in a comment giving the rationale for the split.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-19 15:43

Message:
Logged In: YES 
user_id=6656

I love unix.

Can you come up with a patch?

Sorry, lets try and get this right for 222...

----------------------------------------------------------------------

Comment By: Matt Behrens (mattbehrens)
Date: 2002-04-19 15:25

Message:
Logged In: YES 
user_id=240525

This was indeed backported to 2.2.1 by mwh and it is
breaking the build on OpenBSD.  We don't have CODESET, but
we do have T_FMT_AMPM; however we don't have ERA, ERA_D_FMT,
ERA_D_T_FMT, ERA_T_FMT, or ALT_DIGITS.

I don't understand locale well enough to tell what I do and
do not need out of these.  Prior to this, the fact that
CODESET was not defined was sufficient to take out everything.

I'd like to coordinate to get a proper fix that can
hopefully be in 2.2.2. (I'm the OpenBSD package maintainer
for python.)  Perhaps it is more proper to nest the
T_FMT_AMPM-tested stuff inside the CODESET ifdef?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 13:17

Message:
Logged In: YES 
user_id=21627

This has been fixed in _localemodule.c 2.28. IMO, it is not
critical enough for 2.2.1, but a backport of the patch to
2.2.2 will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:50:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:50:29 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16yZiX-0002nW-00@usw-sf-web2.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Walter D�rwald (doerwalter)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-19 16:50

Message:
Logged In: YES 
user_id=89016

Here is the patch (diff.txt).

This a simple copy of the string version. I had to make the 
unicode version of do_xstrip public (as _PyUnicode_XStrip), 
so that the string version can call it when it gets passed 
a unicode object.


----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-18 21:28

Message:
Logged In: YES 
user_id=89016

I have a patch ready that implements the unicode version, 
and the mixed versions, i.e. str.strip(unicode) and 
unicode.strip(str), but CVS doesn't like me today.

Maybe tomorrow!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-13 04:43

Message:
Logged In: YES 
user_id=3066

(I'd say this is a good reason not to use separate trackers
for features, bugs, & patches -- they're too closely related
to keep them separate, and links between them too tedious
when written only in tracker comments!)

I've updated the documentation for these methods in
Doc/lib/libstdtypes.tex revision 1.87.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-13 03:02

Message:
Logged In: YES 
user_id=6380

Oops, I saw your remark too late.

I've checked in my own version of this for regular
strings...

Feel free to check in your version of this for Unicode
strings, and the docs etc.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 17:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 16:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 11:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 10:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 09:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 23:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:50:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:50:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-545410 ] corefile: python 2.1.3, zope 2.5.0
Message-ID: <E16yZih-0001j8-00@usw-sf-web4.sourceforge.net>

Bugs item #545410, was opened at 2002-04-17 23:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Gerrietts (ggerrietts)
Assigned to: Nobody/Anonymous (nobody)
Summary: corefile: python 2.1.3, zope 2.5.0

Initial Comment:
I regularly get a corefile out of Zope 2.5.0, running
on RedHat 6.2 and Python 2.1.3, usually within 5 or 6
page views.

Reproducing the problem requires (for me) starting up
Zope, going to the management interface, and bouncing
around on a few of the different objects. Sometimes the
first attempt to render the page will cause a crash,
but sometimes it takes a few clicks. After the crash,
Zope dumps core and politely restarts itself.

Traceback files are largely the same from one crash to
the next, with the only variation I've noted being the
addresses of variables -- this fits with the fact that
it takes a different number of steps each time.

Traceback files (infuriatingly enough) do not show line
number information for select.so, even though
selectmodule.o was compiled with -g specified.

Examination of the traceback shows that in stack frame
2, print ((PyCFunctionObject *)func) -> m_ml -> ml_name
reveals "select". In that same frame, print ((PyObject
*)arg) -> ob_type -> tp_name yields "Cannot  access
memory at address 0x1f".

One traceback has been provided. Others, and other
info, available on request.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-19 14:50

Message:
Logged In: YES 
user_id=31392

Are you using any third party Python extension modules with
Zope?  It may be a memory corruption problem in an
extension.  If you are, you should try to reproduce the
problem with *only* Zope's core extensions and Python 2.1.3.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-18 05:44

Message:
Logged In: YES 
user_id=21627

In that backtrace, it is clear that arg in stackframe 2 is
bogus: 0x405d7ffc points into an area that appears to be
used for shared libraries (please do "info shared" to
support this theory).

Now, arg presumably is the return value of load_args, where
it was created through PyTuple_New. This suggests that the
memory management got corrupted; something that likely
happened much earlier.

I recommend to set MALLOC_CHECK_ before starting Python. The
documentation in malloc(3) says that setting it to 2 will
cause an abort() when an error is found; from expecting the
implementation, it appears that setting it to 3 will combine
the debug traces printed and the call to abort; please
experiment with all three values (1,2,3).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 15:58:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 07:58:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-546155 ] posix_int() is not used
Message-ID: <E16yZqa-0004KT-00@usw-sf-web1.sourceforge.net>

Bugs item #546155, was opened at 2002-04-19 10:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546155&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: posix_int() is not used

Initial Comment:
Fred, in the cleanup you made on 4/15 in posixmodule,
you re-orged a lot.  posix_int() is no longer used.
Was this intentional?  If not, assign the bug to me and
I'll remove the function.

----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-19 10:58

Message:
Logged In: YES 
user_id=33168

I only spotted it because of gcc 2.95.3 on solaris.  gcc
2.96-98 (redhat 7.2) does not report that it's unused.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-19 10:45

Message:
Logged In: YES 
user_id=3066

It was not a specific goal, not something I checked
afterward.  I don't think I saw a warning about that from
GCC, which is odd, but grep can't find it.

Feel free to remove dead code!  Thanks for spotting it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546155&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 16:31:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 08:31:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-532860 ] NameError assigning to class in a func
Message-ID: <E16yaLq-0001cG-00@usw-sf-web3.sourceforge.net>

Bugs item #532860, was opened at 2002-03-21 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Andrew Bennetts (spiv)
>Assigned to: Jeremy Hylton (jhylton)
Summary: NameError assigning to class in a func

Initial Comment:
This fails with a NameError:

def f(x)
    class Private:
        x = x
    return Private
f(17)

But this works:

def f(x):
    y = x
    class Private:
        x = y
    return Private
f(17)

But this fails:

def f(x):
    y = x
    class Private:
        y = y
    return Private
f(17)

See also the newsgroup thread:
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=Xns

(All tested on Python 2.2 on Win2k)



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 17:34:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 09:34:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16ybLS-0002uU-00@usw-sf-web4.sourceforge.net>

Bugs item #534153, was opened at 2002-03-23 18:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Martin v. L�wis (loewis)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

Comment By: Matt Behrens (mattbehrens)
Date: 2002-04-19 12:34

Message:
Logged In: YES 
user_id=240525

Attached.

All tests run OK with this patch.

Patch is here, since I can't attach to closed bugs:
http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=546194

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 10:50

Message:
Logged In: YES 
user_id=21627

I think the proper fix is to not group them at all, but to
check each of them individually. A patch would be
appreciated: Just split the T_FMT_AMPM block; I'd still
delay ifdefing the others until we get problem reports for
those as well.

If you can, please port the patch for both 2.3 and 2.2. Put
in a comment giving the rationale for the split.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-19 09:43

Message:
Logged In: YES 
user_id=6656

I love unix.

Can you come up with a patch?

Sorry, lets try and get this right for 222...

----------------------------------------------------------------------

Comment By: Matt Behrens (mattbehrens)
Date: 2002-04-19 09:25

Message:
Logged In: YES 
user_id=240525

This was indeed backported to 2.2.1 by mwh and it is
breaking the build on OpenBSD.  We don't have CODESET, but
we do have T_FMT_AMPM; however we don't have ERA, ERA_D_FMT,
ERA_D_T_FMT, ERA_T_FMT, or ALT_DIGITS.

I don't understand locale well enough to tell what I do and
do not need out of these.  Prior to this, the fact that
CODESET was not defined was sufficient to take out everything.

I'd like to coordinate to get a proper fix that can
hopefully be in 2.2.2. (I'm the OpenBSD package maintainer
for python.)  Perhaps it is more proper to nest the
T_FMT_AMPM-tested stuff inside the CODESET ifdef?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 07:17

Message:
Logged In: YES 
user_id=21627

This has been fixed in _localemodule.c 2.28. IMO, it is not
critical enough for 2.2.1, but a backport of the patch to
2.2.2 will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 17:40:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 09:40:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-546196 ] extend namespace docs to cover LOAD_NAME
Message-ID: <E16ybRO-00041h-00@usw-sf-web2.sourceforge.net>

Bugs item #546196, was opened at 2002-04-19 16:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546196&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeremy Hylton (jhylton)
Assigned to: Jeremy Hylton (jhylton)
Summary: extend namespace docs to cover LOAD_NAME

Initial Comment:
Assuming that Python continues to use LOAD_NAME, then
the reference manual ought to describe this strange
beast.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546196&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 17:39:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 09:39:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-532860 ] NameError assigning to class in a func
Message-ID: <E16ybQH-00040i-00@usw-sf-web2.sourceforge.net>

Bugs item #532860, was opened at 2002-03-21 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Jeremy Hylton (jhylton)
Summary: NameError assigning to class in a func

Initial Comment:
This fails with a NameError:

def f(x)
    class Private:
        x = x
    return Private
f(17)

But this works:

def f(x):
    y = x
    class Private:
        x = y
    return Private
f(17)

But this fails:

def f(x):
    y = x
    class Private:
        y = y
    return Private
f(17)

See also the newsgroup thread:
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=Xns

(All tested on Python 2.2 on Win2k)



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-19 16:39

Message:
Logged In: YES 
user_id=31392

This is actually working as intended, although the reference
manual no longer describes this case at all.  It has been a
long standing "feature" of Python that module and class
blocks use the LOAD_NAME opcode, which has weird scoping
rules.

The documentation should be updated to describe the cases in
which LOAD_NAME is used and its behavior.  (It checks
locals, globals, builtins in that order, and never raises a
NameError unless the name isn't found in any of those
namespaces.  In particular, an unbound local is simply
ignored.)

I don't actually know what these rules are used.  Guido--
should we get rid of LOAD_NAME?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 22:07:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 14:07:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-534153 ] CODESET Doesn't Infer ERA et al.
Message-ID: <E16yfbM-0008MS-00@usw-sf-web1.sourceforge.net>

Bugs item #534153, was opened at 2002-03-24 00:31
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470

Category: Build
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ralph Corderoy (ralph)
Assigned to: Martin v. L�wis (loewis)
Summary: CODESET Doesn't Infer ERA et al.

Initial Comment:
Under AIX 3.2, /usr/include/langinfo.h contains

    #define CODESET 49

but doesn't mention any of

    T_FMT_AMPM ERA ERA_D_FMT ERA_D_T_FMT ERA_T_FMT
    ALT_DIGITS YESEXPR NOEXPR

causing compilation of Modules/_localemodule.c to fail 
as these are all assumed if CODESET is defined (line
487).

Not au fait with the specifics of locale I can only 
suggest a different preprocessor test is used.  At 
worse case, a #ifdef conditional for each of the 
symbols above, only using them if they're defined.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 23:07

Message:
Logged In: YES 
user_id=21627

Patch committed as _localemodule.c 2.30 and 2.25.6.3

----------------------------------------------------------------------

Comment By: Matt Behrens (mattbehrens)
Date: 2002-04-19 18:34

Message:
Logged In: YES 
user_id=240525

Attached.

All tests run OK with this patch.

Patch is here, since I can't attach to closed bugs:
http://sourceforge.net/tracker/?group_id=5470&atid=305470&func=detail&aid=546194

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-19 16:50

Message:
Logged In: YES 
user_id=21627

I think the proper fix is to not group them at all, but to
check each of them individually. A patch would be
appreciated: Just split the T_FMT_AMPM block; I'd still
delay ifdefing the others until we get problem reports for
those as well.

If you can, please port the patch for both 2.3 and 2.2. Put
in a comment giving the rationale for the split.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-04-19 15:43

Message:
Logged In: YES 
user_id=6656

I love unix.

Can you come up with a patch?

Sorry, lets try and get this right for 222...

----------------------------------------------------------------------

Comment By: Matt Behrens (mattbehrens)
Date: 2002-04-19 15:25

Message:
Logged In: YES 
user_id=240525

This was indeed backported to 2.2.1 by mwh and it is
breaking the build on OpenBSD.  We don't have CODESET, but
we do have T_FMT_AMPM; however we don't have ERA, ERA_D_FMT,
ERA_D_T_FMT, ERA_T_FMT, or ALT_DIGITS.

I don't understand locale well enough to tell what I do and
do not need out of these.  Prior to this, the fact that
CODESET was not defined was sufficient to take out everything.

I'd like to coordinate to get a proper fix that can
hopefully be in 2.2.2. (I'm the OpenBSD package maintainer
for python.)  Perhaps it is more proper to nest the
T_FMT_AMPM-tested stuff inside the CODESET ifdef?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-03-27 13:17

Message:
Logged In: YES 
user_id=21627

This has been fixed in _localemodule.c 2.28. IMO, it is not
critical enough for 2.2.1, but a backport of the patch to
2.2.2 will be considered.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534153&group_id=5470



From noreply@sourceforge.net  Fri Apr 19 23:59:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 15:59:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-522274 ] compiler/transformer.py STARSTAR doesn't exist
Message-ID: <E16yhLq-0000zP-00@usw-sf-web1.sourceforge.net>

Bugs item #522274, was opened at 2002-02-25 01:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522274&group_id=5470

Category: Parser/Compiler
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Evelyn Mitchell (efm)
Assigned to: Jeremy Hylton (jhylton)
Summary: compiler/transformer.py STARSTAR doesn't exist

Initial Comment:
pyChecker complains at line 774 of tokenizer.py
No module attribute (STARSTAR) found

The section is:

                if i < len(nodelist):
                    # should be DOUBLESTAR or STAR STAR
                    t = nodelist[i][0]
                    if t == token.DOUBLESTAR:
                        node = nodelist[i+1]
                    elif t == token.STARSTAR:
                        node = nodelist[i+2]
                    else:
                        raise ValueError, "unexpected
token: %s" % t
                    names.append(node[1])
                    flags = flags | CO_VARKEYWORDS

I've verified that there is no STARSTAR in token.py.
I'd patch this to be token.STAR, which does exist, but
this module has no self tests or unit tests, so I
wouldn't be able to know if it broke anything.

My wild guess is that the intention is to refer to two
STAR tokens rather than a DOUBLESTAR token (and that is
because the increment is 2 rather than 1), but I think
that evidence is pretty slim.

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-19 22:59

Message:
Logged In: YES 
user_id=31392

Fixed in rev 1.33 of transformer.py
and in rev 1.80.8.1.2.1 (release22-maint branch).
Not present in earlier versions.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-16 19:21

Message:
Logged In: YES 
user_id=6380

I think the STARSTAR should be STAR.  Jeremy, can you
confirm & fix? Also, there needs to be a unittest for this
code, apparently!

----------------------------------------------------------------------

Comment By: Evelyn Mitchell (efm)
Date: 2002-03-16 16:18

Message:
Logged In: YES 
user_id=13263

Sorry, too much caffine. 

The file is compiler/transformer.py

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-03-10 18:48

Message:
Logged In: YES 
user_id=92689

I don't see a file "tokenizer.py" in the repository, only 
"tokenize.py", which only has 262 lines. What is this 
bug about?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=522274&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 05:21:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 21:21:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-507477 ] Py_CompileString and tracebacks
Message-ID: <E16ymNb-0003Iu-00@usw-sf-web1.sourceforge.net>

Bugs item #507477, was opened at 2002-01-23 12:44
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Krzysztof Zych (badpenguin)
Assigned to: Jeremy Hylton (jhylton)
Summary: Py_CompileString and tracebacks

Initial Comment:
The API docs say, that when compiling a string with Py_Compilestring(code, filename, start), the filename param is used to construct the code object and may appear in tracebacks. Exceptions generated from these compiled objects evaluated with PyEval_EvalCode do not show this valuable description. This does not, somehow, apply when using Python's compile() and eval().

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-20 04:21

Message:
Logged In: YES 
user_id=31392

Just noticed the attached program.  PyRun_SimpleString() is
not the same as PyEval_EvalCode(), so they don't behave the
same.   In particular, PyRun... has a call to
PyErr_Print().  If you check the return value of
PyEval_EvalCode() in your demo, you'll find that it is NULL,
which indicates an error.  If you call PyErr_Print(), you'll
see the same traceback that PyRun... produces.
 

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-12 23:11

Message:
Logged In: YES 
user_id=31392

Can you explain in more detail what you think the bug is? 
Or are there multiple bugs?  From your description, it
sounds like something isn't right, but I can't tell exactly
what you'd like to see fixed.  A small example would help.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=507477&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 06:14:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 19 Apr 2002 22:14:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-505315 ] free vars sometimes show up in locals()
Message-ID: <E16ynD4-0003iH-00@usw-sf-web1.sourceforge.net>

Bugs item #505315, was opened at 2002-01-18 10:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cesar Douady (douady)
Assigned to: Jeremy Hylton (jhylton)
Summary: free vars sometimes show up in locals()

Initial Comment:
Python 2.2 under Linux.

Whether free variables are part of the local dictionary
or not is
unclear from the doc, but certainly the following
description is buggy:

> in :
>
> def foo():
>     x=1
>     def bar():
>         x
>         print locals()
>     bar()
> foo()
>
> the result is "{}", indicating that x is not in
locals(). But in :
>
> def foo():
>     x=1
>     def bar():
>         x
>         y=1
>         print locals()
>     bar()
> foo()
>
> the result is "{'y':1, 'x':1}", indicating that the
presence of y has
> made x part of locals().

The above is supported by Michael Hudson and he
suggested to assign this
bug report to Jeremy.

Also in :

def foo():
    x=1
    class bar:
        x
        y=1
    print dir(bar)
foo()

the result is "['__doc__', '__module__', 'y']", showing
that x was not
included.

This means that the local dictionary for a class (which
is supposed to
make up the class dictionary) and for a function is not
the same if free
variables are ever to be considered as part of the
local dictionary.

Looking at the interpreter code, the problem lies in
PyFrame_FastToLocals() (Objects/frameobject.c:406)
where there is a test
for (f->f_nlocals == NULL) which prevents free and cell
variables from
being transfered.
It is unclear whether this is an optimization fossile
from before nested
scopes or whether this is done on purpose to
differenciate the behavior
between functions (which almost always have locals) and
classes (for
which nlocals is 0 when PyFrame_FastToLocals is called).

In my opinion, the test should be suppressed and cell
variables should not be transfered to the local dict,
but this breaks the current test suite (in particular
test_scope).

----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-20 05:14

Message:
Logged In: YES 
user_id=31392

Fixed in rev 2.62 of frameobject.c
and in rev 2.59.6.3 on the 2.2 branch

Still needs to be backported in 2.1 branch, but that has
other nested scopes bugs to fix, too.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-13 21:41

Message:
Logged In: YES 
user_id=31392

Yes.  I think cell variables should always be transferred.

Free variables should if eval() is supposed to work as
currently advertised, but I don't think that's desirable.


----------------------------------------------------------------------

Comment By: Cesar Douady (douady)
Date: 2002-01-18 13:48

Message:
Logged In: YES 
user_id=428521

I made a typo in the last paragraph.
I actually meant cell variables should always be transfered
to the local dict while free variables should not.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=505315&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 08:21:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 20 Apr 2002 00:21:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E16ypBe-0004iz-00@usw-sf-web1.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
Assigned to: Nobody/Anonymous (nobody)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 08:36:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 20 Apr 2002 00:36:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-546434 ] buffer slice type inconsistant
Message-ID: <E16ypPu-0003LV-00@usw-sf-web2.sourceforge.net>

Bugs item #546434, was opened at 2002-04-20 03:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Donald Wallace Rouse II (dwr2)
Assigned to: Nobody/Anonymous (nobody)
Summary: buffer slice type inconsistant

Initial Comment:
The type of a buffer slice is either 'buffer' 
or 'str', depending on the slice parameters.
If the slice encompasses the entire buffer, the buffer 
itself is returned.
Otherwise, a string is returned.
Here is a sample session:
--------------------------
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "copyright", "credits" or "license" for more 
information.
IDLE 0.8 -- press F1 for help
>>> a="0123456789"
>>> b = buffer(a, 1, 8)
>>> b
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[:8]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C5, size 
8 at 0x00A99F30>
>>> b[2:4]
'34'
>>> b[5]
'6'
>>> c = buffer(a, 4, 1)
>>> c
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
>>> c[0]
'4'
>>> c[0:1]
<read-only buffer for 0x0079B4B0, ptr 0x0079B4C8, size 
1 at 0x00AAA370>
--------------------------
Either b[:] should produce a string, or, more 
preferably, b[x:y] should be equivalent to buffer(b, 
x, y), and c[0] should be equivalent to buffer(c, 0, 
1).
The reason that the types should be similar is because 
if a buffer is passed to a function that's checking 
for strings, the function should always fail or always 
succeed.

This is especially important because types.BufferType 
isn't in the types.StringTypes list, so the 
expression "type(b) in types.StringTypes" will also 
behave inconsistantly.

----------------------------------------------------------------------

>Comment By: Donald Wallace Rouse II (dwr2)
Date: 2002-04-20 03:36

Message:
Logged In: YES 
user_id=111611

Sorry about the formatting; the form wrapped the lines.
A slight correction:
  "b[x:y] should be equivalent to buffer(b, x, y)"
should be
"b[x:y] should be equivalent to buffer(b, x1, y1 - x1), 
where x1 == x if x is positive and len(b) + x if x is 
negative, and similarly for y and y1".

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546434&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 08:53:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 20 Apr 2002 00:53:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-544234 ] httplib cannot talk SSL to MS IIS
Message-ID: <E16ypgw-0001wV-00@usw-sf-web3.sourceforge.net>

Bugs item #544234, was opened at 2002-04-15 17:53
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544234&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib cannot talk SSL to MS IIS

Initial Comment:
This is a duplicate of bug 494762. That bug was closed 
as "invalid", however what I don't think was 
appreciated at the time is that it is not just that 
one server that has this problem, it is a generic 
problem with MS IIS servers.

The choices are:

  (a) leave the code like it is, Python can't talk SSL 
to MS IIS servers
  (b) persuade Microsoft to fix their code, and then 
persuade every MS IIS installation on the planet to 
upgrade
  (c) put a work-around in the Python code

Since I hope that both (a) and (b) are obviously 
unacceptable, I think a suitable work-around would be 
to add another clause to the except statement in 
FakeSocket.makefile as follows:

  if err[1] == "EOF occurred in violation of protocol":
    break

i.e. treat that error as EOF, because that's what it 
actually means.

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-20 09:53

Message:
Logged In: YES 
user_id=21627

This is now fixed with patch 500311.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-15 23:24

Message:
Logged In: YES 
user_id=21627

Can you please try http://python.org/sf/500311? Feedback on
this patch would be much appreciated.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544234&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 14:46:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 20 Apr 2002 06:46:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-495401 ] Build troubles: --with-pymalloc
Message-ID: <E16yvBr-0008UX-00@usw-sf-web1.sourceforge.net>

Bugs item #495401, was opened at 2001-12-20 14:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Walter D�rwald (doerwalter)
Assigned to: Martin v. L�wis (loewis)
Summary: Build troubles: --with-pymalloc

Initial Comment:
The build process segfaults with the current CVS 
version when using --with-pymalloc

System is SuSE Linux 7.0

> uname -a
Linux amazonas 2.2.16-SMP #1 SMP Wed Aug 2 20:01:21 
GMT 2000 i686 unknown
> gcc -v
Reading specs from /usr/lib/gcc-lib/i486-suse-
linux/2.95.2/specs
gcc version 2.95.2 19991024 (release)

Attached is the complete build log.


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-20 15:46

Message:
Logged In: YES 
user_id=21627

I have now applied unicode3.diff as unicodeobject.c 2.140,
adding the assertion that the allocated and the used number
of bytes are identical. If this problem ever occurs again,
the assertion will indicate what the problem is.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-11 08:26

Message:
Logged In: YES 
user_id=21627

I've revised the patch unicode3.diff to the current code
base (it still includes the assertion at the end); I've also
added a new timing test (utim3.py) which considers the
following cases:
- a string consisting of only spaces
- a string consisting of only spaces, and a single character
that needs three bytes in UTF-8
- a string only consisting of characters that need three bytes.

For all three cases, it tests various sizes of the string,
both below and above the pymalloc threshold. For the current
CVS (unicodeobject.c 2.136: MAL's change to use a variable
overalloc), I get

10 spaces                      20.060
100 spaces                     2.600
200 spaces                     2.030
1000 spaces                    0.930
10000 spaces                   0.690
10 spaces, 3 bytes             23.520
100 spaces, 3 bytes            3.730
200 spaces, 3 bytes            2.470
1000 spaces, 3 bytes           0.980
10000 spaces, 3 bytes          0.690
30 bytes                       24.800
300 bytes                      5.220
600 bytes                      3.830
3000 bytes                     2.480
30000 bytes                    2.230

With unicode3.diff, I get

10 spaces                      19.940
100 spaces                     3.260
200 spaces                     2.340
1000 spaces                    1.650
10000 spaces                   1.450
10 spaces, 3 bytes             21.420
100 spaces, 3 bytes            3.410
200 spaces, 3 bytes            2.420
1000 spaces, 3 bytes           1.660
10000 spaces, 3 bytes          1.450
30 bytes                       22.260
300 bytes                      5.830
600 bytes                      4.700
3000 bytes                     3.740
30000 bytes                    3.540

So it appears that unicode3.diff is more efficient for short
strings, and overallocation is more efficient for long
strings. Since overallocation may waste memory, I still
recommend to integrate unicode3.diff.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-13 13:39

Message:
Logged In: YES 
user_id=38388

Tim, I ran the test on my notebook and guess what:

when compiling Python with -mcpu=pentium I get
    58 vs. 59.8 (with / without patch)

when compiling Python with -mcpu=i686, it's
    65.8 vs. 60.17 (with / without patch)

No idea what chip is used in the notebook.
It's pretty old, though. I used gcc 2.95.2 and
some old SuSE Linux version (glibc 2).

Would be interesting to check this on a 
modern pentium 4 machine and maybe
a more recent sun sparc machine. Oh yes,
and your Cray, of coure ;-)


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 22:06

Message:
Logged In: YES 
user_id=31435

MAL, cool -- I saw a major slowdown using the patch too, 
but not nearly as dramatic as you saw, so was curious about 
what could account for that.  Chip, compiler and OS can all 
have major effects.

I assume Martin is using a Pentium box, so assuming your 
notebook is running Linux too, it would be good to get 
another LinTel datapoint.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-11 21:50

Message:
Logged In: YES 
user_id=38388

Tim: Yes, I'm still all AMD based... it's Athlon 1200 I'm 
running. PGCC (the Pentium GCC groups version) has
a special AMD optimization mode for Athlon which is
what I'm using. Somebody has to hold up the flag against
the Wintel camp ;-)

Hmm, I could do the same tests on my notebook which
runs on one of those Inteliums. Maybe tomorrow...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-02-11 21:06

Message:
Logged In: YES 
user_id=31435

time.time() sucks for benchmarking on Windows (updates at 
about 18Hz).  Running the test as-is, MSVC6 and Win98SE, 
it's 1.3 seconds with current CVS, and 1.7 with 
unicode3.diff.

The quantization error in Windows time.time() is > 0.05 
seconds, so no point pretending there are 3 significant 
digits there; luckily(?), it's apparent there's a major 
difference with just 2 digits.

MAL, are you still using an AMD box?  In a decade, nobody 
else has ever reproduced the timing results you see <wink>.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-11 19:42

Message:
Logged In: YES 
user_id=38388

Ok, with 100000 loops and time.clock() I get:
4.690 - 4.710 without your patch,
9.560 - 9.570 with your patch
(again, without pymalloc and the same compiler/machine
on SuSE 7.1).


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-11 19:04

Message:
Logged In: YES 
user_id=21627

time.clock vs. time.time does not make a big difference on
an unloaded machine (except time.time has a higher resolution).
Can you please run the test 10x more often? I then get
12.520 clocks with CVS python, glibc 2.2.4, gcc 2.95, and
10.890 with my patch.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-11 18:49

Message:
Logged In: YES 
user_id=38388

I get different timings (note that you have to use time.clock() for 
benchmarks, not time.time()):

without your patch: 0.470 seconds
with your patch: 0.960 seconds

This is on Linux with pgcc 2.95.2, glibc 2.2, without pymalloc
(which is the normal configuration).

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-11 18:06

Message:
Logged In: YES 
user_id=21627

Marc: Please have a look at pymalloc; it cannot be "fixed".
It is in the nature of a pool allocator that you have to
copy when you want to move between pools - or you have to
waste the extra space.

I agree that UTF-8 coding needs to be fast; that's why I
wrote this patch. I've revised it to fit the current
implementation, and too add the assert that Tim has
requested (unicode3.diff).

For the test case time_utf8.zip (which is a UTF-8 converted
Misc/ACKS), the version that first counts the size is about
10% faster on my system (Linux glibc 2.2.4) (see timings
inside time_utf8.py; #592 is the patched version). So the
price for counting the size turns out to be negligible, and
to offer significant, and is more than compensated for by
the reduction of calls to the memory management system.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-08 23:27

Message:
Logged In: YES 
user_id=38388

Good news, Walter.

Martin:
As I explained in an earlier comment, pymalloc needs to be fixed to better address overallocation. The two pass 
logic would avoid overallocation, but at a high price. Copying memory (if at all needed) is likely to be *much* faster. 
The UTF-8 codec has to be as fast as possible since it is one of the most used codecs in Python's Unicode 
implementation. Also note that I have reduced overallocation to 2*size in the codec.

I suggest to close the bug report.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-07 23:59

Message:
Logged In: YES 
user_id=21627

I still think the current algorithm has serious problems as 
it is based on overallocation, and that it should be 
replaced with an algorithm that counts the memory 
requirements upfront. This will be particularly important 
for pymalloc, but will also avoid unnecessary copies for 
many other malloc implementations.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-02-07 10:58

Message:
Logged In: YES 
user_id=89016

I tried the current CVS and make altinstall runs to 
completion.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-06 19:12

Message:
Logged In: YES 
user_id=38388

I've checked in a patch which fixes the memory allocation problem. Please give it a try and tell me whether this 
fixes your problem, Walter. If so, I'd suggest to close the bug.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-31 20:36

Message:
Logged In: YES 
user_id=31435

Martin, I like your second patch fine, but would like it a 
lot better with

assert(p - PyString_AS_STRING(v) == cbAllocated);

at the end.  Else a piddly change in either loop can cause 
more miserably hard-to-track-down problems.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-31 14:46

Message:
Logged In: YES 
user_id=21627

MAL,
I'm 100% positive that the crash on my system was caused by
the UTF-8 encoding; I've seen it in the debugger overwrite
memory that it doesn't own.

As for unicode.diff: Tim has proposed that this should not
be done, but that 4*size should be allocated in advance.
What do you think?

On unicode2.diff: If pymalloc was changed to shrink the
memory, it would have to copy the original string, since it
would likely be in a different size class. This is less
efficient than the approach taken in unicode2.diff. What
specifically is it that you dislike about first counting the
memory requirements? 

It actually simplifies the code. Notice that the current
code is still buggy with regard to surrogates. If there is a
high surrogate, but not a low one, it will write bogus UTF-8
 (with no lead byte). This is fixed in unicode2.diff as well.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-12-31 13:48

Message:
Logged In: YES 
user_id=38388

I like the unicode.diff, but not the unicode2.diff. Instead of fixing the UTF-8 codec here we should fix the 
pymalloc implementation, since overallocation is common thing to do and not only used in codecs. (Note 
that all Python extensions will start to use pymalloc too once we enable it per default.)

I don't know whether it's relevant, but I found that core dumps can easily be triggered by mixing the 
various 
memory allocation APIs in Python and the C lib. The bug may not only be related to the UTF-8 codec but 
may also linger in some other extension modules.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-30 11:26

Message:
Logged In: YES 
user_id=21627

I disabled threading, which fortunately gave me memory
watchpoints back. Then I noticed that the final *p=0
corrupted a non-NULL freeblock pointer, slightly decreasing
it. Then following the freeblock pointer, freeblock was
changed to a bogus block, which had its next pointer as
garbage. I had to trace this from the back, of course.

As for overallocation, I wonder whether the UTF-8 encoding
should overallocate at all. unicode2.diff is a modification
where it runs over the string twice, counting the number of
needed bytes the first time. This is likely slower (atleast
if no reallocations occur), but doesn't waste that much
memory (I notice that pymalloc will never copy objects when
they shrink, to return the extra space).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-30 04:54

Message:
Logged In: YES 
user_id=31435

Good eye, Martin!  It's clearly possible for the unpatched 
code to write beyond the memory allocated.  The one thing 
that doesn't jibe is that you said bp is 0x2, which means 3 
of its 4 bytes are 0x00, but UTF-8 doesn't produce 0 bytes 
except for one per \u0000 input character.  Right?  So, if 
this routine is the cause, where are the 0 bytes coming 
from?  (It could be test_unicode sets up a UTF-8 encoding 
case with several \u0000 characters, but if so I didn't 
stumble into it.)  Plausible:  when a new pymalloc "page" 
is allocated, the 40-byte chunks in it are *not* linked 
together at the start.  Instead a NULL pointer is stored at 
just the start of "the first" 40-byte chunk, and pymalloc-- 
on subsequent mallocs --finds that NULL and incrementally 
carves out additional 40-byte chunks.  So as a startup-- 
but not a steady-state --condition, the "next free block" 
pointers will very often be NULLs, and then if this is a 
little-endian machine, writing a single 2 byte at the start 
of a free block would lead to a bogus pointer value of 0x2.

About a fix, I'm in favor of junking all the cleverness 
here, by allocating size*4 bytes from the start.  It's 
overallocating in all normal cases already, so we're going 
to incur the expense of cutting the result string back 
anyway; how *much* we overallocate doesn't matter to speed, 
except that if we don't have to keep checking inside the 
loop, the code gets simpler and quicker and more robust.  
The loop should instead merely assert that cbWritten <= 
cbAllocated at the end of each trip.  Had this been done 
from the start, a debug build would have assert-failed a 
few nanoseconds after the wild store.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-30 02:44

Message:
Logged In: YES 
user_id=21627

I've found one source of troubles, see the attached
unicode.diff. Guido's intuition was right; it was an UCS-4
problem: EncodeUTF8 would over-allocate 3*size bytes, but
can actually write 4*size in the worst case, which occurs in
test_unicode.

I'll leave the patch for review and experiments; it fixes
the problem for me.

The existing adjustment for surrogates is pointless, IMO:
for the surrogate pair, it will allocate 6 bytes UTF-8 in
advance, which is more than actually needed.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-30 00:13

Message:
Logged In: YES 
user_id=21627

It's a Heisenbug. I found that even slightest modifications
to the Python source make it come and go, or appear at
different places. On my system, the crashes normally occur
in the first run (.pyc). So I don't think the order of make
invocations is the source of the problem. It's likely as Tim
says: somebody overwrites memory somewhere.

Unfortunately, even though I can reproduce crashes for the
same pool, for some reason, my gdb memory watches don't
trigger. Tim's approach of checking whether a the value came
from following the free list did not help, either: the bug
disappeared under the change.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-29 23:01

Message:
Logged In: YES 
user_id=6656

Hmm.  I now think that the stuff about extension modules is 
almost certainly a read herring.  What I said about "make && 
make altinstall" vs "make altinstall" still seems to be true, 
though.

If you compile with --with-pydebug, you crash right at the 
end of the second (-O) run of compileall.py -- I suspect this 
is something else, but it might not be.


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2001-12-29 22:29

Message:
Logged In: YES 
user_id=6656

I don't know if these are helpful observations or not, but 
anyway:

(1) it doesn't core without the --enable-unicode=ucs4 option
(2) if you just run "make altinstall"  the library files are 
installed *and compiled* before the dynamically linked 
modules are built.  Then we don't crash.
(3) if you run "make altinstall" again, we crash.
If you initially ran "make && make install", we crash.
(4) when we crash, it's not long after the unicode tests are 
compiled.

Are these real clues or just red herrings?  I'm afraid I 
can't tell :(


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-29 19:43

Message:
Logged In: YES 
user_id=31435

Ouch.  Boosted priority back to 5, since Martin can 
reproduce it.  Alas, where pymalloc got called *from* is 
almost certainly irrelevant -- we're seeing the end result 
of earlier corruption.

Note that pymalloc is unusually sensitive to off-by-1 
stores, since the chunks it hands out are contiguous 
(there's no hidden bookkeeping padding between them).  
Plausible:  an earlier bogus store went beyond the end of 
its allocated chunk, overwriting the "next free block" 
pointer at the start of a previously free()'ed chunk of the 
same size (rounded up to a multiple of 8; 40 bytes in this 
case).

At the time this blows up, bp is supposed to point to a 
previously free()'ed chunk of size 40 bytes (if there were 
none free()'ed and available, the earlier "pool != pool-
>nextpool" guard should have failed).  The first 4 bytes 
(let's simplify by assuming this is a 32-bit box) of the 
free chunks link the free chunks together, most recently 
free()'ed at the start of the (singly linked) list.  So the 
code at this point is intent on returning bp, and "pool-
>freeblock = *(block **)bp" is setting the 40-byte-chunk 
list header's idea of the *next* available 40-byte chunk.

But bp is bogus.  The value of bp is gotten out of the free 
list headers, the static array usedpools.  This mechanism 
is horridly obscure, an array of pointer pairs that, in 
effect, capture just the first two members of the 
pool_header struct, once for each chunk size.  It's 
possible that someone is overwriting usedpools[4 + 4]-
>freeblock directly with 2, but that seems unlikely.

More likely is that a free() operation linked a 40-byte 
chunk into the list headed at usedpools[4+4]->freeblock 
correctly, and a later bad store overwrote the first 4 
bytes of the free()'ed block with 2.  Then the "pool-
>freeblock = *(block **)bp)" near the start of an 
unexceptional pymalloc would copy the 2 into the list 
header's freeblock without complaint.  The error wouldn't 
show up until a subsequent malloc tried to use it.

So that's one idea to get closer to the cause:  add code to 
dereference pool->freeblock, before the "return (void *)
bp".  If that blows up earlier, then the first four bytes 
of bp were corrupted, and that gives you a useful data 
breakpoint address for the next run.  If it doesn't blow up 
earlier, the corruption will be harder to find, but let's 
count on being lucky at first <wink>.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-29 17:00

Message:
Logged In: YES 
user_id=21627

Ok, I can reproduce it now; I did not 'make install' before.
Here is a gdb back trace

#0  _PyCore_ObjectMalloc (nbytes=33) at Objects/obmalloc.c:417
#1  0x805885c in PyString_FromString (str=0x816c6e8
"checkJoin") at Objects/stringobject.c:136
#2  0x805d772 in PyString_InternFromString (cp=0x816c6e8
"checkJoin") at Objects/stringobject.c:3640
#3  0x807c9c6 in com_addop_varname (c=0xbfffe87c, kind=0,
name=0x816c6e8 "checkJoin")
    at Python/compile.c:939
#4  0x807de24 in com_atom (c=0xbfffe87c, n=0x816c258) at
Python/compile.c:1478
#5  0x807f01c in com_power (c=0xbfffe87c, n=0x816c8b8) at
Python/compile.c:1846
#6  0x807f545 in com_factor (c=0xbfffe87c, n=0x816c898) at
Python/compile.c:1975
#7  0x807f56c in com_term (c=0xbfffe87c, n=0x816c878) at
Python/compile.c:1985
#8  0x807f6bc in com_arith_expr (c=0xbfffe87c, n=0x816c858)
at Python/compile.c:2020
#9  0x807f7dc in com_shift_expr (c=0xbfffe87c, n=0x816c838)
at Python/compile.c:2046
#10 0x807f8fc in com_and_expr (c=0xbfffe87c, n=0x816c818) at
Python/compile.c:2072
#11 0x807fa0c in com_xor_expr (c=0xbfffe87c, n=0x816c7f8) at
Python/compile.c:2094
...

The access that crashes is *(block **)bp, since bp is 0x2.

Not sure how that happens; I'll investigate (but would
appreciate a clue). It seems that the pool chain got corrupted.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-29 15:52

Message:
Logged In: YES 
user_id=6380

Aha!  The --enable-unicode=ucs4 is more suspicious than the
--with-pymalloc. I had missed that info when this was first
reported.

Not that I'm any closer to solving it... :-(

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2001-12-29 11:53

Message:
Logged In: YES 
user_id=89016

OK, I did a "make distclean" which removed .o files and
the build directory and redid a "./configure --enable-
unicode=ucs4 --with-pymalloc && make && make altinstall".

The build process still crashes in the same spot:
Compiling /usr/local/lib/python2.2/test/test_urlparse.py ...
make: *** [libinstall] Segmentation fault

I also retried with a fresh untarred Python-2.2.tgz. This 
shows the same behaviour.



----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-29 10:23

Message:
Logged In: YES 
user_id=21627

Atleast I cannot reproduce it, on SuSE 7.3. Can you retry
this, building from a clean source tree (no .o files, no
build directory)?

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-28 23:30

Message:
Logged In: YES 
user_id=6380

My prediction: this is irreproducible. Lowering the priority
accordingly.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2001-12-23 13:24

Message:
Logged In: YES 
user_id=89016

Unfortunately no core file was generated. Can I somehow 
force core file generation?

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-12-22 15:42

Message:
Logged In: YES 
user_id=21627

Did that produce a core file? If so, can you attach a gdb
backtrace as well?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=495401&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 19:34:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 20 Apr 2002 11:34:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-546558 ] Windows getpass bug
Message-ID: <E16yzgY-0000ZE-00@usw-sf-web4.sourceforge.net>

Bugs item #546558, was opened at 2002-04-20 18:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470

Category: Windows
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Tim Peters (tim_one)
Summary: Windows getpass bug

Initial Comment:
I'm currently running Python 2.2.1 on a Windows 98 
box, and this is the code I have just run.

-------

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import getpass
>>> def x():
...    secret = getpass.getpass('Tell me a secret: ')
...    stuff = raw_input ('Tell me something else: ')
...    print 'The user told me the secret was "%s" and 
the other thing was "%s"'
 % (secret, stuff)
...
>>> x()
Tell me a secret:
Tell me something else:
The user told me the secret was "Autechre" and the 
other thing was ""
>>>

-------

This may seem normal, but I didn't get the opportunity 
to enter anything when the raw_input was called. I'm 
assuming that getpass leaves the newline character in 
the input buffer, which is then used by raw_input, 
leaving you unable to enter anything.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 21:10:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 20 Apr 2002 13:10:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-546558 ] Windows getpass bug
Message-ID: <E16z1Bi-0004CV-00@usw-sf-web1.sourceforge.net>

Bugs item #546558, was opened at 2002-04-20 14:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470

Category: Windows
>Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
>Assigned to: Mark Hammond (mhammond)
Summary: Windows getpass bug

Initial Comment:
I'm currently running Python 2.2.1 on a Windows 98 
box, and this is the code I have just run.

-------

Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for 
more information.
>>> import getpass
>>> def x():
...    secret = getpass.getpass('Tell me a secret: ')
...    stuff = raw_input ('Tell me something else: ')
...    print 'The user told me the secret was "%s" and 
the other thing was "%s"'
 % (secret, stuff)
...
>>> x()
Tell me a secret:
Tell me something else:
The user told me the secret was "Autechre" and the 
other thing was ""
>>>

-------

This may seem normal, but I didn't get the opportunity 
to enter anything when the raw_input was called. I'm 
assuming that getpass leaves the newline character in 
the input buffer, which is then used by raw_input, 
leaving you unable to enter anything.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-20 16:10

Message:
Logged In: YES 
user_id=31435

Assigning to MarkH in case he has a bright idea.  I don't.

The problem is that getpass on Windows is implemented via 
raw Windows console I/O, and console I/O buffers interact 
in strange and undocumented ways with C's stdio buffers.  
I've never found a reliable way to keep them in synch, and 
MS says you can't mix the two, period.  The only workaround 
I know of is to build your own raw_input() workalike out of 
the msvcrt module's console I/O routines (getch(), etc).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546558&group_id=5470



From noreply@sourceforge.net  Sat Apr 20 21:14:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 20 Apr 2002 13:14:26 -0700
Subject: [Python-bugs-list] [ python-Bugs-546579 ] Nested anchors in Ref Man index.html
Message-ID: <E16z1Fa-0004F3-00@usw-sf-web1.sourceforge.net>

Bugs item #546579, was opened at 2002-04-20 16:14
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546579&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Nested anchors in Ref Man index.html

Initial Comment:
God only knows what Soureforge will do to this:

"""
This line from the 2.2 Doc/ref/index.html confuses 
prechm.py:

<LI><A href="blank-lines.html">
2.1.6 Blank lines <a name="l2h-7">&nbsp;</a>
</a>

Nested <a></a> in general gives it trouble, and this 
one is particularly weird.
"""

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546579&group_id=5470



From noreply@sourceforge.net  Sun Apr 21 14:11:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 21 Apr 2002 06:11:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-546749 ] odd exception moving file to trash
Message-ID: <E16zH7s-00054e-00@usw-sf-web4.sourceforge.net>

Bugs item #546749, was opened at 2002-04-21 15:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: odd exception moving file to trash

Initial Comment:
MacPython 2.2.1 on OSX.1.4, from IDE:
>>> import macfs, findertools
>>> f = open("a_file_to_trash", "w")
>>> f.close()
>>> fss = macfs.FSSpec("a_file_to_trash")
>>> vrefnum = fss.as_tuple()[0]
>>> vrefnum, pardir = macfs.FindFolder(vrefnum, 
"trsh", 1)
>>> trashfolder = macfs.FSSpec((vrefnum, pardir, 
"")).as_pathname()
>>> findertools.move("a_file_to_trash", 
trashfolder)
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:findertools.py", line 74, in move
    return finder.move(src_fss, to=dst_fss)
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:lib-
scriptpackages:Finder:Standard_Suite.py", line 
293, in move
    raise aetools.Error, 
aetools.decodeerror(_arguments)
aetools.Error: (0, 'component result = no error', 
None)
>>> 

The file _does_ get moved to the trash, but that's 
not visible in the Finder's Trash window, not even 
after more items are dragged to the trash 
manually.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470



From noreply@sourceforge.net  Sun Apr 21 16:04:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 21 Apr 2002 08:04:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-544265 ] gcc warning in Modules/readline.c
Message-ID: <E16zIss-0005vH-00@usw-sf-web4.sourceforge.net>

Bugs item #544265, was opened at 2002-04-15 12:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544265&group_id=5470

Category: Build
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Walter D�rwald (doerwalter)
Assigned to: Nobody/Anonymous (nobody)
Summary: gcc warning in Modules/readline.c

Initial Comment:
gcc 2.96 on Linux (RedHat 7.1) issues the following 
warning when compiling Modules/readline 2.47:
Modules/readline.c: In function `set_completer_delims':
Modules/readline.c:273: warning: passing arg 1 of 
`free' 
discards qualifiers from pointer target type


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=544265&group_id=5470



From noreply@sourceforge.net  Sun Apr 21 16:33:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 21 Apr 2002 08:33:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16zJLV-00067w-00@usw-sf-web4.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Duncan Booth (duncanb)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 00:19:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 21 Apr 2002 16:19:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-546156 ] load_false/true() not used
Message-ID: <E16zQbo-00050o-00@usw-sf-web1.sourceforge.net>

Bugs item #546156, was opened at 2002-04-19 10:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546156&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: load_false/true() not used

Initial Comment:
Guido, in cPickle, load_false() & load_true() aren't
used.  I suspect this was due to the late change to
pickling.  Is there any reason to keep these?  If not,
assign back to be and I'll remove them.

Neal


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-21 19:19

Message:
Logged In: YES 
user_id=6380

Oops, you're right. Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546156&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 00:45:27 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 21 Apr 2002 16:45:27 -0700
Subject: [Python-bugs-list] [ python-Bugs-546156 ] load_false/true() not used
Message-ID: <E16zR1L-0001o9-00@usw-sf-web3.sourceforge.net>

Bugs item #546156, was opened at 2002-04-19 10:34
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546156&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: load_false/true() not used

Initial Comment:
Guido, in cPickle, load_false() & load_true() aren't
used.  I suspect this was due to the late change to
pickling.  Is there any reason to keep these?  If not,
assign back to be and I'll remove them.

Neal


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-21 19:19

Message:
Logged In: YES 
user_id=6380

Oops, you're right. Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546156&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 00:46:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 21 Apr 2002 16:46:14 -0700
Subject: [Python-bugs-list] [ python-Bugs-546913 ] #!/usr/bin/python -u -E doesn't work.
Message-ID: <E16zR26-0005HB-00@usw-sf-web1.sourceforge.net>

Bugs item #546913, was opened at 2002-04-21 23:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Landley (landley)
Assigned to: Nobody/Anonymous (nobody)
Summary: #!/usr/bin/python -u -E doesn't work.

Initial Comment:
In linux create an executable file.py with the first 
line:

#!/usr/bin/python -u -E

It doesn't matter WHAT the rest of the file is, it 
won't work.

If you feed it both of those arguments, the python 
interpreter complalins that "-" is an unknown 
argument. (?)  I tried replacing python with "echo" 
and the command line it was getting was "-u -E 
./file.py", and "python -u -E ./file.py" works just 
fine when I feed that to python from an interactive 
bash command line.

Feeding it just "-E" in the #! arguments works fine, 
but you can't combine select.poll with file.read(), 
and without -u, if you combine os.read() with 
file.readline() it takes a 4k chunk out of stdin that 
you can't get it to cough back up with a crowbar...

I'm using python 2.2 compiled from source on an 
approximately Red Hat 7.2 system, if that makes a 
difference.  (I checked the ancient python 1.5 that 
comes with Red Hat and yup: same bug.)

I am about to go create a bash script for the purpose 
of calling the python program in such a way as to not 
trigger this bug...

Rob


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546913&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 10:31:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 02:31:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-532860 ] NameError assigning to class in a func
Message-ID: <E16zaAw-0007p3-00@usw-sf-web3.sourceforge.net>

Bugs item #532860, was opened at 2002-03-21 12:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Jeremy Hylton (jhylton)
Summary: NameError assigning to class in a func

Initial Comment:
This fails with a NameError:

def f(x)
    class Private:
        x = x
    return Private
f(17)

But this works:

def f(x):
    y = x
    class Private:
        x = y
    return Private
f(17)

But this fails:

def f(x):
    y = x
    class Private:
        y = y
    return Private
f(17)

See also the newsgroup thread:
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=Xns

(All tested on Python 2.2 on Win2k)



----------------------------------------------------------------------

>Comment By: Andrew Bennetts (spiv)
Date: 2002-04-22 19:31

Message:
Logged In: YES 
user_id=50945

Apologies for re-opening the bug.

This behaviour still seems like a bug to me, because while
this dies:

>>> def f(x):
...     class Private:
...         x = x
...     return Private
... 
>>> f(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 2, in f
  File "<stdin>", line 3, in Private
NameError: name 'x' is not defined

This works:

>>> x = 1 
>>> class C:
...     x = x
... 
>>> C()
<__main__.C instance at 0x806aeac>

Actually, having the global "x = 1" also makes the first
case work.

This seems inconsistent enough to me to warrant it being
called a bug, regardless of the underlying implementation
details (which I know little of).  I'd expect it work in
both cases, or neither case.

Feel free to close the bug again if you disagree :)

It's quite easy to work around, so I'm not worried greatly
by it.
(workaround:
def f(x):
    class Private:
         pass
    Private.x = x
    return Private
)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-20 02:39

Message:
Logged In: YES 
user_id=31392

This is actually working as intended, although the reference
manual no longer describes this case at all.  It has been a
long standing "feature" of Python that module and class
blocks use the LOAD_NAME opcode, which has weird scoping
rules.

The documentation should be updated to describe the cases in
which LOAD_NAME is used and its behavior.  (It checks
locals, globals, builtins in that order, and never raises a
NameError unless the name isn't found in any of those
namespaces.  In particular, an unbound local is simply
ignored.)

I don't actually know what these rules are used.  Guido--
should we get rid of LOAD_NAME?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 12:12:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 04:12:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-546117 ] readlines() bombs - last line incomplete
Message-ID: <E16zbjv-000458-00@usw-sf-web1.sourceforge.net>

Bugs item #546117, was opened at 2002-04-19 13:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470

>Category: Python Interpreter Core
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: readlines() bombs - last line incomplete

Initial Comment:
HP-UX 11 64bit, compiled with HP ansi c compiler.
Python version 2.2.1rc2

>>> f=open(some_big_file)
>>> f.readlines()
Pid 23292 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

Happens when last line of file lacks a terminating \n,
also the file has to be big enough (my example is about
2K in size)

Oddly, xreadlines() can be created, but attempting to
iterate over it crashes before the first line is 
returned:
>>> f=open(some_big_file)
>>> lines=f.xreadlines()    # OK so far
>>> for line in lines:
...    print line      # never gets here
...

Pid 23257 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

I'll try 2.2.1 final.


----------------------------------------------------------------------

>Comment By: Peter Harris (scav)
Date: 2002-04-22 11:12

Message:
Logged In: YES 
user_id=8911

2.2.1 final does it too. :(

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 12:41:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 04:41:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-547037 ] base64 newlines - documentation (again)
Message-ID: <E16zcC4-00022d-00@usw-sf-web2.sourceforge.net>

Bugs item #547037, was opened at 2002-04-22 11:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Rouse (p_rouse)
Assigned to: Nobody/Anonymous (nobody)
Summary: base64 newlines - documentation (again)

Initial Comment:
The documentation fix for bug 463330, describing the
newline added by base64.encode and base64.encodestring
appears to be incorrect!

The "courtesy newline" is appended to the result, not
the input (at line 466 of binsacii.c), so it is *not*
true that

base64.encodestring('hello') ==
base64.encodestring('hello\n')

In fact:

   base64.encodestring('hello') == 'aGVsbG8=\n'
   base64.encodestring('hello\n') == 'aGVsbG8K\n'

This applies to documentation for 2.2 and 2.2.1, and
actual behaviour has been checked in 2.2 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547037&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 13:01:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 05:01:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-545059 ] Internet Config -666 error
Message-ID: <E16zcVh-0001B1-00@usw-sf-web3.sourceforge.net>

Bugs item #545059, was opened at 2002-04-17 10:49
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545059&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: Internet Config -666 error

Initial Comment:
If IC can't find the extension->creator/type mapping for a file (and maybe the reverse too?) it raises a MacOS.Error -666. The value -666 isn't in the error string list (it's apparently not in the Apple header files, at least not the ones we parse). It should be added by hand, somehow, this error is rather common.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 14:01

Message:
Logged In: YES 
user_id=45365

Fixed, by adding an extra input file the the mkestrres process of creating the Estr resource, containing errors not declared in MacErrors.h.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545059&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 13:16:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 05:16:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-546913 ] #!/usr/bin/python -u -E doesn't work.
Message-ID: <E16zckI-0002RA-00@usw-sf-web2.sourceforge.net>

Bugs item #546913, was opened at 2002-04-22 01:46
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546913&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Rob Landley (landley)
Assigned to: Nobody/Anonymous (nobody)
Summary: #!/usr/bin/python -u -E doesn't work.

Initial Comment:
In linux create an executable file.py with the first 
line:

#!/usr/bin/python -u -E

It doesn't matter WHAT the rest of the file is, it 
won't work.

If you feed it both of those arguments, the python 
interpreter complalins that "-" is an unknown 
argument. (?)  I tried replacing python with "echo" 
and the command line it was getting was "-u -E 
./file.py", and "python -u -E ./file.py" works just 
fine when I feed that to python from an interactive 
bash command line.

Feeding it just "-E" in the #! arguments works fine, 
but you can't combine select.poll with file.read(), 
and without -u, if you combine os.read() with 
file.readline() it takes a 4k chunk out of stdin that 
you can't get it to cough back up with a crowbar...

I'm using python 2.2 compiled from source on an 
approximately Red Hat 7.2 system, if that makes a 
difference.  (I checked the ancient python 1.5 that 
comes with Red Hat and yup: same bug.)

I am about to go create a bash script for the purpose 
of calling the python program in such a way as to not 
trigger this bug...

Rob


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-22 14:16

Message:
Logged In: YES 
user_id=21627

This is not a bug in Python, but a limitation of the
operating system. The system will pass at most one argument
from a #! line; it is an error to specify more than one
argument there. If you use '-uE', it works fine.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546913&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 14:18:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 06:18:09 -0700
Subject: [Python-bugs-list] [ python-Bugs-546749 ] odd exception moving file to trash
Message-ID: <E16zdhp-00022O-00@usw-sf-web3.sourceforge.net>

Bugs item #546749, was opened at 2002-04-21 15:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: odd exception moving file to trash

Initial Comment:
MacPython 2.2.1 on OSX.1.4, from IDE:
>>> import macfs, findertools
>>> f = open("a_file_to_trash", "w")
>>> f.close()
>>> fss = macfs.FSSpec("a_file_to_trash")
>>> vrefnum = fss.as_tuple()[0]
>>> vrefnum, pardir = macfs.FindFolder(vrefnum, 
"trsh", 1)
>>> trashfolder = macfs.FSSpec((vrefnum, pardir, 
"")).as_pathname()
>>> findertools.move("a_file_to_trash", 
trashfolder)
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:findertools.py", line 74, in move
    return finder.move(src_fss, to=dst_fss)
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:lib-
scriptpackages:Finder:Standard_Suite.py", line 
293, in move
    raise aetools.Error, 
aetools.decodeerror(_arguments)
aetools.Error: (0, 'component result = no error', 
None)
>>> 

The file _does_ get moved to the trash, but that's 
not visible in the Finder's Trash window, not even 
after more items are dragged to the trash 
manually.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 15:18

Message:
Logged In: YES 
user_id=45365

This is a duplicate of #493826. I'm leaving this in too, though, because the bit about the resulting file not being visible in the thrash is something not in the other error report.

Also, a question: are you sure about not seeing the result in the Trash window? I *am* seeing it there. And I'm tempted to think that errn==0 simply doesn't signal an error...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 14:24:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 06:24:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-511073 ] urllib problems
Message-ID: <E16zdnn-00027W-00@usw-sf-web3.sourceforge.net>

Bugs item #511073, was opened at 2002-01-31 08:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511073&group_id=5470

Category: Macintosh
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yair Benita (ybenita)
Assigned to: Jack Jansen (jackjansen)
Summary: urllib problems

Initial Comment:
when using urllib.urlopen("url") and then reading 
the file with handle.read() i get only parts of pages. 
it works for short webpages but if i use it to 
download large pages it always come too short. To 
me it looks that it tries to read the file before it is 
downloaded. Jack Jansen's said: MacPython may 
do short reads on sockets. I've always maintained 
that this was correct (which reasoning was quietly 
accepted by everyone here), but last year I finally 
admitted that it may actually be incorrect (which 
was again quietly accepted:-)

example:
x=urllib.urlopen("http://www.ebi.ac.uk/cgi-bin/emblf
etch?db=embl&format=fasta&style=raw&id=AB002
378")
print x.read()

compare the file downloaded by any html browser 
and the file from macpython.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 15:24

Message:
Logged In: YES 
user_id=45365

This was fixed some time ago (the fix made it into 2.2.1) by modifying the underlying GUSI I/O library. Apparently I forgot to close the bug report, so I'm doing so now.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-02-06 01:34

Message:
Logged In: YES 
user_id=45365

I probably found the cause for this, now the only task remaining is finding out who to blame:-)

httplib explicitly sets non-buffering I/O on the file corresponding to the socket, by calling
self.fp = socket.makefile("rb", 0).

MSL, the CodeWarrior I/O library, has an optimization (or bug:-) that if you fread() from a binary
file with buffering turned off it will call the underlying read() straight away.

Python's fileobject.c file_read() reacts to a short fread() return value by returning.

One of these three is wrong, apparently.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=511073&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 14:58:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 06:58:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-545388 ] walk() walks aliases
Message-ID: <E16zeKn-0005yo-00@usw-sf-web1.sourceforge.net>

Bugs item #545388, was opened at 2002-04-18 00:09
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545388&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Jack Jansen (jackjansen)
Summary: walk() walks aliases

Initial Comment:
>> macpath.walk() (or actually os.path.walk) is 
explicitly define *not* to
>> do special things for symlinks or aliases. But 
still: the functionality
>> is nice, so maybe we should put it in a new 
function macostools.walk.
>
> By "special things" you don't mean that walk() is 
suppose to skip over
> aliases, do you?

Yes, that's what I mean. Do I understand from your 
comment that it walks 
aliases? That would be a bug, please file it at 
sourceforge.


-----

I am just filing the above correspondence as a 
reminder that walk() in macpath walks aliases.

/c

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 15:58

Message:
Logged In: YES 
user_id=45365

Fixed in macpath.py 1.36, which also includes your islink() fix and an equivalent of your resolve() function. The last as realpath(), which is an API alias available in posixpath and others.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545388&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 15:03:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 07:03:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-539990 ] Framework.mainloop() - multiple threads
Message-ID: <E16zePd-00062U-00@usw-sf-web1.sourceforge.net>

Bugs item #539990, was opened at 2002-04-05 23:29
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
>Priority: 7
Submitted By: Pieter Claerhout (pclaerhout)
Assigned to: Jack Jansen (jackjansen)
Summary: Framework.mainloop() - multiple threads

Initial Comment:
I tried to use the threading module to start the XML 
RPC server in a different thread (xmlrpcServer itself 
also is a threaded piece of code), but that seems to 
conflict with the mainloop. If you start this 
application, it starts the thread, starts the mainloop 
and stays in there, once you finish the mainloop, the 
thread continues.

You've stumbled on a bug in Framework.mainloop(): it 
doesn't know anything about multiple threads. It gives 
time to other applications (by calling WaitNextEvent) 
but not to other threads within Python.

Also see
http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005416.html

and 

http://mail.python.org/pipermail/pythonmac-sig/2002-
April/005428.html

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 16:03

Message:
Logged In: YES 
user_id=45365

After some discussion on the SIG it turns out this is a rather complicated problem, because WNE() may cause callbacks to be called (for Carbon Event handlers, for instance), and releasing the GIL would mean those callbacks would be hosed.

A solution will have to have all callback wrappers acquire the GIL, and it will either have to make very sure we never enter WNE() or friends with the GIL held, or the callback code will need to be able to handle both the case of being called with the GIL held and the case of being called without it.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-07 23:26

Message:
Logged In: YES 
user_id=45365

Adding an optional time.sleep(0) to the mainloop should do the trick, but unfortunately this won't work with the current MacPython, as time.sleep() is implemented with select(). And while GUSI sleep(0) does the threadswitch sleect(..., 0) doesn't. So this needs to be fixed in timemodule, and then the thread switch can be forced in Framework.Application.mainloop().

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=539990&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 15:03:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 07:03:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-547093 ] urllib/httplib vs corrupted tcp/ip stack
Message-ID: <E16zeQ9-0003iL-00@usw-sf-web2.sourceforge.net>

Bugs item #547093, was opened at 2002-04-22 14:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547093&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Asle Pedersen (apederse)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/httplib vs corrupted tcp/ip stack

Initial Comment:
I am trying to connect to a server (talouselama.fi) 
using urllib2. The server respond immediately after it 
has received the first package from the client 
(urllib2). Since httplib fragment http requests in a 
request package and subsequent header packages the 
server disregards any header information that is sendt 
using urllib2. I have used ethereal to trace the 
packages for the connection. I can provide a dump if 
necessary.

This problem may well be due to a corruptet tcp/ip 
stack at the server (talouselama.fi) but shouldn't 
urllib handle this if any other browser does. (lynx, 
explorer, opera - no exception)??

/Asle


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547093&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 15:11:45 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 07:11:45 -0700
Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices
Message-ID: <E16zeXh-0002iA-00@usw-sf-web3.sourceforge.net>

Bugs item #493951, was opened at 2001-12-16 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Barry Warsaw (bwarsaw)
Summary: string.{starts,ends}with vs slices

Initial Comment:
The attached test shows many cases where 
string.startswith() and string.endswith() fail to 
handle negative slice indices correctly.  The failures 
are in both the start and end indices.  I stumbled 
into this when tracking down why (what turned out to 
be) this didn't work:

>>> file = 'difflib.pyc'
>>> file.endswith('.py', 0, -1) # should be 1
0
>>> file[0:-1].endswith('.py')  # like this is
1
>>>

Can we risk changing this for 2.2?  Don't know.  If 
not, reduce the priority.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 10:11

Message:
Logged In: YES 
user_id=12800

The comment in the code reminds me that we adopted the
semantics for Java's String.startsWith() and String.endsWith(): 

http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html#startsWith(java.lang.String,%20int)

which treats negative indices as errors (at least for the
start parameter -- which we generalized to include the end
parameter).  Changing this is a semantic change to the
string methods, so I don't think it should be undertaken
lightly (i.e. as a bug in the current implementation).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 15:03

Message:
Logged In: YES 
user_id=31435

I can't guess what the docs intended to say (they're vague -
- I can read them several ways).

In all other cases where optional string-method args 
named "start" and "end" are accepted (find(), rfind(), count
(), index(), rindex()), the docs are clear that they're 
interpreted as slice notation.  It doesn't make sense for 
the two newest methods to behave differently in this 
respect.

The unit tests aren't evidence one way or the other to me --
 the behavior of negative indices should be covered by the 
tests no matter what the intended semantics.

Overall, I expect the behavior here is an accident (as 
opposed to intended).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-16 14:45

Message:
Logged In: YES 
user_id=6380

Hm, the docs don't exactly suggest that negative indices
would be supported. While that would be nice, it's
definitely a feature request, so no, please don't do this in
2.2. (The absent of unit tests for negative indices also
suggests this was not an oversight. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 14:24

Message:
Logged In: YES 
user_id=31435

Attached the test case.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 15:21:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 07:21:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-231207 ] Fatal Python Error during program shutdown
Message-ID: <E16zehE-0003YQ-00@usw-sf-web4.sourceforge.net>

Bugs item #231207, was opened at 2001-02-05 18:50
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470

Category: Tkinter
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Doug Henderson (djhender)
Assigned to: Nobody/Anonymous (nobody)
Summary: Fatal Python Error during program shutdown

Initial Comment:
The windows builds of versions 2.0 and 2.1a2 contain an intermittent bug which often appears when a script using Tkinter stops by calling self.tk.quit() and sometimes (less often) appears following a <Destroy> event or call to a ?.destory() function.
Under Windows 98SE, this results in a GPF.
Under Windows 2000, a message to the console window shows "Fatal Python Error", "PyEval_RestoreThread NULL tstate".

The following script demonstrates the problem:
---------------------
# BugDemo.py

from Tkinter import *

class BugDemo(Frame):
    def __init__(self, parent):
        Frame.__init__(self, parent)
        Button(self, text='Hi', command=self.hi).pack()
        Button(self, text='Quit', command=self.tk.quit).pack()
    def hi(self):
        print "hi"

bd = BugDemo(Tk())
bd.pack()
bd.mainloop()
----------------------
Execute in console window: "c:> python BugDemo.py"
Test this by 1) clicking Quit button 2) clicking Hi button, then Quit button.
Test 1: The script runs successfully most of the time. I found I had to minimize and restore its window to make it fail regularly.
Test 2: I need to click Hi button before clicking the Quit button. Then it failed about half the time.

The problem appears to occur after the script has completed, during some kind of cleanup perhaps. The more useful error message on the Win2k machine may help to locate the problem.

Problem also manifests using the PythonWare 2.0 release on Win98.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-22 07:21

Message:
Logged In: NO 

I confirm the behaviour for:
WinNT 4.0 SP5
tested with Python 2.2Beta1 (ActiveState)
tested with Python 2.2.1.222 (ActiveState)

PythonWinIDE will hang when the following program 
is "quit"ted.

But will "quit" normally when run standalone (not within 
PythonWinIDE):

# 
# 

from Tkinter import *
from tkMessageBox import *

class App:
    def __init__(self, winRoot):
        frame = Frame(winRoot)
        frame.pack()

        self.btnQuit = Button(frame, text="QUIT", 
bg="blue", foreground="light blue", command=frame.quit)
        self.btnQuit.pack(side=LEFT)

        self.btnHiThere = Button(frame, text="Hi 
there!",command=self.sayHiThere)
        self.btnHiThere.pack(side=LEFT)

    def sayHiThere(self):
        showinfo("Greeting", "Hi There")
        
        

if __name__ == "__main__":
    root = Tk()
    test = App(root)
    root.mainloop()




----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 14:49

Message:
Logged In: YES 
user_id=31392

Unassign as it appears that effbot isn't going to look at 
it.


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-07-18 04:13

Message:
Logged In: NO 

i won't to be a hacker

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-05-29 00:30

Message:
Logged In: NO 

Note:
I am running Windows98
ActivePython 2.1
Even with console apps in python this same error appears
I tried using another Distribution of Python for win32, 
PythonWare20

So this leads me to believe that some lib is missing on 
win98. Because at work I use Win95, and Installed 
ActivePython 2.1, and it works fine and dandy


----------------------------------------------------------------------

Comment By: Joel Gould (joelgould)
Date: 2001-03-24 08:52

Message:
Logged In: YES 
user_id=20954

I also see a GPF on shutdown under Windows 98 using 
Tkinter.  I tested this using the PythonWare 2.0 release as 
well.

I have attached a very simple Tkinter program.  When I run 
this on my Windows 98 SE machine, a crash occurs when the 
program exits.  Without the MainDialog class it works OK.  
Without the Pmw initialization call it works OK.  But as 
written it will crash around 75% of the time.

(1) run the program
(2) press the Test Button
(3) click Cancel in the file open dialog (you do not need 
to select a file)
(4) click the close button in the upper right corner
-->  Boom

--------------------

import Tkinter
import tkFileDialog
import Pmw

def action():
    tkFileDialog.askopenfilename(filetypes=[('All','*')])

class MainDialog:
    def __init__(self,parent):
        Tkinter.Button(parent,text='Test 
Button',command=action).pack()

root = Pmw.initialise()
dialog = MainDialog(root)
root.mainloop()

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-02-09 15:34

Message:
Assigned to /F, under the theory he can confirm that "this kind of thing" is still a general problem with Tk we can't do anything about.

----------------------------------------------------------------------

Comment By: Doug Henderson (djhender)
Date: 2001-02-05 21:30

Message:
See also #116289 (and my comment to it) which describes what often happened to my 'real' programs which lead to developing the above BugDemo script. My 'real' programs were developed over the last two years or so, and worked in Jan 2000 with 1.5.2. I upgraded the Python version recently, and then started working on these programs again. It was "WTF is wrong with my code", until I found the same problem showing up in the small test cases.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=231207&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 15:31:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 07:31:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-493951 ] string.{starts,ends}with vs slices
Message-ID: <E16zeqL-0003fu-00@usw-sf-web4.sourceforge.net>

Bugs item #493951, was opened at 2001-12-16 14:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Barry Warsaw (bwarsaw)
Summary: string.{starts,ends}with vs slices

Initial Comment:
The attached test shows many cases where 
string.startswith() and string.endswith() fail to 
handle negative slice indices correctly.  The failures 
are in both the start and end indices.  I stumbled 
into this when tracking down why (what turned out to 
be) this didn't work:

>>> file = 'difflib.pyc'
>>> file.endswith('.py', 0, -1) # should be 1
0
>>> file[0:-1].endswith('.py')  # like this is
1
>>>

Can we risk changing this for 2.2?  Don't know.  If 
not, reduce the priority.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 10:31

Message:
Logged In: YES 
user_id=6380

We should fix this in 2.3 at the very least. Leave 2.2.x
alone.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 10:11

Message:
Logged In: YES 
user_id=12800

The comment in the code reminds me that we adopted the
semantics for Java's String.startsWith() and String.endsWith(): 

http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html#startsWith(java.lang.String,%20int)

which treats negative indices as errors (at least for the
start parameter -- which we generalized to include the end
parameter).  Changing this is a semantic change to the
string methods, so I don't think it should be undertaken
lightly (i.e. as a bug in the current implementation).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 15:03

Message:
Logged In: YES 
user_id=31435

I can't guess what the docs intended to say (they're vague -
- I can read them several ways).

In all other cases where optional string-method args 
named "start" and "end" are accepted (find(), rfind(), count
(), index(), rindex()), the docs are clear that they're 
interpreted as slice notation.  It doesn't make sense for 
the two newest methods to behave differently in this 
respect.

The unit tests aren't evidence one way or the other to me --
 the behavior of negative indices should be covered by the 
tests no matter what the intended semantics.

Overall, I expect the behavior here is an accident (as 
opposed to intended).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-16 14:45

Message:
Logged In: YES 
user_id=6380

Hm, the docs don't exactly suggest that negative indices
would be supported. While that would be nice, it's
definitely a feature request, so no, please don't do this in
2.2. (The absent of unit tests for negative indices also
suggests this was not an oversight. :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-12-16 14:24

Message:
Logged In: YES 
user_id=31435

Attached the test case.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=493951&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 15:52:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 07:52:20 -0700
Subject: [Python-bugs-list] [ python-Bugs-451841 ] python-mode indentation bug
Message-ID: <E16zfAy-0003DH-00@usw-sf-web3.sourceforge.net>

Bugs item #451841, was opened at 2001-08-16 19:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451841&group_id=5470

Category: Demos and Tools
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 4
Submitted By: Barry Warsaw (bwarsaw)
Assigned to: Barry Warsaw (bwarsaw)
Summary: python-mode indentation bug

Initial Comment:
In test_uu.py, python-mode starts indenting weirdly
towards the bottom.  I think it's a bug in XEmacs'
21.4's buffer-syntactic-context


----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 10:52

Message:
Logged In: YES 
user_id=12800

Attached is a patch that fixes the problem, which was due to
the ubiquitous "open-paren in column 0" bug/limitation in
XEmacs.  This simply removes the XEmacs-specific
buffer-syntactic-context call in favor of using the slower
parse-partial-sexp call.  Computers are a lot faster now, so
I think we can get away with just parsing the world. ;)

I'm going to test this for a few days before I commit it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=451841&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 15:54:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 07:54:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-473623 ] Emacs: python-mode.el
Message-ID: <E16zfDB-0004KW-00@usw-sf-web2.sourceforge.net>

Bugs item #473623, was opened at 2001-10-22 06:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473623&group_id=5470

Category: Documentation
Group: Not a Bug
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Emacs: python-mode.el

Initial Comment:
Please explain in python-mode.el how to install
the mode in emacs.

On Windows you need to copy python-mode.el
into $EMACS_HOME/lisp and add "(require 'python-mode)"
into your startupscript (E.g. $HOME/.emacs).

Thank you

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 10:54

Message:
Logged In: YES 
user_id=12800

I agree with Martin, so I'm closing this bug.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2001-10-22 14:49

Message:
Logged In: YES 
user_id=21627

There is a link to 

http://www.python.org/emacs/python-mode/

in python-mode.el, which in turn offers a link 
"Installation Notes". Is this not enough? 

I think these instructions are much beter than putting a 
require into .emacs, since they only load python-mode when 
needed. OTOH, they are also somewhat more complex, since 
they work through auto-mode-alist and 
interpreter-mode-alist.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=473623&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 16:23:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 08:23:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-546749 ] odd exception moving file to trash
Message-ID: <E16zffF-0003a9-00@usw-sf-web3.sourceforge.net>

Bugs item #546749, was opened at 2002-04-21 15:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: odd exception moving file to trash

Initial Comment:
MacPython 2.2.1 on OSX.1.4, from IDE:
>>> import macfs, findertools
>>> f = open("a_file_to_trash", "w")
>>> f.close()
>>> fss = macfs.FSSpec("a_file_to_trash")
>>> vrefnum = fss.as_tuple()[0]
>>> vrefnum, pardir = macfs.FindFolder(vrefnum, 
"trsh", 1)
>>> trashfolder = macfs.FSSpec((vrefnum, pardir, 
"")).as_pathname()
>>> findertools.move("a_file_to_trash", 
trashfolder)
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:findertools.py", line 74, in move
    return finder.move(src_fss, to=dst_fss)
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:lib-
scriptpackages:Finder:Standard_Suite.py", line 
293, in move
    raise aetools.Error, 
aetools.decodeerror(_arguments)
aetools.Error: (0, 'component result = no error', 
None)
>>> 

The file _does_ get moved to the trash, but that's 
not visible in the Finder's Trash window, not even 
after more items are dragged to the trash 
manually.

----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2002-04-22 17:23

Message:
Logged In: YES 
user_id=92689

(sorry for the duplicate...)

Yes I'm sure: there's nothing visible in the Finder, but it 
does show with "ls" in the terminal. New finding: it
_does_ show if the trash wasn't empty before...

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 15:18

Message:
Logged In: YES 
user_id=45365

This is a duplicate of #493826. I'm leaving this in too, though, because the bit about the resulting file not being visible in the thrash is something not in the other error report.

Also, a question: are you sure about not seeing the result in the Trash window? I *am* seeing it there. And I'm tempted to think that errn==0 simply doesn't signal an error...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 16:24:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 08:24:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-545436 ] py-execute-string doesn't work
Message-ID: <E16zffi-0006zf-00@usw-sf-web1.sourceforge.net>

Bugs item #545436, was opened at 2002-04-17 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470

Category: Demos and Tools
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry Warsaw (bwarsaw)
Summary: py-execute-string doesn't work

Initial Comment:
The python-mode function py-execute-string appears 
not to work.  In XEmacs 21.4.6 I executed

    M-x py-execute-string
    print "hello world"

and got a "No output." message.

Stepping through the code using edebug it appears 
that in py-execute-region the local variable cmd
(right after the "horrible hack" comment) is set to
the empty string.  I think it's because that chunk
of code uses buffer-local info to determine what
command to run.  Executing py-execute-region from
a fundamental-mode buffer also fails.  Executing
python-mode and then running it again succeeds.

Adding

	(if (equal cmd "")
	    (setq cmd "python"))

right after cmd is set seems to make things work
regardless of the buffer's mode.



----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 11:24

Message:
Logged In: YES 
user_id=12800

Skip, tell me what you think of the attached patch.  It sets
a local `shell' variable to the value of py-which-shell
after setting the temporary file to python-mode.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 16:27:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 08:27:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-545436 ] py-execute-string doesn't work
Message-ID: <E16zfig-000729-00@usw-sf-web1.sourceforge.net>

Bugs item #545436, was opened at 2002-04-17 20:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470

Category: Demos and Tools
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry Warsaw (bwarsaw)
Summary: py-execute-string doesn't work

Initial Comment:
The python-mode function py-execute-string appears 
not to work.  In XEmacs 21.4.6 I executed

    M-x py-execute-string
    print "hello world"

and got a "No output." message.

Stepping through the code using edebug it appears 
that in py-execute-region the local variable cmd
(right after the "horrible hack" comment) is set to
the empty string.  I think it's because that chunk
of code uses buffer-local info to determine what
command to run.  Executing py-execute-region from
a fundamental-mode buffer also fails.  Executing
python-mode and then running it again succeeds.

Adding

	(if (equal cmd "")
	    (setq cmd "python"))

right after cmd is set seems to make things work
regardless of the buffer's mode.



----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 11:24

Message:
Logged In: YES 
user_id=12800

Skip, tell me what you think of the attached patch.  It sets
a local `shell' variable to the value of py-which-shell
after setting the temporary file to python-mode.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 16:59:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 08:59:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-547138 ]  - open - alias generates error
Message-ID: <E16zgEE-00056t-00@usw-sf-web2.sourceforge.net>

Bugs item #547138, was opened at 2002-04-22 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: rodney holland (rhhrhh)
Assigned to: Nobody/Anonymous (nobody)
Summary:  - open - alias generates error

Initial Comment:
Using python 2.2.1c on windows 98 the alias -  open  -
  gives the following error.  The function  - file -   
works fine.


>>> f=open("rfile.dat",'w')
Traceback (most recent call last):
  File "<pyshell#42>", line 1, in ?
    f=open("rfile.dat",'w')
TypeError: an integer is required
>>> 

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 17:23:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 09:23:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-232398 ] Emacs Python mode bugs
Message-ID: <E16zgbb-00053E-00@usw-sf-web4.sourceforge.net>

Bugs item #232398, was opened at 2001-02-14 16:12
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232398&group_id=5470

Category: Demos and Tools
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Barry Warsaw (bwarsaw)
Summary: Emacs Python mode bugs

Initial Comment:
1. I wish that Emacs Python mode, when I run a buffer with ^C^C,
looked at the #! line (if there is one) to choose a Python interpreter,
rather than blindly using the default.

2. Also, when I set the variable python-command to "python1.5", this apparently has no effect -- it still uses "python".

3. Maybe I've submitted this before; each time I use ^C^CF a new buffer with a name like /usr/tmp/python-uKA1TJ is created; these buffers just collect dust.

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 12:23

Message:
Logged In: YES 
user_id=12800

Note that I can't reproduce #2 anymore.

python-mode.el 4.10 implements the suggested feature in item #1.


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-03-01 18:03

Message:
Logged In: YES 
user_id=12800

I'll handle it.  I've got a bunch of minor python-mode
requests backed up, just waiting for a lull to be attacked.
 Please keep this open.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:51

Message:
Logged In: YES 
user_id=31392

Barry,

Are you still planning to work on this?  Or should we move 
it to feature requests and close the bug report?


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2001-02-23 13:37

Message:
I've fixed #3 in 3.110 of python-mode.el.  The other two will require some non-trivial recoding py-execute-region and the py-which-* variables.  I'm not immediately sure of the best way to do this, but I'll work on this for 2.1 final.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=232398&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 17:25:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 09:25:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-540720 ] test_email fails on Mac in summer
Message-ID: <E16zgdR-0004KC-00@usw-sf-web3.sourceforge.net>

Bugs item #540720, was opened at 2002-04-07 17:55
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470

Category: Python Library
Group: Platform-specific
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Barry Warsaw (bwarsaw)
Summary: test_email fails on Mac in summer

Initial Comment:
Yes, I kid you not:-)

The test of the date/time  parser in test_email tries to cater for the fact that the Mac uses localtime (at least, before OSX), but it fails to cater for DST. So, test_email passes in winter, but fails in summer.

I think the whole idea of comparing based on a numeric value is not so good. Why not try a roundtrip, or compare against another date coder (time.asctime)?

----------------------------------------------------------------------

>Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 12:25

Message:
Logged In: YES 
user_id=12800

I believe the patch resolved this issue.

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-15 13:12

Message:
Logged In: YES 
user_id=12800

Actually, forget the patch.  I integrated email 2.0 into
Python 2.3's cvs and this included the proposed fix.  Take a
look at test_formatdate() and test_formatdate_localtime() in
Lib/test/test_email.py and let me know what you think.

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-09 17:49

Message:
Logged In: YES 
user_id=45365

Barry,
I can't apply the patch, it seems to be against a different version of test_email than what's in the repository (I tried both the trunk and the 22 maintainance branch).

----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-08 02:15

Message:
Logged In: YES 
user_id=12800

What do you think of the attached patch?  Is this still a
useful test to include?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=540720&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 17:50:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 09:50:03 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16zh0t-0004cP-00@usw-sf-web3.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 04:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Walter D�rwald (doerwalter)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 12:50

Message:
Logged In: YES 
user_id=6380

Walter, please check this in. I haven't reviewed it
thoroughly, but it looks okay, and the functionality is
right.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-19 10:50

Message:
Logged In: YES 
user_id=89016

Here is the patch (diff.txt).

This a simple copy of the string version. I had to make the 
unicode version of do_xstrip public (as _PyUnicode_XStrip), 
so that the string version can call it when it gets passed 
a unicode object.


----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-18 15:28

Message:
Logged In: YES 
user_id=89016

I have a patch ready that implements the unicode version, 
and the mixed versions, i.e. str.strip(unicode) and 
unicode.strip(str), but CVS doesn't like me today.

Maybe tomorrow!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-12 22:43

Message:
Logged In: YES 
user_id=3066

(I'd say this is a good reason not to use separate trackers
for features, bugs, & patches -- they're too closely related
to keep them separate, and links between them too tedious
when written only in tracker comments!)

I've updated the documentation for these methods in
Doc/lib/libstdtypes.tex revision 1.87.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-12 21:02

Message:
Logged In: YES 
user_id=6380

Oops, I saw your remark too late.

I've checked in my own version of this for regular
strings...

Feel free to check in your version of this for Unicode
strings, and the docs etc.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 11:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 10:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 05:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 04:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 03:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 17:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:09:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:09:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-547138 ]  - open - alias generates error
Message-ID: <E16zhJk-0005bD-00@usw-sf-web4.sourceforge.net>

Bugs item #547138, was opened at 2002-04-22 11:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: rodney holland (rhhrhh)
>Assigned to: Tim Peters (tim_one)
Summary:  - open - alias generates error

Initial Comment:
Using python 2.2.1c on windows 98 the alias -  open  -
  gives the following error.  The function  - file -   
works fine.


>>> f=open("rfile.dat",'w')
Traceback (most recent call last):
  File "<pyshell#42>", line 1, in ?
    f=open("rfile.dat",'w')
TypeError: an integer is required
>>> 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:09

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try the released 2.2.1, although I 
can't imagine why it would make any difference.  Nothing 
changed here, and

C:\Python22>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> file is open
1
>>>

That is, "file" and "open" aren't merely aliases, they're 
exactly the same object.

Are you using IDLE or PythonWin or ...?  "<pyshell#42>" 
doesn't appear in a DOS-box traceback.

Ah, I know!  You did something stupid <wink> you're not 
showing us, like

from os import *

Here:

>>> open
<type 'file'>
>>> from os import *
>>> open
<built-in function open>
>>>

If you replace the builtin open with os.open, then "an 
integer is required" is the expected error.  The builtin 
open and os.open are different functions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:25:19 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:25:19 -0700
Subject: [Python-bugs-list] [ python-Bugs-532860 ] NameError assigning to class in a func
Message-ID: <E16zhZ1-00068N-00@usw-sf-web2.sourceforge.net>

Bugs item #532860, was opened at 2002-03-21 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
Status: Open
Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Jeremy Hylton (jhylton)
Summary: NameError assigning to class in a func

Initial Comment:
This fails with a NameError:

def f(x)
    class Private:
        x = x
    return Private
f(17)

But this works:

def f(x):
    y = x
    class Private:
        x = y
    return Private
f(17)

But this fails:

def f(x):
    y = x
    class Private:
        y = y
    return Private
f(17)

See also the newsgroup thread:
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=Xns

(All tested on Python 2.2 on Win2k)



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-22 17:25

Message:
Logged In: YES 
user_id=31392

The behavior bugs me too, but I don't expect it will get 
fixed because of the need for backwards compatibility.  The 
local namespace for classes, modules, and functions that 
contain exec or import * are searched using the LOAD_NAME 
opcode.  This opcode implements the old locals, globals, 
builtin search for a name using dict lookup.  If the dict 
lookup fails at any level, the next level up is searched.  
This means an unbound local error will never occur in a 
class block, because the dict lookup just returns NULL and 
the search proceeds to globals.

If anything, the bug is the was "x=x" behaves at the class 
level, but I'm loathe to change it.  It will probably break 
existing code and will require substantial implementation 
effort (I think) because class namespaces aren't 
implemented using the same technique as a function 
namespace.

I'd rather document the existing wart and live with it.  In 
particular, I might document it with the following weasle 
words: "The result of reference an unbound local name in a 
class block is undefined."


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-04-22 09:31

Message:
Logged In: YES 
user_id=50945

Apologies for re-opening the bug.

This behaviour still seems like a bug to me, because while
this dies:

>>> def f(x):
...     class Private:
...         x = x
...     return Private
... 
>>> f(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 2, in f
  File "<stdin>", line 3, in Private
NameError: name 'x' is not defined

This works:

>>> x = 1 
>>> class C:
...     x = x
... 
>>> C()
<__main__.C instance at 0x806aeac>

Actually, having the global "x = 1" also makes the first
case work.

This seems inconsistent enough to me to warrant it being
called a bug, regardless of the underlying implementation
details (which I know little of).  I'd expect it work in
both cases, or neither case.

Feel free to close the bug again if you disagree :)

It's quite easy to work around, so I'm not worried greatly
by it.
(workaround:
def f(x):
    class Private:
         pass
    Private.x = x
    return Private
)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-19 16:39

Message:
Logged In: YES 
user_id=31392

This is actually working as intended, although the reference
manual no longer describes this case at all.  It has been a
long standing "feature" of Python that module and class
blocks use the LOAD_NAME opcode, which has weird scoping
rules.

The documentation should be updated to describe the cases in
which LOAD_NAME is used and its behavior.  (It checks
locals, globals, builtins in that order, and never raises a
NameError unless the name isn't found in any of those
namespaces.  In particular, an unbound local is simply
ignored.)

I don't actually know what these rules are used.  Guido--
should we get rid of LOAD_NAME?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:34:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:34:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-545655 ] cannot save buffer
Message-ID: <E16zhhz-0005t6-00@usw-sf-web4.sourceforge.net>

Bugs item #545655, was opened at 2002-04-18 09:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545655&group_id=5470

>Category: IDLE
Group: Python 2.1.2
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Didier (dalais_dj)
Assigned to: Nobody/Anonymous (nobody)
Summary: cannot save buffer

Initial Comment:
Exception in Tkinter callback
Traceback (most recent call last):
  File "C:\Python21\lib\lib-tk\Tkinter.py", line 1285, 
in __call__
    return apply(self.func, args)
  File "C:\Python21\Tools\idle\IOBinding.py", line 
126, in save
    self.save_as(event)
  File "C:\Python21\Tools\idle\IOBinding.py", line 
136, in save_as
    if self.writefile(filename):
  File "C:\Python21\Tools\idle\IOBinding.py", line 
154, in writefile
    f.write(chars)
UnicodeError: ASCII encoding error: ordinal not in 
range(128)



----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:34

Message:
Logged In: YES 
user_id=6380

I'm closing this now. We have a number of bug report for
this, and a proposed solution in the IDLEfork project:

http://sourceforge.net/tracker/index.php?func=detail&aid=508973&group_id=9579&atid=309579

Also note that in CVS we've got a patch that at least
prevents overwriting the file with empty contents when this
happens.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545655&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:39:43 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:39:43 -0700
Subject: [Python-bugs-list] [ python-Bugs-547176 ] rlcompleter does not expand on [ ]
Message-ID: <E16zhmx-0005x1-00@usw-sf-web4.sourceforge.net>

Bugs item #547176, was opened at 2002-04-22 13:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547176&group_id=5470

Category: Extension Modules
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jaco Schieke (schiekjd)
Assigned to: Nobody/Anonymous (nobody)
Summary: rlcompleter does not expand on [ ]

Initial Comment:
A thread on comp.lang.python details the problem:

http://groups.google.com/groups?
hl=en&threadm=b5ddd682.0204180902.2866a9c0%
40posting.google.com&rnum=1&prev=/groups%3Fhl%3Den%
26selm%3Db5ddd682.0204180902.2866a9c0%
2540posting.google.com

rlcompleter.py does not expand correctly on something 
like:
>>> sim[0].<tab>
since
  m = re.match(r"(\w+(\.\w+)*)\.(\w*)", text)
does not allow for brackets in the match.

I propose:
  m = re.match(r"([\w\[\]]+(\.[\w\[\]]+)*)\.(\w*)", 
text)

to fix this on line 127 in cvs version 1.11




----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547176&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:41:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:41:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16zhp6-00008P-00@usw-sf-web1.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Duncan Booth (duncanb)
>Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:44:21 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:44:21 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16zhrR-0006LX-00@usw-sf-web2.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Walter D�rwald (doerwalter)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-22 19:44

Message:
Logged In: YES 
user_id=89016

OK, checked in as:

Doc/lib/libstring.tex 1.46
Include/unicodeobject.h 2.37
test/string_tests.py 1.15
test/test_unicode.py 1.57
Objects/stringobject.c 2.160
Objects/unicodeobject.c 2.144

Backport will follow.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 18:50

Message:
Logged In: YES 
user_id=6380

Walter, please check this in. I haven't reviewed it
thoroughly, but it looks okay, and the functionality is
right.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-19 16:50

Message:
Logged In: YES 
user_id=89016

Here is the patch (diff.txt).

This a simple copy of the string version. I had to make the 
unicode version of do_xstrip public (as _PyUnicode_XStrip), 
so that the string version can call it when it gets passed 
a unicode object.


----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-18 21:28

Message:
Logged In: YES 
user_id=89016

I have a patch ready that implements the unicode version, 
and the mixed versions, i.e. str.strip(unicode) and 
unicode.strip(str), but CVS doesn't like me today.

Maybe tomorrow!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-13 04:43

Message:
Logged In: YES 
user_id=3066

(I'd say this is a good reason not to use separate trackers
for features, bugs, & patches -- they're too closely related
to keep them separate, and links between them too tedious
when written only in tracker comments!)

I've updated the documentation for these methods in
Doc/lib/libstdtypes.tex revision 1.87.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-13 03:02

Message:
Logged In: YES 
user_id=6380

Oops, I saw your remark too late.

I've checked in my own version of this for regular
strings...

Feel free to check in your version of this for Unicode
strings, and the docs etc.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 17:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 16:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 11:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 10:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 09:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 23:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:45:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:45:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-546117 ] readlines() bombs - last line incomplete
Message-ID: <E16zhsg-0005GP-00@usw-sf-web3.sourceforge.net>

Bugs item #546117, was opened at 2002-04-19 09:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: readlines() bombs - last line incomplete

Initial Comment:
HP-UX 11 64bit, compiled with HP ansi c compiler.
Python version 2.2.1rc2

>>> f=open(some_big_file)
>>> f.readlines()
Pid 23292 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

Happens when last line of file lacks a terminating \n,
also the file has to be big enough (my example is about
2K in size)

Oddly, xreadlines() can be created, but attempting to
iterate over it crashes before the first line is 
returned:
>>> f=open(some_big_file)
>>> lines=f.xreadlines()    # OK so far
>>> for line in lines:
...    print line      # never gets here
...

Pid 23257 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

I'll try 2.2.1 final.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:45

Message:
Logged In: YES 
user_id=6380

I can't reproduce this on Linux. Can you upload the data
file or (preferably, if you have access) on a Linux system,
with Python 2.2.1? I'd like to see if this is data dependent
or platform specific before we go any further with this.

----------------------------------------------------------------------

Comment By: Peter Harris (scav)
Date: 2002-04-22 07:12

Message:
Logged In: YES 
user_id=8911

2.2.1 final does it too. :(

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 18:58:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 10:58:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16zi5Q-0000LB-00@usw-sf-web1.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Duncan Booth (duncanb)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 19:16:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 11:16:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16ziMK-0006kL-00@usw-sf-web2.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Duncan Booth (duncanb)
>Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 14:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 19:29:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 11:29:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16ziYp-0005md-00@usw-sf-web3.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
>Priority: 6
Submitted By: Duncan Booth (duncanb)
Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:29

Message:
Logged In: YES 
user_id=31435

Boosted priority (it's crashing X servers too!).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 14:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 19:37:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 11:37:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16zigP-0006zK-00@usw-sf-web2.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Duncan Booth (duncanb)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:37

Message:
Logged In: YES 
user_id=31435

Neal, can you try the attached patch in your Linux 
scenario?  Whether it works or not, assign this back to 
me.  It fixes my problem on Win98, so I'm going to check it 
in regardless, but I'll leave the bug open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:29

Message:
Logged In: YES 
user_id=31435

Boosted priority (it's crashing X servers too!).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 14:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 19:43:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 11:43:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-532860 ] NameError assigning to class in a func
Message-ID: <E16zimO-0000sV-00@usw-sf-web1.sourceforge.net>

Bugs item #532860, was opened at 2002-03-21 01:27
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2
>Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Andrew Bennetts (spiv)
Assigned to: Jeremy Hylton (jhylton)
Summary: NameError assigning to class in a func

Initial Comment:
This fails with a NameError:

def f(x)
    class Private:
        x = x
    return Private
f(17)

But this works:

def f(x):
    y = x
    class Private:
        x = y
    return Private
f(17)

But this fails:

def f(x):
    y = x
    class Private:
        y = y
    return Private
f(17)

See also the newsgroup thread:
http://groups.google.com/groups?hl=en&ie=ISO-8859-1&oe=ISO-8859-1&threadm=Xns

(All tested on Python 2.2 on Win2k)



----------------------------------------------------------------------

>Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-22 18:43

Message:
Logged In: YES 
user_id=31392

Indeed, after conversation with GvR, we are in agreement 
that it would break too much old code to "fix" this.  Just 
don't write code that abuses the wart at the module level, 
and you'll never feel its a bug when nested inside a 
function <0.1 wink>.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-22 17:25

Message:
Logged In: YES 
user_id=31392

The behavior bugs me too, but I don't expect it will get 
fixed because of the need for backwards compatibility.  The 
local namespace for classes, modules, and functions that 
contain exec or import * are searched using the LOAD_NAME 
opcode.  This opcode implements the old locals, globals, 
builtin search for a name using dict lookup.  If the dict 
lookup fails at any level, the next level up is searched.  
This means an unbound local error will never occur in a 
class block, because the dict lookup just returns NULL and 
the search proceeds to globals.

If anything, the bug is the was "x=x" behaves at the class 
level, but I'm loathe to change it.  It will probably break 
existing code and will require substantial implementation 
effort (I think) because class namespaces aren't 
implemented using the same technique as a function 
namespace.

I'd rather document the existing wart and live with it.  In 
particular, I might document it with the following weasle 
words: "The result of reference an unbound local name in a 
class block is undefined."


----------------------------------------------------------------------

Comment By: Andrew Bennetts (spiv)
Date: 2002-04-22 09:31

Message:
Logged In: YES 
user_id=50945

Apologies for re-opening the bug.

This behaviour still seems like a bug to me, because while
this dies:

>>> def f(x):
...     class Private:
...         x = x
...     return Private
... 
>>> f(17)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 2, in f
  File "<stdin>", line 3, in Private
NameError: name 'x' is not defined

This works:

>>> x = 1 
>>> class C:
...     x = x
... 
>>> C()
<__main__.C instance at 0x806aeac>

Actually, having the global "x = 1" also makes the first
case work.

This seems inconsistent enough to me to warrant it being
called a bug, regardless of the underlying implementation
details (which I know little of).  I'd expect it work in
both cases, or neither case.

Feel free to close the bug again if you disagree :)

It's quite easy to work around, so I'm not worried greatly
by it.
(workaround:
def f(x):
    class Private:
         pass
    Private.x = x
    return Private
)


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-19 16:39

Message:
Logged In: YES 
user_id=31392

This is actually working as intended, although the reference
manual no longer describes this case at all.  It has been a
long standing "feature" of Python that module and class
blocks use the LOAD_NAME opcode, which has weird scoping
rules.

The documentation should be updated to describe the cases in
which LOAD_NAME is used and its behavior.  (It checks
locals, globals, builtins in that order, and never raises a
NameError unless the name isn't found in any of those
namespaces.  In particular, an unbound local is simply
ignored.)

I don't actually know what these rules are used.  Guido--
should we get rid of LOAD_NAME?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=532860&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 19:45:09 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 11:45:09 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-444708 ] Optional argument for string.strip()
Message-ID: <E16zioH-0000tq-00@usw-sf-web1.sourceforge.net>

Feature Requests item #444708, was opened at 2001-07-26 10:35
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
Resolution: Accepted
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Walter D�rwald (doerwalter)
Summary: Optional argument for string.strip()

Initial Comment:
The .split method on strings splits at whitespace by 
default, but takes an optional argument allowing 
splitting by other strings. The .strip method (and its 
siblings), on the other hand, always strip whitespace. 
On more than one occasion I would have found it useful 
if these methods also took an optional argument 
allowing other strings to be stripped. For example, to 
strip, say, asterisks from a string you could do:

>>>fred = '**word**word**'
>>>fred.strip('*')
word**word

If nothing else, this would meany that we have a good 
answer when people ask about a equivalent to 
Perl's 'chomp' function - string.rstrip(os.linesep).

----------------------------------------------------------------------

>Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-22 20:45

Message:
Logged In: YES 
user_id=89016

Backported to the release22-maint branch as:

Doc/lib/libstring.tex 1.45.8.1
Include/unicodeobject.h 2.36.10.1
Lib/test/string_tests.py 1.10.16.3
Lib/test/test_unicode.py 1.47.6.3
Objects/stringobject.c 2.147.6.3
Objects/unicodeobject.c 2.124.6.8

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-22 19:44

Message:
Logged In: YES 
user_id=89016

OK, checked in as:

Doc/lib/libstring.tex 1.46
Include/unicodeobject.h 2.37
test/string_tests.py 1.15
test/test_unicode.py 1.57
Objects/stringobject.c 2.160
Objects/unicodeobject.c 2.144

Backport will follow.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 18:50

Message:
Logged In: YES 
user_id=6380

Walter, please check this in. I haven't reviewed it
thoroughly, but it looks okay, and the functionality is
right.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-19 16:50

Message:
Logged In: YES 
user_id=89016

Here is the patch (diff.txt).

This a simple copy of the string version. I had to make the 
unicode version of do_xstrip public (as _PyUnicode_XStrip), 
so that the string version can call it when it gets passed 
a unicode object.


----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-18 21:28

Message:
Logged In: YES 
user_id=89016

I have a patch ready that implements the unicode version, 
and the mixed versions, i.e. str.strip(unicode) and 
unicode.strip(str), but CVS doesn't like me today.

Maybe tomorrow!

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-13 04:43

Message:
Logged In: YES 
user_id=3066

(I'd say this is a good reason not to use separate trackers
for features, bugs, & patches -- they're too closely related
to keep them separate, and links between them too tedious
when written only in tracker comments!)

I've updated the documentation for these methods in
Doc/lib/libstdtypes.tex revision 1.87.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-13 03:02

Message:
Logged In: YES 
user_id=6380

Oops, I saw your remark too late.

I've checked in my own version of this for regular
strings...

Feel free to check in your version of this for Unicode
strings, and the docs etc.

----------------------------------------------------------------------

Comment By: Walter D�rwald (doerwalter)
Date: 2002-04-09 17:07

Message:
Logged In: YES 
user_id=89016

So what happens to patch http://www.python.org/sf/424606

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-09 16:31

Message:
Logged In: YES 
user_id=6380

Reopened. A good use case is str(2**100).rstrip('L').

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 11:45

Message:
Logged In: YES 
user_id=156912

Closing, since this has already been rejected by the BDFL.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-03-07 10:24

Message:
Logged In: YES 
user_id=6656

FYI, this has already been rejected once as patch #424606.

----------------------------------------------------------------------

Comment By: Simon Brunning (brunns)
Date: 2002-03-07 09:33

Message:
Logged In: YES 
user_id=156912

string.replace doesn't do the same thing. With our 
hypothetical .strip argument, we have:

>>>fred = '**word**word**' 
>>>fred.strip('*') 
word**word

Using replace, we have:

>>>fred = '**word**word**' 
>>>fred.replace('*', '') 
wordword 

See the difference?

----------------------------------------------------------------------

Comment By: Sean 'Shaleh' Perry (shaleh)
Date: 2002-03-06 23:16

Message:
Logged In: YES 
user_id=37132

why is string.replace() not sufficient?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=444708&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 19:51:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 11:51:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-547211 ] Warn for __coerce__ in new-style classes
Message-ID: <E16ziu8-0006nE-00@usw-sf-web4.sourceforge.net>

Bugs item #547211, was opened at 2002-04-22 14:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547211&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Warn for __coerce__ in new-style classes

Initial Comment:
New-style classes don't support __coerce__, except that
when you define it, coerce() will call it. (But it
won't be called by the binary operators.) Methinks a
warning should be issued when a new-style class defines
__coerce__.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547211&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 20:05:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 12:05:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-545436 ] py-execute-string doesn't work
Message-ID: <E16zj7r-0007Jp-00@usw-sf-web2.sourceforge.net>

Bugs item #545436, was opened at 2002-04-17 19:25
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470

Category: Demos and Tools
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Barry Warsaw (bwarsaw)
Summary: py-execute-string doesn't work

Initial Comment:
The python-mode function py-execute-string appears 
not to work.  In XEmacs 21.4.6 I executed

    M-x py-execute-string
    print "hello world"

and got a "No output." message.

Stepping through the code using edebug it appears 
that in py-execute-region the local variable cmd
(right after the "horrible hack" comment) is set to
the empty string.  I think it's because that chunk
of code uses buffer-local info to determine what
command to run.  Executing py-execute-region from
a fundamental-mode buffer also fails.  Executing
python-mode and then running it again succeeds.

Adding

	(if (equal cmd "")
	    (setq cmd "python"))

right after cmd is set seems to make things work
regardless of the buffer's mode.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2002-04-22 14:05

Message:
Logged In: YES 
user_id=44345

Seems to work for me, thanks.

S


----------------------------------------------------------------------

Comment By: Barry Warsaw (bwarsaw)
Date: 2002-04-22 10:24

Message:
Logged In: YES 
user_id=12800

Skip, tell me what you think of the attached patch.  It sets
a local `shell' variable to the value of py-which-shell
after setting the temporary file to python-mode.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545436&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 20:20:18 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 12:20:18 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16zjMI-0001JC-00@usw-sf-web1.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Open
Resolution: None
Priority: 6
Submitted By: Duncan Booth (duncanb)
>Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-22 15:20

Message:
Logged In: YES 
user_id=33168

Works for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:37

Message:
Logged In: YES 
user_id=31435

Neal, can you try the attached patch in your Linux 
scenario?  Whether it works or not, assign this back to 
me.  It fixes my problem on Win98, so I'm going to check it 
in regardless, but I'll leave the bug open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:29

Message:
Logged In: YES 
user_id=31435

Boosted priority (it's crashing X servers too!).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 14:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Mon Apr 22 20:54:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 12:54:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16zjsu-0001Zx-00@usw-sf-web1.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 6
Submitted By: Duncan Booth (duncanb)
Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-22 15:54

Message:
Logged In: YES 
user_id=31435

Thank you, Neal!  Closing as Fixed, despite that we'll 
never know what it caused it <wink>.  I'll verify on Win2K 
tomorrow and reopen if it fails there (seems exceedingly 
unlikely, though).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-22 15:20

Message:
Logged In: YES 
user_id=33168

Works for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:37

Message:
Logged In: YES 
user_id=31435

Neal, can you try the attached patch in your Linux 
scenario?  Whether it works or not, assign this back to 
me.  It fixes my problem on Win98, so I'm going to check it 
in regardless, but I'll leave the bug open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:29

Message:
Logged In: YES 
user_id=31435

Boosted priority (it's crashing X servers too!).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 14:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 04:48:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 20:48:15 -0700
Subject: [Python-bugs-list] [ python-Bugs-514433 ] bsddb: enable dbopen (file==NULL)
Message-ID: <E16zrHr-0003KI-00@usw-sf-web3.sourceforge.net>

Bugs item #514433, was opened at 2002-02-08 06:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514433&group_id=5470

Category: Extension Modules
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Sam Rushing (rushing)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: bsddb: enable dbopen (file==NULL)

Initial Comment:
dbopen(): if the file argument is NULL, the library 
will use a temporary file.  this is useful if you want 
that, or if you want to specify a large cache so that 
it never actually touches the disk. [i.e., in-memory 
hash/bt]
I've done this by replacing the "s" with a "z" in the 
arg specs for the three open functions.  Seems to work.

-Sam


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-23 13:48

Message:
Logged In: YES 
user_id=29957

Checked into the trunk. Considering this for inclusion
in 2.2.2.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 17:40

Message:
Logged In: YES 
user_id=29957

see patch #545523

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-02-09 08:49

Message:
Logged In: YES 
user_id=6380

Can you submit a patch to the patch manager?


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=514433&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 04:53:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 20:53:35 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method
Message-ID: <E16zrN1-0006dC-00@usw-sf-web1.sourceforge.net>

Feature Requests item #453506, was opened at 2001-08-20 17:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: lists should have a copy method

Initial Comment:
This is per someone on comp.os.python.
It's odd that dictionaries have a copy
method (you can say dict.copy()) but to
copy a list you have to say list[:] or use
copy.copy.  I think list.copy() should be added
for consistency.


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-22 23:53

Message:
Logged In: YES 
user_id=116038

What's the status of this? It seems pretty useful. I could
submit a patch if someone likes...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 04:56:07 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 20:56:07 -0700
Subject: [Python-bugs-list] [ python-Bugs-457114 ] Incorporate timeoutsocket.py into core
Message-ID: <E16zrPT-0006fD-00@usw-sf-web1.sourceforge.net>

Bugs item #457114, was opened at 2001-08-31 01:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorporate timeoutsocket.py into core

Initial Comment:
I was responding to a question on c.l.py earlier about
urllib hanging and was reminded of Tim O'Malley's
timeoutsocket.py.  It's a shim above socket that allows
you to set timeouts on any TCP connections.  Back in
January, Jeff Bauer suggested in c.l.py that it be
included in the core.  I agree that it provides useful
extra functionality beyond the current socket
implementation and would like it to be considered for
addition to the standard distribution.  Here's a
pointer:

    http://www.timo-tasi.org/python/timeoutsocket.py

Here's how you use it:

    import timeoutsocket
    import httplib
    timeoutsocket.setDefaultSocketTimeout(20)
    # at this point any sockets created
    # will have a 20-second timeout
    h = httplib.HTTP("www.python.org")

Pretty simple, huh?

Skip


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-22 23:56

Message:
Logged In: YES 
user_id=116038

For the record, I have a patch. I'm coordinating with
Bernard Yue for some preliminary testing and it'll added
into the patch tracker shortly.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2002-04-17 11:32

Message:
Logged In: YES 
user_id=44345

Check the python-dev mailing list archive for the past few
days.  There is an active thread about this topic.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 08:14

Message:
Logged In: YES 
user_id=6380

Bernard Yue is considering to tackle this. See the thread in
python-dev starting at
http://mail.python.org/pipermail/python-dev/2002-April/023278.html
Maybe you two can work on this together?


----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-17 01:22

Message:
Logged In: YES 
user_id=116038

I'd be interested in integrating the two modules if no one
has tackled this yet. Seems like it would make a cool
feature.

I'm a little unclear on where you think the best integration
(and I'm a little new to the interpreter source :) ) point
would be - in the python module interface socket.py or the
lower level c interface socketmodule.c.

----------------------------------------------------------------------

Comment By: Skip Montanaro (montanaro)
Date: 2001-09-05 16:46

Message:
Logged In: YES 
user_id=44345

While the offer is tempting, I almost certainly don't
understand the various bits associated with sockets and
don't have the time to learn them, so I'm unassigning.
Hopefully someone else will pick it up for 2.3...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 14:26

Message:
Logged In: YES 
user_id=6380

Skip, want to work on this? If not, please unassign it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-31 09:10

Message:
Logged In: YES 
user_id=6380

I like this idea, but don't think this exact implementation
belongs in the standard library. The hacks deployed to
"install" the special effect are a bit fragile, e.g.
consider "import socket as foo"; and they shouldn't be
necessary.

When integrated into the standard library, it should
probably become a standard feature of the socket object.
Note that on Windows, socket.socket is already a shim on top
of _socket.socket, so that would be a convenient starting
point.

Patch anyone?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=457114&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 06:43:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 22 Apr 2002 22:43:24 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-453506 ] lists should have a copy method
Message-ID: <E16zt5I-00054N-00@usw-sf-web4.sourceforge.net>

Feature Requests item #453506, was opened at 2001-08-20 17:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: lists should have a copy method

Initial Comment:
This is per someone on comp.os.python.
It's odd that dictionaries have a copy
method (you can say dict.copy()) but to
copy a list you have to say list[:] or use
copy.copy.  I think list.copy() should be added
for consistency.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-23 01:43

Message:
Logged In: YES 
user_id=31435

I doubt Guido would go for it.  dicts grew a .copy() method 
*because* there was no convenient syntax like list[:] that 
worked for dicts.  That's not a reason to add a .copy() 
method to lists too.  Note that if you're too fond of 
uniformity <wink>, don't use any of these:  use copy.copy() 
or copy.deepcopy().  Python doesn't need four ways to 
spell "copy this list".  Oops:  make that five.  list
(somelist) also copies a list.  In 2.2, dict(somedict) also 
copies a dict.  Enough already.

----------------------------------------------------------------------

Comment By: Michael Gilfix (mgilfix)
Date: 2002-04-22 23:53

Message:
Logged In: YES 
user_id=116038

What's the status of this? It seems pretty useful. I could
submit a patch if someone likes...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=453506&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 08:10:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 00:10:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E16zuRU-0006Ms-00@usw-sf-web2.sourceforge.net>

Bugs item #216388, was opened at 2000-10-09 11:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
Resolution: Remind
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


----------------------------------------------------------------------

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-23 17:10

Message:
Logged In: YES 
user_id=29957

well, StringIO does the correct thing (returns back
a unicode string), fwiw. 

the offending checkin for cStringIO was 2.30. The commit
log is:

  date: 2001/09/24 17:34:52;  author: lemburg;  state: Exp;
 lines: +5 -9
  StringIO patch #462596: let's [c]StringIO accept read
buffers on
  input to .write() too.

The referenced patch is actually doing a bit more than
'write':
  This patch allows using arbitrary read-buffer
  compatible objects as basis for StringIO and cStringIO
  objects.

I'm not sure what on the appropriate way to fix this

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-18 22:53

Message:
Logged In: YES 
user_id=6380

Hm, that's bad. An error on write(u"...") is much preferred
over wreiting garbage. :-(

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 16:38

Message:
Logged In: YES 
user_id=29957

Hm. This no longer produces the above error. However, it
now produces:
>>> import cStringIO 
>>> s=cStringIO.StringIO(u"abcdefgh") 
>>> s.getvalue()
'a\x00b\x00c\x00d\x00e\x00f\x00g\x00h\x00'

Should it produce a unicode string back? 
(thought I'd go through some of the older sf bugs)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-04 21:18

Message:
Logged In: NO 

9;lo;;99999999999999999999999

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-02 09:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-17 13:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-11 03:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-08 14:56

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-13 08:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 19:34

Message:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 08:59:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 00:59:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-546117 ] readlines() bombs - last line incomplete
Message-ID: <E16zvD9-0005wl-00@usw-sf-web3.sourceforge.net>

Bugs item #546117, was opened at 2002-04-19 13:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470

>Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
>Priority: 3
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: readlines() bombs - last line incomplete

Initial Comment:
HP-UX 11 64bit, compiled with HP ansi c compiler.
Python version 2.2.1rc2

>>> f=open(some_big_file)
>>> f.readlines()
Pid 23292 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

Happens when last line of file lacks a terminating \n,
also the file has to be big enough (my example is about
2K in size)

Oddly, xreadlines() can be created, but attempting to
iterate over it crashes before the first line is 
returned:
>>> f=open(some_big_file)
>>> lines=f.xreadlines()    # OK so far
>>> for line in lines:
...    print line      # never gets here
...

Pid 23257 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

I'll try 2.2.1 final.


----------------------------------------------------------------------

>Comment By: Peter Harris (scav)
Date: 2002-04-23 07:59

Message:
Logged In: YES 
user_id=8911

I think it's compiler/architecture dependent. It works fine 
on Linux.

Re-compiling Objects/fileobject.c without optimisation 
cures the problem. I think HP's compiler is a bit dodgy, 
because the last version of Python was dumping core until I 
recompiled longobject.c.

I would try compiling with gcc but I don't have it on our 
HP machine.

I think the README should maybe warn HP PA-RISC 2.0 users 
that the C compiler will occasionally break things.

Thanks for your time.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 17:45

Message:
Logged In: YES 
user_id=6380

I can't reproduce this on Linux. Can you upload the data
file or (preferably, if you have access) on a Linux system,
with Python 2.2.1? I'd like to see if this is data dependent
or platform specific before we go any further with this.

----------------------------------------------------------------------

Comment By: Peter Harris (scav)
Date: 2002-04-22 11:12

Message:
Logged In: YES 
user_id=8911

2.2.1 final does it too. :(

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 09:27:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 01:27:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E16zve5-0006Fo-00@usw-sf-web3.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 11:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Duncan Booth (duncanb)
Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Duncan Booth (duncanb)
Date: 2002-04-23 08:27

Message:
Logged In: YES 
user_id=74031

The fix works fine for me on Win2K.

Actually I can add some more information which throws a bit 
of light on the subject. On my system a string of 2974 "%" 
characters is fine, and results in a popup window 32762 
pixels wide. A string of 2975 "%" characters fails to give 
me a window which would be 11 pixels wider and dies with an 
access violation.

My best guess is that Win2K (not a 16 bit operating system 
at all, honest!) is doing a 16 bit calculation which 
overflows. Probably the OS returns an error and something 
in tk or tkinter doesn't manage to handle the error 
condition correctly.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 19:54

Message:
Logged In: YES 
user_id=31435

Thank you, Neal!  Closing as Fixed, despite that we'll 
never know what it caused it <wink>.  I'll verify on Win2K 
tomorrow and reopen if it fails there (seems exceedingly 
unlikely, though).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-22 19:20

Message:
Logged In: YES 
user_id=33168

Works for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 18:37

Message:
Logged In: YES 
user_id=31435

Neal, can you try the attached patch in your Linux 
scenario?  Whether it works or not, assign this back to 
me.  It fixes my problem on Win98, so I'm going to check it 
in regardless, but I'll leave the bug open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 18:29

Message:
Logged In: YES 
user_id=31435

Boosted priority (it's crashing X servers too!).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 18:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 17:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 17:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 15:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 10:20:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 02:20:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-546749 ] odd exception moving file to trash
Message-ID: <E16zwTU-0007lO-00@usw-sf-web2.sourceforge.net>

Bugs item #546749, was opened at 2002-04-21 15:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: odd exception moving file to trash

Initial Comment:
MacPython 2.2.1 on OSX.1.4, from IDE:
>>> import macfs, findertools
>>> f = open("a_file_to_trash", "w")
>>> f.close()
>>> fss = macfs.FSSpec("a_file_to_trash")
>>> vrefnum = fss.as_tuple()[0]
>>> vrefnum, pardir = macfs.FindFolder(vrefnum, 
"trsh", 1)
>>> trashfolder = macfs.FSSpec((vrefnum, pardir, 
"")).as_pathname()
>>> findertools.move("a_file_to_trash", 
trashfolder)
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:findertools.py", line 74, in move
    return finder.move(src_fss, to=dst_fss)
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:lib-
scriptpackages:Finder:Standard_Suite.py", line 
293, in move
    raise aetools.Error, 
aetools.decodeerror(_arguments)
aetools.Error: (0, 'component result = no error', 
None)
>>> 

The file _does_ get moved to the trash, but that's 
not visible in the Finder's Trash window, not even 
after more items are dragged to the trash 
manually.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-23 11:20

Message:
Logged In: YES 
user_id=45365

Ah! If it does show up if the thrash wasn't empty before then I think this is one of those finder quirks that happen when you do something behind its back. Esp. with the thrash this is imaginable: it is a figment of the finders imagination, consisting in reality of numerous folders on numerous disks. I think we should ignore this bit of the problem for now, and later may try adding findertools.touched() here or there. Or moving to the finder thrash object in stead of the folder underlying it.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-04-22 17:23

Message:
Logged In: YES 
user_id=92689

(sorry for the duplicate...)

Yes I'm sure: there's nothing visible in the Finder, but it 
does show with "ls" in the terminal. New finding: it
_does_ show if the trash wasn't empty before...

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 15:18

Message:
Logged In: YES 
user_id=45365

This is a duplicate of #493826. I'm leaving this in too, though, because the bit about the resulting file not being visible in the thrash is something not in the other error report.

Also, a question: are you sure about not seeing the result in the Trash window? I *am* seeing it there. And I'm tempted to think that errn==0 simply doesn't signal an error...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 10:48:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 02:48:28 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-547481 ] In-place reverse() and sort() for slices
Message-ID: <E16zwuS-0007ed-00@usw-sf-web4.sourceforge.net>

Feature Requests item #547481, was opened at 2002-04-23 11:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Bender (bbender)
Assigned to: Nobody/Anonymous (nobody)
Summary: In-place reverse() and sort() for slices

Initial Comment:
In order to apply sort() or reverse() to only part of a
sequence (a slice), the following code seems to be
necessary:

	# a is a sequence
	tmp = s[m:n]
	tmp.sort()		# or tmp.reverse()
	s[m:n] = tmp

It would be much nicer to apply sort() or reverse() to
the slice directly:

	a[m:n].sort()

However, this does not work, since the slice returns a
new sequence object, on which sort() or reverse() will
work, instead of working on the slice in-place.
After sort() is done, the modified object will be
discarded, since it cannot be assigned to anything as
sort() and reverse() do not have a return value.

Therefore, the line above is accepted by the
interpreter even though it is completely useless.

My proposal is to change the semantics of applying
sort() and reverse() to slices such as to work in-place
on the slice, in stead of working on the new object
created by the slicing operation.

This would be similar to slice assignment, which also
does not create a new object.

Would this change require a PEP?

Bernhard Bender

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 13:52:37 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 05:52:37 -0700
Subject: [Python-bugs-list] [ python-Bugs-547537 ] cStringIO mangles Unicode
Message-ID: <E16zzmf-0001Iy-00@usw-sf-web4.sourceforge.net>

Bugs item #547537, was opened at 2002-04-23 08:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cStringIO mangles Unicode

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 13:55:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 05:55:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-216388 ] cStringIO rejects Unicode strings
Message-ID: <E16zzpU-0003vq-00@usw-sf-web1.sourceforge.net>

Bugs item #216388, was opened at 2000-10-08 20:42
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470

Category: Unicode
Group: Feature Request
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: cStringIO rejects Unicode strings

Initial Comment:
>>> import cStringIO
>>> s=cStringIO.StringIO(u"abcdefgh")
Traceback (innermost last):
  File "<pyshell#8>", line 1, in ?
    s=cStringIO.StringIO(u"abcdefgh")
TypeError: expected string, unicode found


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 08:55

Message:
Logged In: YES 
user_id=6380

Let's please move this discussion to a new bug report on the
new problem. I've opened one, 547537, and summarized the
issue there. I've assigned ot to MAL.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-23 03:10

Message:
Logged In: YES 
user_id=29957

well, StringIO does the correct thing (returns back
a unicode string), fwiw. 

the offending checkin for cStringIO was 2.30. The commit
log is:

  date: 2001/09/24 17:34:52;  author: lemburg;  state: Exp;
 lines: +5 -9
  StringIO patch #462596: let's [c]StringIO accept read
buffers on
  input to .write() too.

The referenced patch is actually doing a bit more than
'write':
  This patch allows using arbitrary read-buffer
  compatible objects as basis for StringIO and cStringIO
  objects.

I'm not sure what on the appropriate way to fix this

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-18 08:53

Message:
Logged In: YES 
user_id=6380

Hm, that's bad. An error on write(u"...") is much preferred
over wreiting garbage. :-(

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-18 02:38

Message:
Logged In: YES 
user_id=29957

Hm. This no longer produces the above error. However, it
now produces:
>>> import cStringIO 
>>> s=cStringIO.StringIO(u"abcdefgh") 
>>> s.getvalue()
'a\x00b\x00c\x00d\x00e\x00f\x00g\x00h\x00'

Should it produce a unicode string back? 
(thought I'd go through some of the older sf bugs)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2002-04-04 06:18

Message:
Logged In: NO 

9;lo;;99999999999999999999999

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-03-01 17:31

Message:
Logged In: YES 
user_id=31392

Setting back to normal priority for 2.2


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-16 21:29

Message:
Lowered priority to reflect my previous comments; I don't think I'll have time to do this for Python 2.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-10 11:07

Message:
Status:  Jim said I can work on it, but the priority isn't very high for him.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2001-01-07 22:56

Message:
Ok, ok, ok... I've sent a prod to appropriate people.  This *should* be interesting to have done.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2000-12-12 16:00

Message:
Assigned to Fred -- maybe you can prod Jim into looking into this.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2000-10-09 04:34

Message:
I've marked this as feature request since making the standard
lib Unicode compatible is a post-2.0 project (probably a good
one for 2.1).


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=216388&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 13:59:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 05:59:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-547537 ] cStringIO mangles Unicode
Message-ID: <E16zzt3-0003xi-00@usw-sf-web1.sourceforge.net>

Bugs item #547537, was opened at 2002-04-23 08:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cStringIO mangles Unicode

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 08:59

Message:
Logged In: YES 
user_id=6380

I wonder if perhaps the fix is as simple as using "t#"
instead of "s#" in the PyArg_... format string in P_write().
That accepts Unicode strings as args to write() only when
they are ASCII (actually, it uses the default encoding).

Marc-Andre, can you explain the reason for the change in the
first place (other than fixing a dubious dependency on
PyString_GetSize() raising an exception for a non-string
object)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 14:06:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 06:06:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-546117 ] readlines() bombs - last line incomplete
Message-ID: <E17000Y-0001ky-00@usw-sf-web2.sourceforge.net>

Bugs item #546117, was opened at 2002-04-19 09:23
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470

Category: Documentation
>Group: Platform-specific
>Status: Closed
>Resolution: Wont Fix
Priority: 3
Submitted By: Peter Harris (scav)
Assigned to: Nobody/Anonymous (nobody)
Summary: readlines() bombs - last line incomplete

Initial Comment:
HP-UX 11 64bit, compiled with HP ansi c compiler.
Python version 2.2.1rc2

>>> f=open(some_big_file)
>>> f.readlines()
Pid 23292 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

Happens when last line of file lacks a terminating \n,
also the file has to be big enough (my example is about
2K in size)

Oddly, xreadlines() can be created, but attempting to
iterate over it crashes before the first line is 
returned:
>>> f=open(some_big_file)
>>> lines=f.xreadlines()    # OK so far
>>> for line in lines:
...    print line      # never gets here
...

Pid 23257 received a SIGSEGV for stack growth failure.
Possible causes: insufficient memory or swap space,
or stack size exceeded maxssiz.
Memory fault(coredump)

I'll try 2.2.1 final.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 09:06

Message:
Logged In: YES 
user_id=6380

OK, I've added a note to the README. Sigh.

----------------------------------------------------------------------

Comment By: Peter Harris (scav)
Date: 2002-04-23 03:59

Message:
Logged In: YES 
user_id=8911

I think it's compiler/architecture dependent. It works fine 
on Linux.

Re-compiling Objects/fileobject.c without optimisation 
cures the problem. I think HP's compiler is a bit dodgy, 
because the last version of Python was dumping core until I 
recompiled longobject.c.

I would try compiling with gcc but I don't have it on our 
HP machine.

I think the README should maybe warn HP PA-RISC 2.0 users 
that the C compiler will occasionally break things.

Thanks for your time.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:45

Message:
Logged In: YES 
user_id=6380

I can't reproduce this on Linux. Can you upload the data
file or (preferably, if you have access) on a Linux system,
with Python 2.2.1? I'd like to see if this is data dependent
or platform specific before we go any further with this.

----------------------------------------------------------------------

Comment By: Peter Harris (scav)
Date: 2002-04-22 07:12

Message:
Logged In: YES 
user_id=8911

2.2.1 final does it too. :(

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546117&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 16:09:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 08:09:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E1701vG-0005Nk-00@usw-sf-web1.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 07:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Duncan Booth (duncanb)
Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-23 11:09

Message:
Logged In: YES 
user_id=31435

It's Windows -- you'll never know.  Like it didn't fail for 
Guido on his Win98SE but did for me on my Win98SE, on *my* 
Win2K Pro the original example works fine.  Also worked 
fine s/3000/4000/.  s/3000/5000/, though, and it died with 
an access violation in the Tk DLL.

----------------------------------------------------------------------

Comment By: Duncan Booth (duncanb)
Date: 2002-04-23 04:27

Message:
Logged In: YES 
user_id=74031

The fix works fine for me on Win2K.

Actually I can add some more information which throws a bit 
of light on the subject. On my system a string of 2974 "%" 
characters is fine, and results in a popup window 32762 
pixels wide. A string of 2975 "%" characters fails to give 
me a window which would be 11 pixels wider and dies with an 
access violation.

My best guess is that Win2K (not a 16 bit operating system 
at all, honest!) is doing a 16 bit calculation which 
overflows. Probably the OS returns an error and something 
in tk or tkinter doesn't manage to handle the error 
condition correctly.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 15:54

Message:
Logged In: YES 
user_id=31435

Thank you, Neal!  Closing as Fixed, despite that we'll 
never know what it caused it <wink>.  I'll verify on Win2K 
tomorrow and reopen if it fails there (seems exceedingly 
unlikely, though).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-22 15:20

Message:
Logged In: YES 
user_id=33168

Works for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:37

Message:
Logged In: YES 
user_id=31435

Neal, can you try the attached patch in your Linux 
scenario?  Whether it works or not, assign this back to 
me.  It fixes my problem on Win98, so I'm going to check it 
in regardless, but I'll leave the bug open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 14:29

Message:
Logged In: YES 
user_id=31435

Boosted priority (it's crashing X servers too!).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 14:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 13:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 11:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 20:23:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 12:23:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-546078 ] IDLE calltips cause application error
Message-ID: <E1705t5-00062F-00@usw-sf-web2.sourceforge.net>

Bugs item #546078, was opened at 2002-04-19 04:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470

Category: IDLE
Group: None
Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Duncan Booth (duncanb)
Assigned to: Tim Peters (tim_one)
Summary: IDLE calltips cause application error

Initial Comment:
I can reproduce this bug on Python 2.2 and Python 2.1 
on different Windows 2000 machines.

Start a copy of IDLE.
At the interactive prompt type the following 
interactive session:

>>> s = "%"*3000
>>> def f(p=s): pass

>>> f(

Instead of showing a calltip window with the arguments 
for f, idle dies with an application error dialog:

idle: pythonw.exe - Application Error
The instruction at "0x1000a01f" referenced memory 
at "0x00000000". The memory could not be "read".

This happens whenever the calltip string gets too long 
(somewhere between 2500 and 3000 characters).


----------------------------------------------------------------------

Comment By: Jeffrey Hobbs (hobbs)
Date: 2002-04-23 12:23

Message:
Logged In: YES 
user_id=72656

This is due to limitations in X (which still requires 
dimensions constrained to 16 bits), and subsequently the 
Xlib emulation side for Windows.  The Unix side has been 
fixed with Tk patch 541999:

https://sourceforge.net/tracker/index.php?
func=detail&aid=541999&group_id=12997&atid=312997

A subsequent patch for Windows is still needed (though on 
Win2K I can go to 10K chars before having problems, and 
then the label just does blank - no crash).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-23 08:09

Message:
Logged In: YES 
user_id=31435

It's Windows -- you'll never know.  Like it didn't fail for 
Guido on his Win98SE but did for me on my Win98SE, on *my* 
Win2K Pro the original example works fine.  Also worked 
fine s/3000/4000/.  s/3000/5000/, though, and it died with 
an access violation in the Tk DLL.

----------------------------------------------------------------------

Comment By: Duncan Booth (duncanb)
Date: 2002-04-23 01:27

Message:
Logged In: YES 
user_id=74031

The fix works fine for me on Win2K.

Actually I can add some more information which throws a bit 
of light on the subject. On my system a string of 2974 "%" 
characters is fine, and results in a popup window 32762 
pixels wide. A string of 2975 "%" characters fails to give 
me a window which would be 11 pixels wider and dies with an 
access violation.

My best guess is that Win2K (not a 16 bit operating system 
at all, honest!) is doing a 16 bit calculation which 
overflows. Probably the OS returns an error and something 
in tk or tkinter doesn't manage to handle the error 
condition correctly.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 12:54

Message:
Logged In: YES 
user_id=31435

Thank you, Neal!  Closing as Fixed, despite that we'll 
never know what it caused it <wink>.  I'll verify on Win2K 
tomorrow and reopen if it fails there (seems exceedingly 
unlikely, though).

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-22 12:20

Message:
Logged In: YES 
user_id=33168

Works for me.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 11:37

Message:
Logged In: YES 
user_id=31435

Neal, can you try the attached patch in your Linux 
scenario?  Whether it works or not, assign this back to 
me.  It fixes my problem on Win98, so I'm going to check it 
in regardless, but I'll leave the bug open.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 11:29

Message:
Logged In: YES 
user_id=31435

Boosted priority (it's crashing X servers too!).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 11:16

Message:
Logged In: YES 
user_id=6380

Yes, I'm positive. I've typed it in exactly, and verified
that I'm using 2.2.1 #34.

Regardless, I think that clamping the length of the string
makes a lot of sense.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 10:58

Message:
Logged In: YES 
user_id=31435

Guido, are you sure this works for you?  It crashed for me 
on Win98SE, using the distributed 2.2.1.  It's an "illegal 
operation" error, and it says

PYTHONW caused a general protection fault
in module DIBENG.DLL at 0005:00003f2f.

MS claims this is due to a bad display driver:

http://support.microsoft.com/directory/article.asp?ID=KB;EN-
US;Q235618

but I doubt that's really the cause here.  I also doubt 
we'll ever know the true cause:  we're deep in the land of 
undocumented MS DLLs without source code, and how they 
interact with Tk's implementation.

Offhand I guess the problem would go away if CallTips.py 
clamped the length of the string it tried to display.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-22 10:41

Message:
Logged In: YES 
user_id=6380

I just tried this with Python 2.2.1 and cannot reproduce it
either, but then I'm on Win98 and don't have easy access to
Win2K. If this really is Win2K specific, TIm is our only
hope, so I've assigned to him. (Tim, all I need at this
point is to see whether you can reproduce this on Win2k.)

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2002-04-21 08:33

Message:
Logged In: YES 
user_id=33168

I couldn't replicate this bug...well, not exactly.
On Linux (redhat 7.2), I tried the example and there was no
problem.  I increased 3000 to 30,000 and still no problem. 
I then changed % to * and my X server crashed!

So I think the problem you are seeing is Windows specific,
but there may be a Tk problem also.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546078&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 22:01:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 14:01:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-546749 ] odd exception moving file to trash
Message-ID: <E1707Pg-0006rp-00@usw-sf-web4.sourceforge.net>

Bugs item #546749, was opened at 2002-04-21 15:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Just van Rossum (jvr)
Assigned to: Jack Jansen (jackjansen)
Summary: odd exception moving file to trash

Initial Comment:
MacPython 2.2.1 on OSX.1.4, from IDE:
>>> import macfs, findertools
>>> f = open("a_file_to_trash", "w")
>>> f.close()
>>> fss = macfs.FSSpec("a_file_to_trash")
>>> vrefnum = fss.as_tuple()[0]
>>> vrefnum, pardir = macfs.FindFolder(vrefnum, 
"trsh", 1)
>>> trashfolder = macfs.FSSpec((vrefnum, pardir, 
"")).as_pathname()
>>> findertools.move("a_file_to_trash", 
trashfolder)
Traceback (most recent call last):
  File "<input>", line 1, in ?
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:findertools.py", line 74, in move
    return finder.move(src_fss, to=dst_fss)
  File "Titaantje:Applications:Python 
2.2.1:Mac:Lib:lib-
scriptpackages:Finder:Standard_Suite.py", line 
293, in move
    raise aetools.Error, 
aetools.decodeerror(_arguments)
aetools.Error: (0, 'component result = no error', 
None)
>>> 

The file _does_ get moved to the trash, but that's 
not visible in the Finder's Trash window, not even 
after more items are dragged to the trash 
manually.

----------------------------------------------------------------------

>Comment By: Jack Jansen (jackjansen)
Date: 2002-04-23 23:01

Message:
Logged In: YES 
user_id=45365

Closing as a duplicate of #493826

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-23 11:20

Message:
Logged In: YES 
user_id=45365

Ah! If it does show up if the thrash wasn't empty before then I think this is one of those finder quirks that happen when you do something behind its back. Esp. with the thrash this is imaginable: it is a figment of the finders imagination, consisting in reality of numerous folders on numerous disks. I think we should ignore this bit of the problem for now, and later may try adding findertools.touched() here or there. Or moving to the finder thrash object in stead of the folder underlying it.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2002-04-22 17:23

Message:
Logged In: YES 
user_id=92689

(sorry for the duplicate...)

Yes I'm sure: there's nothing visible in the Finder, but it 
does show with "ls" in the terminal. New finding: it
_does_ show if the trash wasn't empty before...

----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2002-04-22 15:18

Message:
Logged In: YES 
user_id=45365

This is a duplicate of #493826. I'm leaving this in too, though, because the bit about the resulting file not being visible in the thrash is something not in the other error report.

Also, a question: are you sure about not seeing the result in the Trash window? I *am* seeing it there. And I'm tempted to think that errn==0 simply doesn't signal an error...

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=546749&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 22:21:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 14:21:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-543148 ] Memory leak with stackframes + inspect
Message-ID: <E1707jJ-0007MM-00@usw-sf-web2.sourceforge.net>

Bugs item #543148, was opened at 2002-04-12 14:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Bernhard Herzog (bernhard)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Memory leak with stackframes + inspect

Initial Comment:
The following program leaks memory on Python 2.1.3:

import inspect

def leak():
    frame = inspect.currentframe()

while 1:
    leak()

(On Linux at least the process size grows *very*
quickly!)

System:
Python 2.1.3 (#1, Apr 12 2002, 20:09:56) 
[GCC 2.95.4 20011006 (Debian prerelease)] on linux2


It has no memory problems with Python 2.2.

Workaround: del frame in leak.
The docs at least should mention this.


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-23 17:21

Message:
Logged In: YES 
user_id=3066

Added text & example based on previous comment to
Doc/lib/libinspect.tex revisions 1.3.2.1, 1.10.6.1, and 1.11.

----------------------------------------------------------------------

Comment By: Bernhard Herzog (bernhard)
Date: 2002-04-13 10:26

Message:
Logged In: YES 
user_id=2369

For the documentation, perhaps a note in section 3.11.4,
"The interpreter stack", might be appropriate. Something
like this:

   In Python 2.1 and earlier, stackframes stored directly or
   indirectly in local variables can easily cause referency
   cycles the garbage collector can't collect, leading to
   memory leaks. To avoid this, it's a good idea to
   explicitly remove the cycle in a finally: clause. For
   example:

   def handle_stackframe_without_leak():
       frame = inspect.currentframe()
       try:
           # do something with the frame
       finally:
           del frame


The situation here is very similar to sys.exc_info and the
traceback in its return value.



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-13 01:25

Message:
Logged In: YES 
user_id=31435

The slower leak in current CVS got plugged via bounding the 
frameobject free_list, in

Objects/frameobject.c; new revision: 2.61

Also backported to the 2.2 branch.

Reassigned to Fred for 2.1, in case he can figure out what 
kind of doc change might help.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 20:03

Message:
Logged In: YES 
user_id=31435

Neil, are there other gcable containers that use free 
lists?  Offhand I could only think of tuples, but they 
already put a bound on the their free list size 
(MAXSAVEDTUPLES).  Of course I agree it is a general 
problem.

Another approach could expose part of the guts of 
_PyObject_GC_Malloc, and tell free-list addicts (FLAs) they 
have to call that on every "virtual" allocation; similarly 
for virtual deallocation.  The "excess" approach remains, I 
think, a clever and solid one, and from that view "the 
problem" is that the FLAs simply don't participate in it.  
OTOH, FLAs are using a free-list because they're keen to 
make allocation as fast as possible, so making newing 
external calls is unattractive on that ground.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 19:05

Message:
Logged In: YES 
user_id=31435

Reassigned to me.

Bernhard, can you suggest where the docs could say 
something in 2.1 that would do you any good?  And/or what 
they could say that would help?  Documenting cases where 
cycles can cause leaks hasn't appeared to do much good over 
the years -- if someone doesn't already know that assigning 
the current frame to a local vrbl in that frame causes a 
cycle, or why such a cycle leaks before 2.2, they're not 
easy things to get across.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-12 18:54

Message:
Logged In: YES 
user_id=35752

Sounds like a sensible solution.  I think this is a 
problem with all GC collected objects that use a free list.
I can't think of a nice general solution for it though (other
than removing the other free lists :).

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:39

Message:
Logged In: YES 
user_id=31435

OK, it *is* the frameobject free_list that's screwing us 
here.  Disable that mechanism, and the fleak2.py output is 
steady over time, and the process doesn't grow over time.

gc is triggered by an excess of allocations over 
deallocations, by some delta N.  After the first N frames 
in cycles are allocated, gc cleans them up, but they all go 
into the free_list.  Then it takes N+N frames in cycles 
before gc is triggered again (the first N come out of the 
free_list so don't bump the allocation count at all), and 
all N+N are returned to the free_list.  Then it takes N+N+N 
frames in cycles before gc is triggered again, etc.  Over 
time, the number of frames in the free_list grows without 
bound.

I'm thinking about putting a bound on it.  That is, if 
frame_dealloc sees there are already K frames on free_list, 
free the memory instead of keeping it devoted to frames 
forever.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:27

Message:
Logged In: YES 
user_id=31435

Ack, I'm hallucinating -- forget fleak.py.  What it 
actually shows is that we're *not* leaking frames(!).

Something is still very strange, but I don't know what.  
Staring at the output from (the much simpler) fleak2.py 
shows that the 1st generation keeps growing over time, 
which is weird by itself.  gc believes it reclaims 
everything unreachable each time it triggers too, yet the 
process grows about 50MB/minute on my box.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 18:00

Message:
Logged In: YES 
user_id=31435

The attached fleak.py seems to show that, under 2.2 and 
current CVS, we're leaking one frame per top-level call.  
It prints

gc: collecting generation 2...
gc: objects in each generation: 0 0 21971
gc: done, 20000 unreachable, 0 uncollectable.
20000
[<frame object at 0x00755B90>]
{<type 'frame'>: 20000}

However, stranger, if you set VARIANT=1 at the top, the 
output changes to

gc: collecting generation 2...
gc: objects in each generation: 0 0 2070
gc: done, 99 unreachable, 0 uncollectable.
99
[<frame object at 0x0077C770>]
{<type 'frame'>: 99}

So (this will make sense if you look at the code), the 
*frequency* of gc determines how much stuff is considered 
unreachable in the end.  Disabling the frameobject 
free_list didn't appear to make any difference to this.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-12 15:16

Message:
Logged In: YES 
user_id=31435

Yes, when you create a cyclic structure involving frames in 
2.1, it plain leaks -- frames aren't looked at by the 
cyclic garbage detector in 2.1.  Frames were added to 
cyclic gc collection in 2.2.

However, it sure looks to me like this program *still* 
leaks in 2.2 (and current CVS), just a lot slower (I've 
watched it grow to over 30MB on Windows, with no sign of 
ever stopping).  But if I call gc.collect() periodically in 
the "while 1:" (every 100th time) it doesn't leak at all 
(and stays at about 2MB).  Assigning to Neal in the hopes 
that it will be instantly obvious to him why gc isn't 
happening without being forced -- or perhaps why gc is 
happening but is ineffective in this case.  Maybe the 
frameobject free_list is interfering?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=543148&group_id=5470



From noreply@sourceforge.net  Tue Apr 23 23:17:15 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 15:17:15 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-547481 ] In-place reverse() and sort() for slices
Message-ID: <E1708b5-0007yt-00@usw-sf-web2.sourceforge.net>

Feature Requests item #547481, was opened at 2002-04-23 09:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Bender (bbender)
Assigned to: Nobody/Anonymous (nobody)
Summary: In-place reverse() and sort() for slices

Initial Comment:
In order to apply sort() or reverse() to only part of a
sequence (a slice), the following code seems to be
necessary:

	# a is a sequence
	tmp = s[m:n]
	tmp.sort()		# or tmp.reverse()
	s[m:n] = tmp

It would be much nicer to apply sort() or reverse() to
the slice directly:

	a[m:n].sort()

However, this does not work, since the slice returns a
new sequence object, on which sort() or reverse() will
work, instead of working on the slice in-place.
After sort() is done, the modified object will be
discarded, since it cannot be assigned to anything as
sort() and reverse() do not have a return value.

Therefore, the line above is accepted by the
interpreter even though it is completely useless.

My proposal is to change the semantics of applying
sort() and reverse() to slices such as to work in-place
on the slice, in stead of working on the new object
created by the slicing operation.

This would be similar to slice assignment, which also
does not create a new object.

Would this change require a PEP?

Bernhard Bender

----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-23 22:17

Message:
Logged In: YES 
user_id=35752

This would take some deep magic to make work and would
be a fundamental change to the language.  lst[m:m] is an
expression that returns a new object.  The chances of this
change being accepted is about zero.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 01:06:36 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 17:06:36 -0700
Subject: [Python-bugs-list] [ python-Bugs-547138 ]  - open - alias generates error
Message-ID: <E170AIu-0000gD-00@usw-sf-web2.sourceforge.net>

Bugs item #547138, was opened at 2002-04-22 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: rodney holland (rhhrhh)
Assigned to: Tim Peters (tim_one)
Summary:  - open - alias generates error

Initial Comment:
Using python 2.2.1c on windows 98 the alias -  open  -
  gives the following error.  The function  - file -   
works fine.


>>> f=open("rfile.dat",'w')
Traceback (most recent call last):
  File "<pyshell#42>", line 1, in ?
    f=open("rfile.dat",'w')
TypeError: an integer is required
>>> 

----------------------------------------------------------------------

Comment By: Robert D. Penny (wobblie)
Date: 2002-04-24 00:06

Message:
Logged In: YES 
user_id=393585

I just got caught by the same "gotcha" using 2.2.1 on linux.
Thanks for pointing out the problem.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 17:09

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try the released 2.2.1, although I 
can't imagine why it would make any difference.  Nothing 
changed here, and

C:\Python22>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> file is open
1
>>>

That is, "file" and "open" aren't merely aliases, they're 
exactly the same object.

Are you using IDLE or PythonWin or ...?  "<pyshell#42>" 
doesn't appear in a DOS-box traceback.

Ah, I know!  You did something stupid <wink> you're not 
showing us, like

from os import *

Here:

>>> open
<type 'file'>
>>> from os import *
>>> open
<built-in function open>
>>>

If you replace the builtin open with os.open, then "an 
integer is required" is the expected error.  The builtin 
open and os.open are different functions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 02:18:54 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 18:18:54 -0700
Subject: [Python-bugs-list] [ python-Bugs-547138 ]  - open - alias generates error
Message-ID: <E170BQs-0001Pk-00@usw-sf-web2.sourceforge.net>

Bugs item #547138, was opened at 2002-04-22 11:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: rodney holland (rhhrhh)
Assigned to: Tim Peters (tim_one)
Summary:  - open - alias generates error

Initial Comment:
Using python 2.2.1c on windows 98 the alias -  open  -
  gives the following error.  The function  - file -   
works fine.


>>> f=open("rfile.dat",'w')
Traceback (most recent call last):
  File "<pyshell#42>", line 1, in ?
    f=open("rfile.dat",'w')
TypeError: an integer is required
>>> 

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2002-04-23 21:18

Message:
Logged In: YES 
user_id=31435

Closing as not-a-bug since this is a not-quite-common 
mistake and there's no reason to believe it's anything 
other than that.  Don't use "import *" and your life will 
be happier <wink>.

----------------------------------------------------------------------

Comment By: Robert D. Penny (wobblie)
Date: 2002-04-23 20:06

Message:
Logged In: YES 
user_id=393585

I just got caught by the same "gotcha" using 2.2.1 on linux.
Thanks for pointing out the problem.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 13:09

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try the released 2.2.1, although I 
can't imagine why it would make any difference.  Nothing 
changed here, and

C:\Python22>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> file is open
1
>>>

That is, "file" and "open" aren't merely aliases, they're 
exactly the same object.

Are you using IDLE or PythonWin or ...?  "<pyshell#42>" 
doesn't appear in a DOS-box traceback.

Ah, I know!  You did something stupid <wink> you're not 
showing us, like

from os import *

Here:

>>> open
<type 'file'>
>>> from os import *
>>> open
<built-in function open>
>>>

If you replace the builtin open with os.open, then "an 
integer is required" is the expected error.  The builtin 
open and os.open are different functions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 06:32:57 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 22:32:57 -0700
Subject: [Python-bugs-list] [ python-Bugs-547138 ]  - open - alias generates error
Message-ID: <E170FOj-000341-00@usw-sf-web3.sourceforge.net>

Bugs item #547138, was opened at 2002-04-22 15:59
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: rodney holland (rhhrhh)
Assigned to: Tim Peters (tim_one)
Summary:  - open - alias generates error

Initial Comment:
Using python 2.2.1c on windows 98 the alias -  open  -
  gives the following error.  The function  - file -   
works fine.


>>> f=open("rfile.dat",'w')
Traceback (most recent call last):
  File "<pyshell#42>", line 1, in ?
    f=open("rfile.dat",'w')
TypeError: an integer is required
>>> 

----------------------------------------------------------------------

Comment By: rodney holland (rhhrhh)
Date: 2002-04-24 05:32

Message:
Logged In: YES 
user_id=522964

your analysis is correct - it is just too tempting to 
use    import *    in order to save a few keystrokes.  
Thanks for the prompt response.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-24 01:18

Message:
Logged In: YES 
user_id=31435

Closing as not-a-bug since this is a not-quite-common 
mistake and there's no reason to believe it's anything 
other than that.  Don't use "import *" and your life will 
be happier <wink>.

----------------------------------------------------------------------

Comment By: Robert D. Penny (wobblie)
Date: 2002-04-24 00:06

Message:
Logged In: YES 
user_id=393585

I just got caught by the same "gotcha" using 2.2.1 on linux.
Thanks for pointing out the problem.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-22 17:09

Message:
Logged In: YES 
user_id=31435

Works for me.  Please try the released 2.2.1, although I 
can't imagine why it would make any difference.  Nothing 
changed here, and

C:\Python22>python
Python 2.2.1 (#34, Apr  9 2002, 19:34:33) [MSC 32 bit 
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> file is open
1
>>>

That is, "file" and "open" aren't merely aliases, they're 
exactly the same object.

Are you using IDLE or PythonWin or ...?  "<pyshell#42>" 
doesn't appear in a DOS-box traceback.

Ah, I know!  You did something stupid <wink> you're not 
showing us, like

from os import *

Here:

>>> open
<type 'file'>
>>> from os import *
>>> open
<built-in function open>
>>>

If you replace the builtin open with os.open, then "an 
integer is required" is the expected error.  The builtin 
open and os.open are different functions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547138&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 07:41:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 23 Apr 2002 23:41:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-547939 ] Error in documentation
Message-ID: <E170GSm-0003mN-00@usw-sf-web3.sourceforge.net>

Bugs item #547939, was opened at 2002-04-24 06:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547939&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error in documentation

Initial Comment:

So, this is more of a gripe than a bug...

Documentation in os module for getgid() and getpgrp() 
is worse than the UNIX man pages! OK, I know the 
difference, but I was a bit fuzzy. The os module 
documentation didn't help! Notice that the only
difference is in a possesive apostrophe.  Ack!
This seems a bit perverse.

getgid() 
 Return the current process' group id. 

getpgrp() 
 Return the current process group id. 

http://www.python.org/doc/current/lib/os-procinfo.html


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547939&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 08:51:24 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 24 Apr 2002 00:51:24 -0700
Subject: [Python-bugs-list] [ python-Bugs-547953 ] inconsistency in "Using the cgi module"
Message-ID: <E170HYi-0005Qr-00@usw-sf-web2.sourceforge.net>

Bugs item #547953, was opened at 2002-04-24 15:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547953&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: inconsistency in "Using the cgi module"

Initial Comment:
In the library reference, there is an inconsistency in
the "Using the cgi module" page.  It says to test
whether a list of values has been returned by using the
type() function.  The example immediately below then
uses isinstance() to check for a list.

It should probably be updated to tell people just to
use isinstance().  It might also be better to just use
"list" rather than "ListType" in the isinstance() call:
  if isinstance(value, list):
      ...


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547953&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 15:04:52 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 24 Apr 2002 07:04:52 -0700
Subject: [Python-bugs-list] [ python-Bugs-548109 ] Build fails in _curses module
Message-ID: <E170NO8-0003sO-00@usw-sf-web1.sourceforge.net>

Bugs item #548109, was opened at 2002-04-24 14:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548109&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Hildebrandt (hildeb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails in _curses module

Initial Comment:
WHile building Python-2.2.1 on HP-UX 10.20 I get:

...
building '_curses' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I/mnt/disk4/gnu/Python-2.2.1/./Include -I/usr/local/include
-IInclude/ -c /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c -o
build/temp.hp-ux-B.10.20-9000/715-2.2/_cursesmodule.o -DNDEBUG -g -O3
-Wall -Wstrict-prototypes
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_EchoChar':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: (Each undeclared identifier is reported 
only once
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: for each function it appears in.)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_NoOutRefresh':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1118: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1118: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_Refresh':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1260: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1260: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_SubWin':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1326: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1326: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCurses_tigetflag':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:2264: warning: implicit declaration of 
function tigetflag'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCurses_tigetnum':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:2277: warning: implicit declaration of 
function tigetnum'



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548109&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 15:18:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 24 Apr 2002 07:18:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-548109 ] Build fails in _curses module
Message-ID: <E170Nar-0000fG-00@usw-sf-web3.sourceforge.net>

Bugs item #548109, was opened at 2002-04-24 14:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548109&group_id=5470

Category: Build
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Ralf Hildebrandt (hildeb)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails in _curses module

Initial Comment:
WHile building Python-2.2.1 on HP-UX 10.20 I get:

...
building '_curses' extension
gcc -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I.
-I/mnt/disk4/gnu/Python-2.2.1/./Include -I/usr/local/include
-IInclude/ -c /mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c -o
build/temp.hp-ux-B.10.20-9000/715-2.2/_cursesmodule.o -DNDEBUG -g -O3
-Wall -Wstrict-prototypes
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_EchoChar':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: (Each undeclared identifier is reported 
only once
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:710: for each function it appears in.)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_NoOutRefresh':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1118: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1118: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_Refresh':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1260: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1260: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCursesWindow_SubWin':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1326: structure has no member named _flags'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:1326: _ISPAD' undeclared (first use in this 
function)
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCurses_tigetflag':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:2264: warning: implicit declaration of 
function tigetflag'
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c: In function PyCurses_tigetnum':
/mnt/disk4/gnu/Python-2.2.1/Modules/_cursesmodule.c:2277: warning: implicit declaration of 
function tigetnum'



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-04-24 14:18

Message:
Logged In: YES 
user_id=6656

Do you have ncurses installed?  It looks somewhat like
configure is detecting ncurses but the module is being
compiled against some lesser curses.  Not sure, though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548109&group_id=5470



From noreply@sourceforge.net  Wed Apr 24 16:36:23 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 24 Apr 2002 08:36:23 -0700
Subject: [Python-bugs-list] [ python-Bugs-548176 ] urlparse doesn't handle host?bla
Message-ID: <E170Ooh-0002DN-00@usw-sf-web4.sourceforge.net>

Bugs item #548176, was opened at 2002-04-24 17:36
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548176&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Demleitner (msdemlei)
Assigned to: Nobody/Anonymous (nobody)
Summary: urlparse doesn't handle host?bla

Initial Comment:
The urlparse module (at least in 2.2 and 2.1, Linux)
doesn't
handle URLs of the form
http://www.maerkischeallgemeine.de?loc_id=49 correctly
-- everything up to the 9 ends up in the host.  I
didn't check the RFC, but in the real world URLs like
this do show up.  urlparse works fine when there's a
trailing slash on the host name:
http://www.maerkischeallgemeine.de/?loc_id=49

Example:
<pre>
>>> import urlparse
>>>
urlparse.urlparse("http://www.maerkischeallgemeine.de/?loc_id=49")
('http', 'www.maerkischeallgemeine.de', '/', '',
'loc_id=49', '')
>>>
urlparse.urlparse("http://www.maerkischeallgemeine.de?loc_id=49")
('http', 'www.maerkischeallgemeine.de?loc_id=49', '',
'', '', '')
</pre>

This has serious implications for urllib, since
urllib.urlopen will fail for URLs like the second one,
and with a pretty mysterious exception ("host not
found") at that.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548176&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 01:47:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Wed, 24 Apr 2002 17:47:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-545410 ] corefile: python 2.1.3, zope 2.5.0
Message-ID: <E170XPZ-0008Rl-00@usw-sf-web2.sourceforge.net>

Bugs item #545410, was opened at 2002-04-17 23:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Geoff Gerrietts (ggerrietts)
Assigned to: Nobody/Anonymous (nobody)
Summary: corefile: python 2.1.3, zope 2.5.0

Initial Comment:
I regularly get a corefile out of Zope 2.5.0, running
on RedHat 6.2 and Python 2.1.3, usually within 5 or 6
page views.

Reproducing the problem requires (for me) starting up
Zope, going to the management interface, and bouncing
around on a few of the different objects. Sometimes the
first attempt to render the page will cause a crash,
but sometimes it takes a few clicks. After the crash,
Zope dumps core and politely restarts itself.

Traceback files are largely the same from one crash to
the next, with the only variation I've noted being the
addresses of variables -- this fits with the fact that
it takes a different number of steps each time.

Traceback files (infuriatingly enough) do not show line
number information for select.so, even though
selectmodule.o was compiled with -g specified.

Examination of the traceback shows that in stack frame
2, print ((PyCFunctionObject *)func) -> m_ml -> ml_name
reveals "select". In that same frame, print ((PyObject
*)arg) -> ob_type -> tp_name yields "Cannot  access
memory at address 0x1f".

One traceback has been provided. Others, and other
info, available on request.

----------------------------------------------------------------------

>Comment By: Geoff Gerrietts (ggerrietts)
Date: 2002-04-25 00:47

Message:
Logged In: YES 
user_id=66989

MALLOC_CHECK_ didn't do anything different for me. I don't
know what that means exactly, because it definitely SEEMS
like there's some bad memory management going on. Maybe it's
just not bad ENOUGH.

The arg in stackframe 2 is actually NOT in the shared
library space -- the highest shared library address is
actually in the 0x404xxxx range. I'm not sure how the
programs are linked/run, so I'm not sure what 0x405d7ffc
would likely be if it's not shared libraries, though.

I've been looking into (and continue to look into) the
possibility Guido suggested on python-dev, that this is an
overrun of a thread's stack. It seems unlikely, given that
stack threads are allotted 2MB under Linux, but I suppose
anything's possible. The Data.fs in use in this core is
180MB; when compressed, it shrinks to about 90MB. It's a big
site, so overruns are a lot more possible here than in other
places.

I'm going to take a pass at pulling out all the 3rd-party
extension modules, but that's going to be very challenging.
A significant part of the architecture (roughly half,
including authentication) is accessible only through a 3rd
party extension, ILU. My independent testing with ILU
indicates that ILU works acceptably and doesn't cause memory
corruption. Because it's so ingrained into the site, I'm
going to look at doing more thorough testing and more of it,
and I'll try to isolate it so I can test around it, but I
don't think it's reasonable to try to replace it at this
point in time; the engineering effort would be several
weeks.

There are (at least one) other 3rd party module(s) that I'll
be able to rip out or fake up more easily.

I think this is more of a progress report than anything
else. Thanks for the eyes.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2002-04-19 14:50

Message:
Logged In: YES 
user_id=31392

Are you using any third party Python extension modules with
Zope?  It may be a memory corruption problem in an
extension.  If you are, you should try to reproduce the
problem with *only* Zope's core extensions and Python 2.1.3.


----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-18 05:44

Message:
Logged In: YES 
user_id=21627

In that backtrace, it is clear that arg in stackframe 2 is
bogus: 0x405d7ffc points into an area that appears to be
used for shared libraries (please do "info shared" to
support this theory).

Now, arg presumably is the return value of load_args, where
it was created through PyTuple_New. This suggests that the
memory management got corrupted; something that likely
happened much earlier.

I recommend to set MALLOC_CHECK_ before starting Python. The
documentation in malloc(3) says that setting it to 2 will
cause an abort() when an error is found; from expecting the
implementation, it appears that setting it to 3 will combine
the debug traces printed and the call to abort; please
experiment with all three values (1,2,3).

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=545410&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 13:45:14 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 05:45:14 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-547481 ] In-place reverse() and sort() for slices
Message-ID: <E170icc-0001m0-00@usw-sf-web1.sourceforge.net>

Feature Requests item #547481, was opened at 2002-04-23 11:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernhard Bender (bbender)
Assigned to: Nobody/Anonymous (nobody)
Summary: In-place reverse() and sort() for slices

Initial Comment:
In order to apply sort() or reverse() to only part of a
sequence (a slice), the following code seems to be
necessary:

	# a is a sequence
	tmp = s[m:n]
	tmp.sort()		# or tmp.reverse()
	s[m:n] = tmp

It would be much nicer to apply sort() or reverse() to
the slice directly:

	a[m:n].sort()

However, this does not work, since the slice returns a
new sequence object, on which sort() or reverse() will
work, instead of working on the slice in-place.
After sort() is done, the modified object will be
discarded, since it cannot be assigned to anything as
sort() and reverse() do not have a return value.

Therefore, the line above is accepted by the
interpreter even though it is completely useless.

My proposal is to change the semantics of applying
sort() and reverse() to slices such as to work in-place
on the slice, in stead of working on the new object
created by the slicing operation.

This would be similar to slice assignment, which also
does not create a new object.

Would this change require a PEP?

Bernhard Bender

----------------------------------------------------------------------

>Comment By: Bernhard Bender (bbender)
Date: 2002-04-25 14:45

Message:
Logged In: YES 
user_id=523837

I do not see this as a major change to the language:

1- slicing a[n:m] already has two different semantics
(creating a new object or referring to a slice of the
original sequence) depending on wether it is on the right or
left side of an assigment operator

2- statements like a[n:m].reverse() currently have no net
effect on any program, so they should not be used in any
well tested software.

3- I am not proposing to change the semantics of any current
use of slicing, especially a slice will still return a new
object.

The only change is for the application of in-place
operations like sort() and reverse() that currently make no
sense with slices.
Therefore, such change to the semantics of slicing should be
possible without doing harm to any existing program,
especially if an "import from __future__" is use to activate
the new semantics.

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2002-04-24 00:17

Message:
Logged In: YES 
user_id=35752

This would take some deep magic to make work and would
be a fundamental change to the language.  lst[m:m] is an
expression that returns a new object.  The chances of this
change being accepted is about zero.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=547481&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 16:15:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 08:15:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-548651 ] Fix the METH_CLASS implementation
Message-ID: <E170kxb-0000M9-00@usw-sf-web3.sourceforge.net>

Bugs item #548651, was opened at 2002-04-25 17:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 6
Submitted By: Thomas Heller (theller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Fix the METH_CLASS implementation

Initial Comment:
The devel-docs about METH_CLASS:

The method will be passed the type object as the first 
parameter rather than an instance of the type. This is 
used to create class methods, similar to what is 
created when using the classmethod() built-in 
function. New in version 2.3.

The code does not do it in this way. The first 
parameter the function receives is NULL, the type 
object goes together with the remaining arguments
in the second parameter (which is a tuple).

See the thread with subject 'METH_CLASS' on python-dev 
at 2002-04-25, Guido agreed that this should be fixed.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548651&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 16:30:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 08:30:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-548661 ] os.popen w/o using the shell
Message-ID: <E170lC7-0000vC-00@usw-sf-web4.sourceforge.net>

Bugs item #548661, was opened at 2002-04-25 10:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Bicking (ianbicking)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen w/o using the shell

Initial Comment:
I heard that there was an undocumented feature to the
os.popen family, where instead of passing a command
string as the first argument you could pass a list, as
[path, arg1, arg2, ...], and circumvent any shell
interpretation.  I was disapointed to see that this was
not so ("popen() argument 1 must be string, not list"
ditto tuple)

I believe this would be an excellent feature -- using
the shell is a significant source of errors due to
quoting, as well as a serious security concern.  95% of
the time the shell is not required.  The shell also
introduces portability concerns (e.g., bug #512433) --
creating a Python shell is not necessary when the shell
is usually superfluous anyway.



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 17:57:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 09:57:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-548693 ] Missing or wrong index entries
Message-ID: <E170mYt-0001sw-00@usw-sf-web2.sourceforge.net>

Bugs item #548693, was opened at 2002-04-25 18:57
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548693&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Missing or wrong index entries

Initial Comment:
As repoted by Cliff Wells in private email to me:

The dictionary's 'setdefault' method is not if the
library index.

'has_key' is listed in the library index as Queue
method, but the entry refers to "Hash, Btree, and
Record Objects" of bsddb.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548693&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 19:13:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 11:13:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-548661 ] os.popen w/o using the shell
Message-ID: <E170njo-0005Dj-00@usw-sf-web1.sourceforge.net>

Bugs item #548661, was opened at 2002-04-25 17:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Bicking (ianbicking)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen w/o using the shell

Initial Comment:
I heard that there was an undocumented feature to the
os.popen family, where instead of passing a command
string as the first argument you could pass a list, as
[path, arg1, arg2, ...], and circumvent any shell
interpretation.  I was disapointed to see that this was
not so ("popen() argument 1 must be string, not list"
ditto tuple)

I believe this would be an excellent feature -- using
the shell is a significant source of errors due to
quoting, as well as a serious security concern.  95% of
the time the shell is not required.  The shell also
introduces portability concerns (e.g., bug #512433) --
creating a Python shell is not necessary when the shell
is usually superfluous anyway.



----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-25 20:13

Message:
Logged In: YES 
user_id=21627

This feature is indeed available in popen2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 19:18:41 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 11:18:41 -0700
Subject: [Python-bugs-list] [ python-Bugs-548661 ] os.popen w/o using the shell
Message-ID: <E170npJ-0002pm-00@usw-sf-web2.sourceforge.net>

Bugs item #548661, was opened at 2002-04-25 10:30
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Ian Bicking (ianbicking)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.popen w/o using the shell

Initial Comment:
I heard that there was an undocumented feature to the
os.popen family, where instead of passing a command
string as the first argument you could pass a list, as
[path, arg1, arg2, ...], and circumvent any shell
interpretation.  I was disapointed to see that this was
not so ("popen() argument 1 must be string, not list"
ditto tuple)

I believe this would be an excellent feature -- using
the shell is a significant source of errors due to
quoting, as well as a serious security concern.  95% of
the time the shell is not required.  The shell also
introduces portability concerns (e.g., bug #512433) --
creating a Python shell is not necessary when the shell
is usually superfluous anyway.



----------------------------------------------------------------------

>Comment By: Ian Bicking (ianbicking)
Date: 2002-04-25 13:18

Message:
Logged In: YES 
user_id=210337

I see you are correct.  It would be nice if this feature was
consistent across all popen*, and was also documented (and
so  also committed to with clear semantics)

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-25 13:13

Message:
Logged In: YES 
user_id=21627

This feature is indeed available in popen2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548661&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 22:08:39 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 14:08:39 -0700
Subject: [Python-bugs-list] [ python-Bugs-415492 ] Compiler generates relative filenames
Message-ID: <E170qTn-0004i8-00@usw-sf-web4.sourceforge.net>

Bugs item #415492, was opened at 2001-04-11 10:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415492&group_id=5470

Category: Parser/Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul Prescod (prescod)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiler generates relative filenames

Initial Comment:
Make a file called "test.py"
----
import pack

print pack.func.func_code.co_filename
-----

Make a directory called "pack". Put a file in it 
called "__init__.py" with the contents:

def func(): pass

Now run test.py. It will compile a relative path into 
these modules. Now you can change to any directory on 
the system and run test.py and it will return the 
original relative path. The problem is that the 
relative path is compiled into the .pyc. It should be 
an absolute path.

----------------------------------------------------------------------

Comment By: Greg Chapman (glchapman)
Date: 2002-04-25 13:08

Message:
Logged In: YES 
user_id=86307

I just ran into this today when trying to find out why 
pydoc wasn't working for a module of mine: 
inspect.getmodule calls os.abspath with the filename found 
in the code object of global functions.  If the cwd is 
different than when the code object was compiled, 
inspect.getmodule fails.

Anyway, it looks to me like most of these relative paths 
could be caught in the find_module function (of import.c) 
if, when given an empty string for a path (while iterating 
over sys.path), find_module called getcwd() and used that 
instead of the empty string.  Of course, this assumes that 
(on all platforms) opening a bare filename means open the 
file with that name in the current directory (is that a 
valid assumption?).  Also, it appears from posixmodule.c 
that getcwd may not always be available.

Does this sound like a reasonable idea?


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-09-05 10:10

Message:
Logged In: YES 
user_id=6380

Why on earth was this assigned to Paul? He's not going to
make progress. Assigning back to nobody.

----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 13:15

Message:
Logged In: YES 
user_id=31392

Just to clarify.  The compiler in question is the builtin
compiler.  It generates absolute path names unless the .py
file is in the current working directory.


----------------------------------------------------------------------

Comment By: Jeremy Hylton (jhylton)
Date: 2001-04-13 06:12

Message:
Logged In: YES 
user_id=31392

I'm not clear on what the rules for co_filename are, but it
looks like the absolute path is only used for package
imports.  If you cd into the package directory, run python
-c "import __init__", and then later import the package the
path name is relative.

The compiler package isn't connected to the import
mechanism, so there's no way for it to know whether it is
compiling a module or a package.  I don't think there's a
way to do anything better.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415492&group_id=5470



From noreply@sourceforge.net  Thu Apr 25 23:58:03 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 15:58:03 -0700
Subject: [Python-bugs-list] [ python-Bugs-548845 ] pydoc doesn't show C types
Message-ID: <E170sBf-0005Tw-00@usw-sf-web3.sourceforge.net>

Bugs item #548845, was opened at 2002-04-25 14:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc doesn't show C types

Initial Comment:
If you define a type in C and add it to a module's 
dictionary, it will not be displayed by pydoc.  Now 
that calling such types can serve as the constructor 
for the type's instances, I think pydoc should ensure 
that the types are displayed.

Pydoc sees such types as classes because 
inspect.isclass returns true for them:

def isclass(object):
    return isinstance(object, types.ClassType) or  
        hasattr(object, '__bases__')

(The above succeeds for because C types have a 
__bases__ attribute).  However, when pydoc checks to 
see if the type/class is defined in the module being 
documented, it uses the type's __module__ attribute to 
look up the module in sys.modules.  By default, C 
types always return "__builtin__" as their __module__, 
so pydoc concludes the type was actually declared in 
the __builtin__ module and does not show it.

(Perhaps this is really a documentation bug -- there 
does not seem to be anything indicating that types 
which wish to expose themselves to pydoc should 
redefine the __module__ attribute.)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 01:42:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Thu, 25 Apr 2002 17:42:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-548874 ] Lists do have __getitem__ method
Message-ID: <E170toG-0006aI-00@usw-sf-web3.sourceforge.net>

Bugs item #548874, was opened at 2002-04-25 17:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548874&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Kelly Gerber (kgerber)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lists do have __getitem__ method

Initial Comment:
In the Python Reference Manual, Release 2.2.1, section
3.3 Special method names, first paragraph, it says"(The
reverse is not true--if x is a list object,
x.__getitem__(i) is not equivalent to x[i].)"

I do not think this is true any more since Python2.2,
because types now have special methods. They both seem
to produce the same result. Doesn't that make them
equivalent?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548874&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 13:11:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 05:11:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky
Message-ID: <E1714ZD-0005S8-00@usw-sf-web3.sourceforge.net>

Bugs item #549038, was opened at 2002-04-26 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgitb variable dumps a little flaky

Initial Comment:
First off, easy problem: lookup() should look in 
frame.f_globals["__builtins__"] also. Along the same 
lines, I am not sure if lookup works properly with 
nested scopes, but since I don't use nested scopes in 
any of my code this is not a problem for me ;-)

Secondly, the parsing in scanvars() is somewhat hacky. 
For example, given the following line:

  foo(open(filename).read())

it will think the following variables exist:

  foo
  open
  filename
  ).read

Obviously this last one is incorrect. I am not sure if 
this is easy to fix or not.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 14:54:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 06:54:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-549081 ] test_signal hangs durring 'make test'
Message-ID: <E1716BU-0006iq-00@usw-sf-web3.sourceforge.net>

Bugs item #549081, was opened at 2002-04-26 13:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470

Category: Installation
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_signal hangs durring 'make test'

Initial Comment:

This appears to be similar to bug as PR#288,
    [ 210635 ] test_signal hangs when running 
    as part of testall (PR#288)

except that I have this problem on a fresh install of
OpenBSD 3.0 while trying to build Python-2.2.1.
I did a generic build running as root:
    ./configure
    ./make
    ./make test

Yours,
Noah



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 15:38:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 07:38:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-534748 ] Removing _tkinter considered harmful
Message-ID: <E1716s4-0007Zv-00@usw-sf-web4.sourceforge.net>

Bugs item #534748, was opened at 2002-03-25 08:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul F. Dubois (dubois)
Assigned to: Nobody/Anonymous (nobody)
Summary: Removing _tkinter considered harmful

Initial Comment:
The Python build process now tries to import _tkinter
and if it cannot removes it. There are two problems
with this:

a. It isn't correct.
b. It removes the very thing required to understand why
it  won't import.

(a) It isn't correct because it might import correctly
later. If the user has, for example, installed tk / tcl
in a place that is not in LD_LIBRARY_PATH, the import
might fail during the Python build but succeed after
the user sets this variable. Since the installer having
it set is no guarantee the user will have it set, we
aren't buying anything by verifying that the installer
can import it.

(b) If it won't import you just destroyed the evidence.

----------------------------------------------------------------------

>Comment By: Paul F. Dubois (dubois)
Date: 2002-04-26 07:38

Message:
Logged In: YES 
user_id=5550

I now know that this is in Python's setup.py file. I suggest
the offending file might be renamed rather than removed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 15:52:35 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 07:52:35 -0700
Subject: [Python-bugs-list] [ python-Bugs-534748 ] Removing _tkinter considered harmful
Message-ID: <E17175P-0007k1-00@usw-sf-web4.sourceforge.net>

Bugs item #534748, was opened at 2002-03-25 16:48
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Paul F. Dubois (dubois)
Assigned to: Nobody/Anonymous (nobody)
Summary: Removing _tkinter considered harmful

Initial Comment:
The Python build process now tries to import _tkinter
and if it cannot removes it. There are two problems
with this:

a. It isn't correct.
b. It removes the very thing required to understand why
it  won't import.

(a) It isn't correct because it might import correctly
later. If the user has, for example, installed tk / tcl
in a place that is not in LD_LIBRARY_PATH, the import
might fail during the Python build but succeed after
the user sets this variable. Since the installer having
it set is no guarantee the user will have it set, we
aren't buying anything by verifying that the installer
can import it.

(b) If it won't import you just destroyed the evidence.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2002-04-26 14:52

Message:
Logged In: YES 
user_id=6656

The time machine strikes again; that's what happens in CVS
Python (on the trunk; this didn't get ported to 221).

----------------------------------------------------------------------

Comment By: Paul F. Dubois (dubois)
Date: 2002-04-26 14:38

Message:
Logged In: YES 
user_id=5550

I now know that this is in Python's setup.py file. I suggest
the offending file might be renamed rather than removed.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=534748&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 17:04:10 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 09:04:10 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E1718Cg-0008DY-00@usw-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 18:19:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 10:19:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-548845 ] pydoc doesn't show C types
Message-ID: <E1719NS-00012I-00@usw-sf-web2.sourceforge.net>

Bugs item #548845, was opened at 2002-04-26 00:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470

Category: Python Library
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: pydoc doesn't show C types

Initial Comment:
If you define a type in C and add it to a module's 
dictionary, it will not be displayed by pydoc.  Now 
that calling such types can serve as the constructor 
for the type's instances, I think pydoc should ensure 
that the types are displayed.

Pydoc sees such types as classes because 
inspect.isclass returns true for them:

def isclass(object):
    return isinstance(object, types.ClassType) or  
        hasattr(object, '__bases__')

(The above succeeds for because C types have a 
__bases__ attribute).  However, when pydoc checks to 
see if the type/class is defined in the module being 
documented, it uses the type's __module__ attribute to 
look up the module in sys.modules.  By default, C 
types always return "__builtin__" as their __module__, 
so pydoc concludes the type was actually declared in 
the __builtin__ module and does not show it.

(Perhaps this is really a documentation bug -- there 
does not seem to be anything indicating that types 
which wish to expose themselves to pydoc should 
redefine the __module__ attribute.)


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2002-04-26 19:19

Message:
Logged In: YES 
user_id=11105

As the most recent documentation (which is just a few days 
old) shows, it's a bug in the extensions module IMO ;-).
You have to use "<module>.<name>" as the tp_name slot in 
the extension type, and __module__ will automatically be 
set. pydoc then also documents this type.

http://starship.python.net/crew/theller/pyhelp.cgi?
keyword=tp_name&version=devel

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=548845&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 18:24:20 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 10:24:20 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-549187 ] error about string formatting rewording?
Message-ID: <E1719SG-00013B-00@usw-sf-web4.sourceforge.net>

Feature Requests item #549187, was opened at 2002-04-26 17:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=549187&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: error about string formatting rewording?

Initial Comment:
The error message that occurs during string formatting,
when one passes more arguments than necessary, is this:

    TypeError: not all arguments converted

It might be good to mention that this conversion is
taking place as a result of string formatting.  My
suggestions is to add a little more to this message:

    TypeError: not all arguments converted during
string formatting


The reason is because string formatting uses the same
operation as the modulus command, and also can take in
a single integer argument, like:

   ziffer = note % 10

Newcomers to the language often mix up string and
numbers, and the error message above can be very
cryptic if one doesn't know about string formatting
yet.  With the reworded error message, there's less of
chance of confusion.

See:

http://mail.python.org/pipermail/tutor/2002-April/014110.html

for more details on why this might be nice.  Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=549187&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 21:45:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 13:45:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-547953 ] inconsistency in "Using the cgi module"
Message-ID: <E171CbP-0005oa-00@usw-sf-web1.sourceforge.net>

Bugs item #547953, was opened at 2002-04-24 03:51
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547953&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James Henstridge (jhenstridge)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: inconsistency in "Using the cgi module"

Initial Comment:
In the library reference, there is an inconsistency in
the "Using the cgi module" page.  It says to test
whether a list of values has been returned by using the
type() function.  The example immediately below then
uses isinstance() to check for a list.

It should probably be updated to tell people just to
use isinstance().  It might also be better to just use
"list" rather than "ListType" in the isinstance() call:
  if isinstance(value, list):
      ...


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-26 16:45

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/libcgi.tex revisions 1.36, 1.35.4.1, and
1.28.6.1.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547953&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 22:00:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 14:00:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-547939 ] Error in documentation
Message-ID: <E171Cpl-00038Z-00@usw-sf-web3.sourceforge.net>

Bugs item #547939, was opened at 2002-04-24 02:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547939&group_id=5470

Category: Documentation
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Error in documentation

Initial Comment:

So, this is more of a gripe than a bug...

Documentation in os module for getgid() and getpgrp() 
is worse than the UNIX man pages! OK, I know the 
difference, but I was a bit fuzzy. The os module 
documentation didn't help! Notice that the only
difference is in a possesive apostrophe.  Ack!
This seems a bit perverse.

getgid() 
 Return the current process' group id. 

getpgrp() 
 Return the current process group id. 

http://www.python.org/doc/current/lib/os-procinfo.html


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-04-26 17:00

Message:
Logged In: YES 
user_id=3066

Clarified in Doc/lib/libos.tex revisions 1.83 and 1.74.2.1.2.2.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547939&group_id=5470



From noreply@sourceforge.net  Fri Apr 26 22:08:17 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 14:08:17 -0700
Subject: [Python-bugs-list] [ python-Bugs-547537 ] cStringIO mangles Unicode
Message-ID: <E171Cwz-0003bY-00@usw-sf-web2.sourceforge.net>

Bugs item #547537, was opened at 2002-04-23 08:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cStringIO mangles Unicode

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 17:08

Message:
Logged In: YES 
user_id=6380

Should I just check this in? It looks pretty safe to me...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 08:59

Message:
Logged In: YES 
user_id=6380

I wonder if perhaps the fix is as simple as using "t#"
instead of "s#" in the PyArg_... format string in P_write().
That accepts Unicode strings as args to write() only when
they are ASCII (actually, it uses the default encoding).

Marc-Andre, can you explain the reason for the change in the
first place (other than fixing a dubious dependency on
PyString_GetSize() raising an exception for a non-string
object)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470



From noreply@sourceforge.net  Sat Apr 27 02:38:02 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Fri, 26 Apr 2002 18:38:02 -0700
Subject: [Python-bugs-list] [ python-Bugs-549338 ] lib-dynload/*.so permissions wrong
Message-ID: <E171HA2-0005k9-00@usw-sf-web3.sourceforge.net>

Bugs item #549338, was opened at 2002-04-26 20:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549338&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Lewis Muir (jlmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: lib-dynload/*.so permissions wrong

Initial Comment:
After

    ./configure --prefix=<PYTHON_INSTALL_DIR>
    make
    make test
    make install

the .so files installed 
in '<PYTHON_INSTALL_DIR>/lib/python2.2/lib-dynload' 
have permissions set to 700. They should instead have 
file permissions set to 755.

Running the python interpreter as a non-root user with 
the lib-dynload/*.so file permissions set to 700 (as 
is done by the install), a simple import of the time 
module fails:

    >>> import time
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: No module named time
    >>>

After changing file permissions to 755, 'import time' 
works fine.

---
Python 2.2.1
Mandrake 8.0
Linux 2.4.8
x86 hardware

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549338&group_id=5470



From noreply@sourceforge.net  Sat Apr 27 16:02:58 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 08:02:58 -0700
Subject: [Python-bugs-list] [ python-Bugs-547537 ] cStringIO mangles Unicode
Message-ID: <E171Tj0-0005P1-00@usw-sf-web4.sourceforge.net>

Bugs item #547537, was opened at 2002-04-23 12:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cStringIO mangles Unicode

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:02

Message:
Logged In: YES 
user_id=38388

The idea to rip out the old string only approach was to make
cStringIO more compatible to the file object implementation.

Rather than switching from s# to t#, the cStringIO object
should maintain a binary switch just like the file
object does and then use s# for pseudo files opened
in binary mode (default) and t# for text mode ones.

Note that in any case, Unicode should be explicitly
encoded before writing it to a file. 

Simply switching to t# would cause compatibility 
problems, since a different buffer API would be used
for all input objects.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 21:08

Message:
Logged In: YES 
user_id=6380

Should I just check this in? It looks pretty safe to me...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 12:59

Message:
Logged In: YES 
user_id=6380

I wonder if perhaps the fix is as simple as using "t#"
instead of "s#" in the PyArg_... format string in P_write().
That accepts Unicode strings as args to write() only when
they are ASCII (actually, it uses the default encoding).

Marc-Andre, can you explain the reason for the change in the
first place (other than fixing a dubious dependency on
PyString_GetSize() raising an exception for a non-string
object)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470



From noreply@sourceforge.net  Sat Apr 27 16:05:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 08:05:33 -0700
Subject: [Python-bugs-list] [ python-Bugs-513666 ] unicode() docs don't mention LookupError
Message-ID: <E171TlV-00057H-00@usw-sf-web3.sourceforge.net>

Bugs item #513666, was opened at 2002-02-06 08:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513666&group_id=5470

Category: Documentation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Ben Gertzfield (che_fox)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: unicode() docs don't mention LookupError

Initial Comment:
The unicode() docs say:

"If errors is 'strict' (the default), a ValueError is
raised on errors..."

This is not true; ValueError is only raised on
conversion errors.  There are other exceptions that can
be raised:

Python 2.1.2 (#1, Jan 18 2002, 18:05:45) 
[GCC 2.95.4  (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.

>>> unicode("abc", "nonexistent codec")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
LookupError: unknown encoding

Looking at src/Objects/unicodeobject.c, there are lots
of other exceptions that can be raised.  The
documentation should probably be clarified.


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:05

Message:
Logged In: YES 
user_id=38388

I don't have time for this. The basic errors that I can
currently remember are LookupError (codec not found) and
UnicodeError (invalid data, subclass of ValueError).

Codecs may raise other exceptions as well, so its not
possible to define an exhaustive list.

Assigning back to you, Fred.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2002-03-12 20:25

Message:
Logged In: YES 
user_id=3066

Marc-Andre -- could you summarize all the exceptions that
can be raised and what they mean?  A simple list here would
be fine; I can move the information into LaTeX if you'd prefer.

Thanks!

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-02-06 09:25

Message:
Logged In: YES 
user_id=38388

You are right in that there are many more exceptions which are possible (perhaps we ought to mention 
LookupError in the docs), ValueError will certainly be the most common, though.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=513666&group_id=5470



From noreply@sourceforge.net  Sat Apr 27 16:13:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 08:13:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-547537 ] cStringIO mangles Unicode
Message-ID: <E171TtB-0005Aq-00@usw-sf-web3.sourceforge.net>

Bugs item #547537, was opened at 2002-04-23 12:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cStringIO mangles Unicode

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:13

Message:
Logged In: YES 
user_id=38388

Another note: the bug title is wrong: cStringIO doesn't
mangle Unicode, it just returns the raw binary data. Not
that this is of much use, but it's in sync with what the
file object does.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 15:02

Message:
Logged In: YES 
user_id=38388

The idea to rip out the old string only approach was to make
cStringIO more compatible to the file object implementation.

Rather than switching from s# to t#, the cStringIO object
should maintain a binary switch just like the file
object does and then use s# for pseudo files opened
in binary mode (default) and t# for text mode ones.

Note that in any case, Unicode should be explicitly
encoded before writing it to a file. 

Simply switching to t# would cause compatibility 
problems, since a different buffer API would be used
for all input objects.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 21:08

Message:
Logged In: YES 
user_id=6380

Should I just check this in? It looks pretty safe to me...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 12:59

Message:
Logged In: YES 
user_id=6380

I wonder if perhaps the fix is as simple as using "t#"
instead of "s#" in the PyArg_... format string in P_write().
That accepts Unicode strings as args to write() only when
they are ASCII (actually, it uses the default encoding).

Marc-Andre, can you explain the reason for the change in the
first place (other than fixing a dubious dependency on
PyString_GetSize() raising an exception for a non-string
object)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470



From noreply@sourceforge.net  Sat Apr 27 16:40:46 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 08:40:46 -0700
Subject: [Python-bugs-list] [ python-Bugs-549081 ] test_signal hangs durring 'make test'
Message-ID: <E171UJa-0005MJ-00@usw-sf-web3.sourceforge.net>

Bugs item #549081, was opened at 2002-04-26 13:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470

Category: Installation
Group: Python 2.1.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_signal hangs durring 'make test'

Initial Comment:

This appears to be similar to bug as PR#288,
    [ 210635 ] test_signal hangs when running 
    as part of testall (PR#288)

except that I have this problem on a fresh install of
OpenBSD 3.0 while trying to build Python-2.2.1.
I did a generic build running as root:
    ./configure
    ./make
    ./make test

Yours,
Noah



----------------------------------------------------------------------

>Comment By: Noah Spurrier (noah)
Date: 2002-04-27 15:40

Message:
Logged In: YES 
user_id=59261

Below is the output of test_signal.py. I ran it manually. I 
modified it slightly to print out the pid; the return 
values from the signal calls; and to print a count of the 
loop iteration (starting at 1). You can see that after 
Count 4 it just sits there. After about a minute I hit Ctrl-
Z. I have uploaded the modified version of test_signal.py.
...
bash-2.05# python test_signal.py 
pid: 8606
signal.alarm(20): 0
signal.signal(5, handlerA): 0
signal.signal(2, handlerB): <built-in function 
default_int_handler>
signal.signal(3, signal.SIG_IGN): 0
signal.signal(signal.SIGALRM, signal.default_int_handler): 0
starting pause() loop...
+ sleep 2
count: 1
call pause()...
+ kill -5 8606
pause() returned
+ sleep 2
count: 2
call pause()...
+ kill -2 8606
pause() returned
+ sleep 2
count: 3
call pause()...
+ kill -3 8606
pause() returned
count: 4
call pause()...
^Z
[1]+  Stopped                 python test_signal.py
bash-2.05# ps -p 8606
  PID TT   STAT      TIME COMMAND
 8606 p0  T       0:00.09 python test_signal.py 
bash-2.05# uname -a
OpenBSD nobot 3.0 GENERIC#94 i386
bash-2.05# python
Python 2.2.1 (#4, Apr 26 2002, 23:06:40) 
[GCC 2.95.3 20010125 (prerelease)] on openbsd3





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470



From noreply@sourceforge.net  Sat Apr 27 16:44:04 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 08:44:04 -0700
Subject: [Python-bugs-list] [ python-Bugs-549081 ] test_signal hangs durring 'make test'
Message-ID: <E171UMm-0005O7-00@usw-sf-web3.sourceforge.net>

Bugs item #549081, was opened at 2002-04-26 13:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470

Category: Installation
>Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_signal hangs durring 'make test'

Initial Comment:

This appears to be similar to bug as PR#288,
    [ 210635 ] test_signal hangs when running 
    as part of testall (PR#288)

except that I have this problem on a fresh install of
OpenBSD 3.0 while trying to build Python-2.2.1.
I did a generic build running as root:
    ./configure
    ./make
    ./make test

Yours,
Noah



----------------------------------------------------------------------

Comment By: Noah Spurrier (noah)
Date: 2002-04-27 15:40

Message:
Logged In: YES 
user_id=59261

Below is the output of test_signal.py. I ran it manually. I 
modified it slightly to print out the pid; the return 
values from the signal calls; and to print a count of the 
loop iteration (starting at 1). You can see that after 
Count 4 it just sits there. After about a minute I hit Ctrl-
Z. I have uploaded the modified version of test_signal.py.
...
bash-2.05# python test_signal.py 
pid: 8606
signal.alarm(20): 0
signal.signal(5, handlerA): 0
signal.signal(2, handlerB): <built-in function 
default_int_handler>
signal.signal(3, signal.SIG_IGN): 0
signal.signal(signal.SIGALRM, signal.default_int_handler): 0
starting pause() loop...
+ sleep 2
count: 1
call pause()...
+ kill -5 8606
pause() returned
+ sleep 2
count: 2
call pause()...
+ kill -2 8606
pause() returned
+ sleep 2
count: 3
call pause()...
+ kill -3 8606
pause() returned
count: 4
call pause()...
^Z
[1]+  Stopped                 python test_signal.py
bash-2.05# ps -p 8606
  PID TT   STAT      TIME COMMAND
 8606 p0  T       0:00.09 python test_signal.py 
bash-2.05# uname -a
OpenBSD nobot 3.0 GENERIC#94 i386
bash-2.05# python
Python 2.2.1 (#4, Apr 26 2002, 23:06:40) 
[GCC 2.95.3 20010125 (prerelease)] on openbsd3





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470



From noreply@sourceforge.net  Sat Apr 27 16:46:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 08:46:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-549081 ] test_signal hangs -- signal broken on OpenBSD?
Message-ID: <E171UOj-0005Ou-00@usw-sf-web3.sourceforge.net>

Bugs item #549081, was opened at 2002-04-26 13:54
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470

Category: Installation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
>Summary: test_signal hangs -- signal broken on OpenBSD?

Initial Comment:

This appears to be similar to bug as PR#288,
    [ 210635 ] test_signal hangs when running 
    as part of testall (PR#288)

except that I have this problem on a fresh install of
OpenBSD 3.0 while trying to build Python-2.2.1.
I did a generic build running as root:
    ./configure
    ./make
    ./make test

Yours,
Noah



----------------------------------------------------------------------

Comment By: Noah Spurrier (noah)
Date: 2002-04-27 15:40

Message:
Logged In: YES 
user_id=59261

Below is the output of test_signal.py. I ran it manually. I 
modified it slightly to print out the pid; the return 
values from the signal calls; and to print a count of the 
loop iteration (starting at 1). You can see that after 
Count 4 it just sits there. After about a minute I hit Ctrl-
Z. I have uploaded the modified version of test_signal.py.
...
bash-2.05# python test_signal.py 
pid: 8606
signal.alarm(20): 0
signal.signal(5, handlerA): 0
signal.signal(2, handlerB): <built-in function 
default_int_handler>
signal.signal(3, signal.SIG_IGN): 0
signal.signal(signal.SIGALRM, signal.default_int_handler): 0
starting pause() loop...
+ sleep 2
count: 1
call pause()...
+ kill -5 8606
pause() returned
+ sleep 2
count: 2
call pause()...
+ kill -2 8606
pause() returned
+ sleep 2
count: 3
call pause()...
+ kill -3 8606
pause() returned
count: 4
call pause()...
^Z
[1]+  Stopped                 python test_signal.py
bash-2.05# ps -p 8606
  PID TT   STAT      TIME COMMAND
 8606 p0  T       0:00.09 python test_signal.py 
bash-2.05# uname -a
OpenBSD nobot 3.0 GENERIC#94 i386
bash-2.05# python
Python 2.2.1 (#4, Apr 26 2002, 23:06:40) 
[GCC 2.95.3 20010125 (prerelease)] on openbsd3





----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549081&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 01:02:25 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 17:02:25 -0700
Subject: [Python-bugs-list] [ python-Bugs-547537 ] cStringIO mangles Unicode
Message-ID: <E171c93-0002SN-00@usw-sf-web4.sourceforge.net>

Bugs item #547537, was opened at 2002-04-23 08:52
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: M.-A. Lemburg (lemburg)
Summary: cStringIO mangles Unicode

Initial Comment:
The last few comments added to bug 216388 indicate a
new problem in cStringIO. Rather than abusing that bug
report, I'm opening a new one here. The problem is that
cStringIO now accepts Unicode strings to write(), but
when you use this, getvalue() returns binary garbage.
The cause is apparently MAL's checkin for cStringIO
2.30, which enabled read buffers.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-27 20:02

Message:
Logged In: YES 
user_id=6380

I think that adding a binary mode to cStringIO is okay, but
the default should be text, and until we have the binary
mode option, the format should be t#.

Another solution would be to let cStringIO act more like
StringIO; after all that was its original intention. But
since that would require a major overhaul, I'm not seriously
proposing that.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 11:13

Message:
Logged In: YES 
user_id=38388

Another note: the bug title is wrong: cStringIO doesn't
mangle Unicode, it just returns the raw binary data. Not
that this is of much use, but it's in sync with what the
file object does.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-04-27 11:02

Message:
Logged In: YES 
user_id=38388

The idea to rip out the old string only approach was to make
cStringIO more compatible to the file object implementation.

Rather than switching from s# to t#, the cStringIO object
should maintain a binary switch just like the file
object does and then use s# for pseudo files opened
in binary mode (default) and t# for text mode ones.

Note that in any case, Unicode should be explicitly
encoded before writing it to a file. 

Simply switching to t# would cause compatibility 
problems, since a different buffer API would be used
for all input objects.



----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-26 17:08

Message:
Logged In: YES 
user_id=6380

Should I just check this in? It looks pretty safe to me...

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-23 08:59

Message:
Logged In: YES 
user_id=6380

I wonder if perhaps the fix is as simple as using "t#"
instead of "s#" in the PyArg_... format string in P_write().
That accepts Unicode strings as args to write() only when
they are ASCII (actually, it uses the default encoding).

Marc-Andre, can you explain the reason for the change in the
first place (other than fixing a dubious dependency on
PyString_GetSize() raising an exception for a non-string
object)?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547537&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 04:39:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sat, 27 Apr 2002 20:39:11 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-549187 ] error about string formatting rewording?
Message-ID: <E171fWp-0004YN-00@usw-sf-web4.sourceforge.net>

Feature Requests item #549187, was opened at 2002-04-26 17:24
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=549187&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Danny Yoo (dyoo)
Assigned to: Nobody/Anonymous (nobody)
Summary: error about string formatting rewording?

Initial Comment:
The error message that occurs during string formatting,
when one passes more arguments than necessary, is this:

    TypeError: not all arguments converted

It might be good to mention that this conversion is
taking place as a result of string formatting.  My
suggestions is to add a little more to this message:

    TypeError: not all arguments converted during
string formatting


The reason is because string formatting uses the same
operation as the modulus command, and also can take in
a single integer argument, like:

   ziffer = note % 10

Newcomers to the language often mix up string and
numbers, and the error message above can be very
cryptic if one doesn't know about string formatting
yet.  With the reworded error message, there's less of
chance of confusion.

See:

http://mail.python.org/pipermail/tutor/2002-April/014110.html

for more details on why this might be nice.  Thanks!

----------------------------------------------------------------------

>Comment By: Danny Yoo (dyoo)
Date: 2002-04-28 03:39

Message:
Logged In: YES 
user_id=49843

Ok, I wrote up a patch to add more to the error message. 
Here's what it does:

>>> def isEven(n): return n % 2 == 0
... 
>>> isEven(17)
False
>>> isEven("17")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 1, in isEven
TypeError: not all arguments converted during string formatting

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=549187&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 09:41:56 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 01:41:56 -0700
Subject: [Python-bugs-list] [ python-Bugs-549725 ] xml.dom.minidom doesn't pass CDATA
Message-ID: <E171kFo-0007Fo-00@usw-sf-web3.sourceforge.net>

Bugs item #549725, was opened at 2002-04-28 08:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom doesn't pass CDATA

Initial Comment:
>>> import sys
>>> from sxml.xml2py import parseFile
# this is a simple wrapper to xml.dom.minidom.parse()
>>> x=parseFile(sys.stdin)

<?xml version="1.0" ?>           
<foo><![CDATA[dies ist
ein bar
]]></foo>
^D

>>> x
[<DOM Element: foo at 1076384172>]
>>> x.childNodes[0].childNodes
[<DOM Text node "dies ist">, <DOM Text node "\n">, <DOM Text node "ein bar">, <DOM Text node "\n">]
>>> 

I was expecting a CDATASection node here.
(In fact, my code would like to depend on it.)


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 10:17:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 02:17:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] UTF8 decoder appears to leak references
Message-ID: <E171koh-0007xL-00@usw-sf-web2.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 19:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: UTF8 decoder appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 10:26:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 02:26:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E171kwT-0007tG-00@usw-sf-web4.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 19:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
>Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 19:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 11:05:29 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 03:05:29 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E171lYf-00087Q-00@usw-sf-web3.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 19:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 20:05

Message:
Logged In: YES 
user_id=14198

Found it :)  Attaching patch.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 19:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 11:39:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 03:39:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-549731 ] Unicode encoders appears to leak references
Message-ID: <E171m5I-0000Lh-00@usw-sf-web2.sourceforge.net>

Bugs item #549731, was opened at 2002-04-28 19:17
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Unicode encoders appears to leak references

Initial Comment:
Note the following Debug Python session:

>>> s=u"anything"
[8189 refs]
>>> v=s.encode("utf8")
[10967 refs]
>>> v=s.encode("utf8")
[10968 refs]
>>> v=s.encode("utf8")
[10969 refs]
>>> v=s.encode("utf8")
[10970 refs]

Each call to encode is losing a reference.  Attaching a
test program that demonstrates this in more detail. 
The output from my test program is:

After 10000 iterations, lost 12850 references
[15227 refs]

and for 100000:
After 100000 iterations, lost 102850 references
[105227 refs]

etc.

As far as I can tell, this appears in all Python 2.x
versions.

----------------------------------------------------------------------

>Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 20:39

Message:
Logged In: YES 
user_id=14198

Oops - too quick.  All calls to _PyCodec_Lookup() leak.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 20:05

Message:
Logged In: YES 
user_id=14198

Found it :)  Attaching patch.

----------------------------------------------------------------------

Comment By: Mark Hammond (mhammond)
Date: 2002-04-28 19:26

Message:
Logged In: YES 
user_id=14198

s/decode/encode/ :)  Also meant to mention problem not
restricted to UTF8 - changing the encoding in the text file
to anything other than 'ascii' seems to leak in the same way.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549731&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 12:19:26 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 04:19:26 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-549764 ] Uninstall target in makefile
Message-ID: <E171miE-000321-00@usw-sf-web1.sourceforge.net>

Feature Requests item #549764, was opened at 2002-04-28 06:19
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=549764&group_id=5470

Category: Installation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Chad Austin (aegis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Uninstall target in makefile

Initial Comment:
I'm often installing different versions of Python to
test threading bugs in SCons, and it's a pain to
manually go in and remove the files every time.  A simple:

make uninstall

would be very cool.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=549764&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 14:59:12 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 06:59:12 -0700
Subject: [Python-bugs-list] [ python-Bugs-549725 ] xml.dom.minidom doesn't pass CDATA
Message-ID: <E171pCq-00040V-00@usw-sf-web3.sourceforge.net>

Bugs item #549725, was opened at 2002-04-28 10:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom doesn't pass CDATA

Initial Comment:
>>> import sys
>>> from sxml.xml2py import parseFile
# this is a simple wrapper to xml.dom.minidom.parse()
>>> x=parseFile(sys.stdin)

<?xml version="1.0" ?>           
<foo><![CDATA[dies ist
ein bar
]]></foo>
^D

>>> x
[<DOM Element: foo at 1076384172>]
>>> x.childNodes[0].childNodes
[<DOM Text node "dies ist">, <DOM Text node "\n">, <DOM Text node "ein bar">, <DOM Text node "\n">]
>>> 

I was expecting a CDATASection node here.
(In fact, my code would like to depend on it.)


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 15:59

Message:
Logged In: YES 
user_id=21627

What is sxml? Why is this a bug in Python?

Notice that the use of CDATA in the DOM is completely
optional - the DOM tree represents your document correctly.
Code relying on CDATA is broken.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 15:00:59 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 07:00:59 -0700
Subject: [Python-bugs-list] [ python-Bugs-549338 ] lib-dynload/*.so permissions wrong
Message-ID: <E171pEZ-00041D-00@usw-sf-web3.sourceforge.net>

Bugs item #549338, was opened at 2002-04-27 03:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549338&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Lewis Muir (jlmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: lib-dynload/*.so permissions wrong

Initial Comment:
After

    ./configure --prefix=<PYTHON_INSTALL_DIR>
    make
    make test
    make install

the .so files installed 
in '<PYTHON_INSTALL_DIR>/lib/python2.2/lib-dynload' 
have permissions set to 700. They should instead have 
file permissions set to 755.

Running the python interpreter as a non-root user with 
the lib-dynload/*.so file permissions set to 700 (as 
is done by the install), a simple import of the time 
module fails:

    >>> import time
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: No module named time
    >>>

After changing file permissions to 755, 'import time' 
works fine.

---
Python 2.2.1
Mandrake 8.0
Linux 2.4.8
x86 hardware

----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 16:00

Message:
Logged In: YES 
user_id=21627

When you perform the installation, what is your umask?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549338&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 15:43:50 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 07:43:50 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-495086 ] dict.popitem(key=None)
Message-ID: <E171pu2-0004M4-00@usw-sf-web3.sourceforge.net>

Feature Requests item #495086, was opened at 2001-12-19 16:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Dan Parisien (mathematician)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict.popitem(key=None)

Initial Comment:
Would it be possible to add an extra argument to the 
popitem method of DictionaryType so one can both 
retrieve a dict item and delete it at the same time? 
It would be so handy. Without the optional argument, 
it would work the same way dict.popitem works now

example::

>>> d = dict([(x,x) for x in range(10)])
>>> d
{0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 
8, 9: 9}
>>> d.popitem() # retrieves "random" key->val pair
(0, 0)
>>> d.popitem(4) # val=d[4]; del d[4]; return val
4
>>> d.popitem(6) # val=d[6]; del d[6]; return val 6
>>> d # missing keys [0, 4, 6]
{1: 1, 2: 2, 3: 3, 5: 5, 7: 7, 8: 8, 9: 9}





----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-04-28 14:43

Message:
Logged In: YES 
user_id=80475

The patch for dict.popitem(k) was rejected on the grounds 
that 1) the optional argument slowed down popitem and 2) 
returning (k,v) didn't make sense when k was already 
known.  A revised patch for for dict.pop(k) --> v was 
accepted, loaded to CVS, and closed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-04-05 19:44

Message:
Logged In: YES 
user_id=80475

A patch implementing this request is at:
http://sourceforge.net/tracker/index.php?
func=detail&aid=539949&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-02-20 08:22

Message:
Logged In: YES 
user_id=80475

Great idea!

The rationale is just like that for .setdefault() in 
providing a fast, simple, single method, single look-up 
replacement for a commonly used sequence of dictionary 
operations.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-17 00:17

Message:
Logged In: YES 
user_id=21627

Also requested as

http://sourceforge.net/tracker/index.php?func=detail&aid=504880&group_id=5470&atid=355470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 17:09:33 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 09:09:33 -0700
Subject: [Python-bugs-list] [ python-Feature Requests-495086 ] dict.popitem(key=None)
Message-ID: <E171rEz-0005UH-00@usw-sf-web2.sourceforge.net>

Feature Requests item #495086, was opened at 2001-12-19 17:26
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Dan Parisien (mathematician)
Assigned to: Nobody/Anonymous (nobody)
Summary: dict.popitem(key=None)

Initial Comment:
Would it be possible to add an extra argument to the 
popitem method of DictionaryType so one can both 
retrieve a dict item and delete it at the same time? 
It would be so handy. Without the optional argument, 
it would work the same way dict.popitem works now

example::

>>> d = dict([(x,x) for x in range(10)])
>>> d
{0: 0, 1: 1, 2: 2, 3: 3, 4: 4, 5: 5, 6: 6, 7: 7, 8: 
8, 9: 9}
>>> d.popitem() # retrieves "random" key->val pair
(0, 0)
>>> d.popitem(4) # val=d[4]; del d[4]; return val
4
>>> d.popitem(6) # val=d[6]; del d[6]; return val 6
>>> d # missing keys [0, 4, 6]
{1: 1, 2: 2, 3: 3, 5: 5, 7: 7, 8: 8, 9: 9}





----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-04-28 16:43

Message:
Logged In: YES 
user_id=80475

The patch for dict.popitem(k) was rejected on the grounds 
that 1) the optional argument slowed down popitem and 2) 
returning (k,v) didn't make sense when k was already 
known.  A revised patch for for dict.pop(k) --> v was 
accepted, loaded to CVS, and closed.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-04-05 21:44

Message:
Logged In: YES 
user_id=80475

A patch implementing this request is at:
http://sourceforge.net/tracker/index.php?
func=detail&aid=539949&group_id=5470&atid=305470

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-02-20 09:22

Message:
Logged In: YES 
user_id=80475

Great idea!

The rationale is just like that for .setdefault() in 
providing a fast, simple, single method, single look-up 
replacement for a commonly used sequence of dictionary 
operations.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-02-17 01:17

Message:
Logged In: YES 
user_id=21627

Also requested as

http://sourceforge.net/tracker/index.php?func=detail&aid=504880&group_id=5470&atid=355470

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=355470&aid=495086&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 17:21:00 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 09:21:00 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E171rQ4-0005EO-00@usw-sf-web4.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 19:55:49 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 11:55:49 -0700
Subject: [Python-bugs-list] [ python-Bugs-549725 ] xml.dom.minidom doesn't pass CDATA
Message-ID: <E171tpt-0006y2-00@usw-sf-web4.sourceforge.net>

Bugs item #549725, was opened at 2002-04-28 08:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom doesn't pass CDATA

Initial Comment:
>>> import sys
>>> from sxml.xml2py import parseFile
# this is a simple wrapper to xml.dom.minidom.parse()
>>> x=parseFile(sys.stdin)

<?xml version="1.0" ?>           
<foo><![CDATA[dies ist
ein bar
]]></foo>
^D

>>> x
[<DOM Element: foo at 1076384172>]
>>> x.childNodes[0].childNodes
[<DOM Text node "dies ist">, <DOM Text node "\n">, <DOM Text node "ein bar">, <DOM Text node "\n">]
>>> 

I was expecting a CDATASection node here.
(In fact, my code would like to depend on it.)


----------------------------------------------------------------------

>Comment By: Matthias Urlichs (smurf)
Date: 2002-04-28 18:55

Message:
Logged In: YES 
user_id=10327

SXML is a project of mine. As I said, it's just a simple wrapper for minidom.

Why should CDATA handling be optional? It seems that it should be _easier_ to package the string into one CDATASection element. Instead, four Text elements are used -- the first line, the first linefeed, the second line, and the second linefeed. It's additional effort, and I'd like to turn it off if I don't want it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 13:59

Message:
Logged In: YES 
user_id=21627

What is sxml? Why is this a bug in Python?

Notice that the use of CDATA in the DOM is completely
optional - the DOM tree represents your document correctly.
Code relying on CDATA is broken.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 20:57:32 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 12:57:32 -0700
Subject: [Python-bugs-list] [ python-Bugs-549725 ] xml.dom.minidom doesn't pass CDATA
Message-ID: <E171unc-0007f9-00@usw-sf-web4.sourceforge.net>

Bugs item #549725, was opened at 2002-04-28 10:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom doesn't pass CDATA

Initial Comment:
>>> import sys
>>> from sxml.xml2py import parseFile
# this is a simple wrapper to xml.dom.minidom.parse()
>>> x=parseFile(sys.stdin)

<?xml version="1.0" ?>           
<foo><![CDATA[dies ist
ein bar
]]></foo>
^D

>>> x
[<DOM Element: foo at 1076384172>]
>>> x.childNodes[0].childNodes
[<DOM Text node "dies ist">, <DOM Text node "\n">, <DOM Text node "ein bar">, <DOM Text node "\n">]
>>> 

I was expecting a CDATASection node here.
(In fact, my code would like to depend on it.)


----------------------------------------------------------------------

>Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 21:57

Message:
Logged In: YES 
user_id=21627

Support for CDATA sections is optional because the DOM spec
says so, see

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-E067D597

Notice that the DOM spec itself is silent on the issue of
building DOM trees. In DOM Level 3, there is a feature to
control whether CDATA sections are created or not, but
minidom is not targeted at DOM level 3 (and DOM level 3 is
not completed).

The DOM tree is build based on the information that the XML
parser produces, which happens to be Expat. This parser, in
turn, does not support reporting CDATA section boundaries. 

You could try to use a different XML parser. Notice that the
minidom builder uses the SAX API, which supports reporting
of CDATA section boundaries as an option only, as well. So
you'd not only need a different parser, but also a different
DOM builder. If you absolutely need this functionality, you
can use 4DOM with xmlproc, from PyXML.

If you don't like several subsequent Text nodes, you can use
the DOM element .normalize method to merge them. Notice that
.normalize would not merge CDATA sections.

In any case, this is clearly not a bug in minidom.

----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-04-28 20:55

Message:
Logged In: YES 
user_id=10327

SXML is a project of mine. As I said, it's just a simple wrapper for minidom.

Why should CDATA handling be optional? It seems that it should be _easier_ to package the string into one CDATASection element. Instead, four Text elements are used -- the first line, the first linefeed, the second line, and the second linefeed. It's additional effort, and I'd like to turn it off if I don't want it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 15:59

Message:
Logged In: YES 
user_id=21627

What is sxml? Why is this a bug in Python?

Notice that the use of CDATA in the DOM is completely
optional - the DOM tree represents your document correctly.
Code relying on CDATA is broken.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 21:03:11 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 13:03:11 -0700
Subject: [Python-bugs-list] [ python-Bugs-549725 ] xml.dom.minidom doesn't pass CDATA
Message-ID: <E171ut5-0001av-00@usw-sf-web1.sourceforge.net>

Bugs item #549725, was opened at 2002-04-28 08:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Open
Resolution: Invalid
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom doesn't pass CDATA

Initial Comment:
>>> import sys
>>> from sxml.xml2py import parseFile
# this is a simple wrapper to xml.dom.minidom.parse()
>>> x=parseFile(sys.stdin)

<?xml version="1.0" ?>           
<foo><![CDATA[dies ist
ein bar
]]></foo>
^D

>>> x
[<DOM Element: foo at 1076384172>]
>>> x.childNodes[0].childNodes
[<DOM Text node "dies ist">, <DOM Text node "\n">, <DOM Text node "ein bar">, <DOM Text node "\n">]
>>> 

I was expecting a CDATASection node here.
(In fact, my code would like to depend on it.)


----------------------------------------------------------------------

>Comment By: Matthias Urlichs (smurf)
Date: 2002-04-28 20:03

Message:
Logged In: YES 
user_id=10327

Oh well...

I'm therefore closing this bug.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 19:57

Message:
Logged In: YES 
user_id=21627

Support for CDATA sections is optional because the DOM spec
says so, see

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-E067D597

Notice that the DOM spec itself is silent on the issue of
building DOM trees. In DOM Level 3, there is a feature to
control whether CDATA sections are created or not, but
minidom is not targeted at DOM level 3 (and DOM level 3 is
not completed).

The DOM tree is build based on the information that the XML
parser produces, which happens to be Expat. This parser, in
turn, does not support reporting CDATA section boundaries. 

You could try to use a different XML parser. Notice that the
minidom builder uses the SAX API, which supports reporting
of CDATA section boundaries as an option only, as well. So
you'd not only need a different parser, but also a different
DOM builder. If you absolutely need this functionality, you
can use 4DOM with xmlproc, from PyXML.

If you don't like several subsequent Text nodes, you can use
the DOM element .normalize method to merge them. Notice that
.normalize would not merge CDATA sections.

In any case, this is clearly not a bug in minidom.

----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-04-28 18:55

Message:
Logged In: YES 
user_id=10327

SXML is a project of mine. As I said, it's just a simple wrapper for minidom.

Why should CDATA handling be optional? It seems that it should be _easier_ to package the string into one CDATASection element. Instead, four Text elements are used -- the first line, the first linefeed, the second line, and the second linefeed. It's additional effort, and I'd like to turn it off if I don't want it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 13:59

Message:
Logged In: YES 
user_id=21627

What is sxml? Why is this a bug in Python?

Notice that the use of CDATA in the DOM is completely
optional - the DOM tree represents your document correctly.
Code relying on CDATA is broken.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 21:04:28 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 13:04:28 -0700
Subject: [Python-bugs-list] [ python-Bugs-549725 ] xml.dom.minidom doesn't pass CDATA
Message-ID: <E171uuK-0001bp-00@usw-sf-web1.sourceforge.net>

Bugs item #549725, was opened at 2002-04-28 08:41
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Matthias Urlichs (smurf)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.dom.minidom doesn't pass CDATA

Initial Comment:
>>> import sys
>>> from sxml.xml2py import parseFile
# this is a simple wrapper to xml.dom.minidom.parse()
>>> x=parseFile(sys.stdin)

<?xml version="1.0" ?>           
<foo><![CDATA[dies ist
ein bar
]]></foo>
^D

>>> x
[<DOM Element: foo at 1076384172>]
>>> x.childNodes[0].childNodes
[<DOM Text node "dies ist">, <DOM Text node "\n">, <DOM Text node "ein bar">, <DOM Text node "\n">]
>>> 

I was expecting a CDATASection node here.
(In fact, my code would like to depend on it.)


----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-04-28 20:03

Message:
Logged In: YES 
user_id=10327

Oh well...

I'm therefore closing this bug.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 19:57

Message:
Logged In: YES 
user_id=21627

Support for CDATA sections is optional because the DOM spec
says so, see

http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/core.html#ID-E067D597

Notice that the DOM spec itself is silent on the issue of
building DOM trees. In DOM Level 3, there is a feature to
control whether CDATA sections are created or not, but
minidom is not targeted at DOM level 3 (and DOM level 3 is
not completed).

The DOM tree is build based on the information that the XML
parser produces, which happens to be Expat. This parser, in
turn, does not support reporting CDATA section boundaries. 

You could try to use a different XML parser. Notice that the
minidom builder uses the SAX API, which supports reporting
of CDATA section boundaries as an option only, as well. So
you'd not only need a different parser, but also a different
DOM builder. If you absolutely need this functionality, you
can use 4DOM with xmlproc, from PyXML.

If you don't like several subsequent Text nodes, you can use
the DOM element .normalize method to merge them. Notice that
.normalize would not merge CDATA sections.

In any case, this is clearly not a bug in minidom.

----------------------------------------------------------------------

Comment By: Matthias Urlichs (smurf)
Date: 2002-04-28 18:55

Message:
Logged In: YES 
user_id=10327

SXML is a project of mine. As I said, it's just a simple wrapper for minidom.

Why should CDATA handling be optional? It seems that it should be _easier_ to package the string into one CDATASection element. Instead, four Text elements are used -- the first line, the first linefeed, the second line, and the second linefeed. It's additional effort, and I'd like to turn it off if I don't want it.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 13:59

Message:
Logged In: YES 
user_id=21627

What is sxml? Why is this a bug in Python?

Notice that the use of CDATA in the DOM is completely
optional - the DOM tree represents your document correctly.
Code relying on CDATA is broken.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549725&group_id=5470



From noreply@sourceforge.net  Sun Apr 28 22:20:05 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 14:20:05 -0700
Subject: [Python-bugs-list] [ python-Bugs-549907 ] Wrong #ifdef in _localemodule.c
Message-ID: <E171w5V-0002RM-00@usw-sf-web1.sourceforge.net>

Bugs item #549907, was opened at 2002-04-28 21:20
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549907&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Raj Srinivasan (rsrini)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong #ifdef in _localemodule.c

Initial Comment:
At line 642 should be #ifdef HAVE_LIBINTL_H instead of
#ifdef HAVE_LANGINFO_H

raj



----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549907&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 01:47:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 17:47:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-547093 ] urllib/httplib vs corrupted tcp/ip stack
Message-ID: <E171zKI-0002Fm-00@usw-sf-web4.sourceforge.net>

Bugs item #547093, was opened at 2002-04-22 10:03
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547093&group_id=5470

>Category: Python Library
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Asle Pedersen (apederse)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib/httplib vs corrupted tcp/ip stack

Initial Comment:
I am trying to connect to a server (talouselama.fi) 
using urllib2. The server respond immediately after it 
has received the first package from the client 
(urllib2). Since httplib fragment http requests in a 
request package and subsequent header packages the 
server disregards any header information that is sendt 
using urllib2. I have used ethereal to trace the 
packages for the connection. I can provide a dump if 
necessary.

This problem may well be due to a corruptet tcp/ip 
stack at the server (talouselama.fi) but shouldn't 
urllib handle this if any other browser does. (lynx, 
explorer, opera - no exception)??

/Asle


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:47

Message:
Logged In: YES 
user_id=6380

Can you explain what you think httplib is doing wrong?  Are
you saying that it should buffer the whole request until it
is ready to send it in a single send() request?  If so, I
don't think it is httplib's responsibility to fix this --
the server doesn't follow the HTTP protocol (which says
nothing about keeping things together in a single packet),
and its webmaster should be informed of the bug in his site.

Other browsers probably happen to send the whole request in
a single packet.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=547093&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 01:50:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 17:50:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky
Message-ID: <E171zNC-0004Xn-00@usw-sf-web1.sourceforge.net>

Bugs item #549038, was opened at 2002-04-26 08:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
Assigned to: Nobody/Anonymous (nobody)
Summary: cgitb variable dumps a little flaky

Initial Comment:
First off, easy problem: lookup() should look in 
frame.f_globals["__builtins__"] also. Along the same 
lines, I am not sure if lookup works properly with 
nested scopes, but since I don't use nested scopes in 
any of my code this is not a problem for me ;-)

Secondly, the parsing in scanvars() is somewhat hacky. 
For example, given the following line:

  foo(open(filename).read())

it will think the following variables exist:

  foo
  open
  filename
  ).read

Obviously this last one is incorrect. I am not sure if 
this is easy to fix or not.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:50

Message:
Logged In: YES 
user_id=6380

Nobody except Ka-Ping Ping understands the code in cgitb.py,
so I suggest that you track him down and get him to look at
this bug report. In the past I've performed this service
myself but I'm getting tired of it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 01:53:34 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 17:53:34 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E171zQ6-00025D-00@usw-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 12:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
>Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 12:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 03:25:16 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Sun, 28 Apr 2002 19:25:16 -0700
Subject: [Python-bugs-list] [ python-Bugs-549038 ] cgitb variable dumps a little flaky
Message-ID: <E1720qq-0005bj-00@usw-sf-web1.sourceforge.net>

Bugs item #549038, was opened at 2002-04-26 13:11
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Ribbens (jribbens)
>Assigned to: Ka-Ping Yee (ping)
Summary: cgitb variable dumps a little flaky

Initial Comment:
First off, easy problem: lookup() should look in 
frame.f_globals["__builtins__"] also. Along the same 
lines, I am not sure if lookup works properly with 
nested scopes, but since I don't use nested scopes in 
any of my code this is not a problem for me ;-)

Secondly, the parsing in scanvars() is somewhat hacky. 
For example, given the following line:

  foo(open(filename).read())

it will think the following variables exist:

  foo
  open
  filename
  ).read

Obviously this last one is incorrect. I am not sure if 
this is easy to fix or not.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:50

Message:
Logged In: YES 
user_id=6380

Nobody except Ka-Ping Ping understands the code in cgitb.py,
so I suggest that you track him down and get him to look at
this bug report. In the past I've performed this service
myself but I'm getting tired of it.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549038&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 17:29:48 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 29 Apr 2002 09:29:48 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E172E28-0004EC-00@usw-sf-web4.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 17:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: John J Lee (jjlee)
Date: 2002-04-29 17:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 01:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 17:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 19:10:06 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 29 Apr 2002 11:10:06 -0700
Subject: [Python-bugs-list] [ python-Bugs-549151 ] urllib2 POSTs on redirect
Message-ID: <E172FbC-00054N-00@usw-sf-web3.sourceforge.net>

Bugs item #549151, was opened at 2002-04-26 12:04
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: John J Lee (jjlee)
Assigned to: Jeremy Hylton (jhylton)
Summary: urllib2 POSTs on redirect

Initial Comment:

urllib2 (I'm using 1.13.22 with Python 2.0, but I assume the 2.2 branch does the same) uses the 
POST method on redirect, contrary to RFC1945 section 9.3:

> 9.3  Redirection 3xx
> 
>    This class of status code indicates that further action needs to be
>    taken by the user agent in order to fulfill the request. The action
>    required may be carried out by the user agent without interaction
>    with the user if and only if the method used in the subsequent
>    request is GET or HEAD. A user agent should never automatically
>    redirect a request more than 5 times, since such redirections usually
>    indicate an infinite loop.

Can be fixed in HTTPRedirectHandler.http_error_302 by replacing
        new = Request(newurl, req.get_data())

with
        new = Request(newurl)

so that GET is done on redirect instead of POST.

I suppose the limit of 10 in the same function should be changed to 5, also.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-29 14:10

Message:
Logged In: YES 
user_id=6380

Fair enough. I'll leve it to Jeremy to review the proposed
fix. (Note that he's busy though.)

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-29 12:29

Message:
Logged In: YES 
user_id=261020

I don't see why it shouldn't substitue a GET.  That certainly seems to be
the standard practice (well, at least that's what lynx does), and in the case
of the only site where I've encountered redirects on POST, the redirect URL
contains urlencoded stuff, so it clearly expects the user-agent to do a GET.
The site would break if this didn't happen, so I guess Netscape and IE must
do the same thing.

Clearly the RFC *does* allow this, though it doesn't require it (or specify
what should happen here in any way other than to say that a POST is not
allowed, in fact).  Since it's standard practice and allowed by the RFC, I
don't think it should be an error.

John


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-28 20:53

Message:
Logged In: YES 
user_id=6380

Hm, the way I interpret the text you quote, if the original
request is  a POST, it should probably not substitute a GET
but report the error.

Assigning to Jeremy since it's his module.

----------------------------------------------------------------------

Comment By: John J Lee (jjlee)
Date: 2002-04-28 12:21

Message:
Logged In: YES 
user_id=261020

1. Bug is also in 2.2 branch

2. The fix (in 2.1 and 2.2) should reflect the earlier bug fix in the 2.2 branch to add the old headers:

new = Request(newurl, headers=req.headers)

3. I guess 10 should be replaced with 4, not 5.


John


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549151&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 21:28:55 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 29 Apr 2002 13:28:55 -0700
Subject: [Python-bugs-list] [ python-Bugs-550364 ] Version number handling
Message-ID: <E172HlX-0005sp-00@usw-sf-web2.sourceforge.net>

Bugs item #550364, was opened at 2002-04-29 16:28
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470

Category: Distutils
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: A.M. Kuchling (akuchling)
Assigned to: Nobody/Anonymous (nobody)
Summary: Version number handling

Initial Comment:
A while ago, Tim Peters mentioned in a check-in message:

"Change the version string from "2.2+" to "2.3a0".  distutils 
peels off
the first 3 characters of this string in several places, so for as 
long
as they remain "2.2" it confuses the heck out of attempts to 
build 2.3 stuff using distutils."

It's true; distutils does sys.version[:3] in a few places.
The attached patch factors this out so it'll be easier to 
change.  

(There's also a Python development issue here, namely when
the version number gets bumped in the CVS tree.)


 


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550364&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 21:46:01 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 29 Apr 2002 13:46:01 -0700
Subject: [Python-bugs-list] [ python-Bugs-508100 ] telnetlib in debug mode
Message-ID: <E172I25-00061c-00@usw-sf-web2.sourceforge.net>

Bugs item #508100, was opened at 2002-01-24 14:39
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508100&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Cedric Moreau (c_moe)
Assigned to: A.M. Kuchling (akuchling)
Summary: telnetlib in debug mode

Initial Comment:
In telnetlib.py, in function process_rawq() the display
of IAC mode options in debug mode isn't right:
Actually:
...
self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(c))
...
self.msg('IAC %s %d', c == WILL and 'WILL' or 'WONT',
ord(c))

Should be:
...
self.msg('IAC %s %d', c == DO and 'DO' or 'DONT', ord(opt))
...
self.msg('IAC %s %d', c == WILL and 'WILL' or 'WONT',
ord(opt))
...


----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2002-04-29 16:46

Message:
Logged In: YES 
user_id=11375

Fixed by patch #416079.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=508100&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 23:21:40 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 29 Apr 2002 15:21:40 -0700
Subject: [Python-bugs-list] [ python-Bugs-550409 ] What does os.read on EOF?
Message-ID: <E172JWe-0001Rb-00@usw-sf-web1.sourceforge.net>

Bugs item #550409, was opened at 2002-04-29 22:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550409&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: What does os.read on EOF?

Initial Comment:
You may want to note that os.read() returns 
(apparently) an empty string on EOF. This appears to 
be true of regular files and of file descriptor 
returned by pty.fork().

Yours,
Noah

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550409&group_id=5470



From noreply@sourceforge.net  Mon Apr 29 23:22:22 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 29 Apr 2002 15:22:22 -0700
Subject: [Python-bugs-list] [ python-Bugs-550409 ] What does os.read() return on EOF?
Message-ID: <E172JXK-0001SS-00@usw-sf-web1.sourceforge.net>

Bugs item #550409, was opened at 2002-04-29 22:21
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550409&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
>Summary: What does os.read() return on EOF?

Initial Comment:
You may want to note that os.read() returns 
(apparently) an empty string on EOF. This appears to 
be true of regular files and of file descriptor 
returned by pty.fork().

Yours,
Noah

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550409&group_id=5470



From noreply@sourceforge.net  Tue Apr 30 00:02:38 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Mon, 29 Apr 2002 16:02:38 -0700
Subject: [Python-bugs-list] [ python-Bugs-549338 ] lib-dynload/*.so permissions wrong
Message-ID: <E172KAI-0007ro-00@usw-sf-web3.sourceforge.net>

Bugs item #549338, was opened at 2002-04-26 20:38
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549338&group_id=5470

Category: Installation
Group: Python 2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: J. Lewis Muir (jlmuir)
Assigned to: Nobody/Anonymous (nobody)
Summary: lib-dynload/*.so permissions wrong

Initial Comment:
After

    ./configure --prefix=<PYTHON_INSTALL_DIR>
    make
    make test
    make install

the .so files installed 
in '<PYTHON_INSTALL_DIR>/lib/python2.2/lib-dynload' 
have permissions set to 700. They should instead have 
file permissions set to 755.

Running the python interpreter as a non-root user with 
the lib-dynload/*.so file permissions set to 700 (as 
is done by the install), a simple import of the time 
module fails:

    >>> import time
    Traceback (most recent call last):
      File "<stdin>", line 1, in ?
    ImportError: No module named time
    >>>

After changing file permissions to 755, 'import time' 
works fine.

---
Python 2.2.1
Mandrake 8.0
Linux 2.4.8
x86 hardware

----------------------------------------------------------------------

>Comment By: J. Lewis Muir (jlmuir)
Date: 2002-04-29 18:02

Message:
Logged In: YES 
user_id=527708

The umask was set to 022.

To be exact, the 'configure', 'make', and 'make test' were 
run as a normal user with umask set to 077. I then 'su'ed 
as root (using the command 'su - root', making the shell a 
login shell) where my umask became 022 and then ran 'make 
install'.

Both the normal user shell and the root shell were GNU 
bash, version 2.05.1(1)-release.

----------------------------------------------------------------------

Comment By: Martin v. L�wis (loewis)
Date: 2002-04-28 09:00

Message:
Logged In: YES 
user_id=21627

When you perform the installation, what is your umask?

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=549338&group_id=5470



From noreply@sourceforge.net  Tue Apr 30 21:40:13 2002
From: noreply@sourceforge.net (noreply@sourceforge.net)
Date: Tue, 30 Apr 2002 13:40:13 -0700
Subject: [Python-bugs-list] [ python-Bugs-550777 ] fcntl module with wrong module for ioctl
Message-ID: <E172eQ1-0005fT-00@usw-sf-web4.sourceforge.net>

Bugs item #550777, was opened at 2002-04-30 20:40
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550777&group_id=5470

Category: Documentation
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Noah Spurrier (noah)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: fcntl module with wrong module for ioctl

Initial Comment:
The documentation for fcntl.ioctl() gives the wrong 
module for definitions of ioctl operations.

    http://www.python.org/doc/lib/module-fcntl.html

    ioctl(fd, op, arg) 
    This function is identical to the fcntl()
    function, except that the operations are typically
    defined in the library module IOCTL. 

As far as I can tell, there is no IOCTL module.
I think what the documentation should say is the
termios module. The termios module defines various 
ioctl operation constants.

The following example demonstrates an ioctl operation
to get the current terminal window size.
#!/usr/bin/env python

import termios, fcntl, struct, sys

s = struct.pack("HHHH", 0, 0, 0, 0)
fd_stdout = sys.stdout.fileno()
x = fcntl.ioctl(fd_stdout, termios.TIOCGWINSZ, s)
print '(rows, cols, x pixels, y pixels) =',
print struct.unpack("HHHH", x)

Yours,
Noah


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=550777&group_id=5470