From report at bugs.python.org  Fri Feb  1 00:09:39 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 31 Jan 2008 23:09:39 -0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1201820979.09.0.06635507204.issue1983@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I fixed the bug in r60484. Python was already using pid_t on several
occasions like getpid(). I added a test to verify that PyInt_FromLong()
can always handle pid_t.

Do you want to port the fix to 2.5?

----------
resolution:  -> fixed
status: open -> pending
versions: +Python 2.5 -Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________

From report at bugs.python.org  Fri Feb  1 00:27:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 31 Jan 2008 23:27:40 -0000
Subject: [issue1984] The raw string r'\' fails
In-Reply-To: <1201818368.03.0.299164822165.issue1984@psf.upfronthosting.co.za>
Message-ID: <1201822060.18.0.690627953444.issue1984@psf.upfronthosting.co.za>


Georg Brandl added the comment:

This is not easily fixable -- it has been discussed several times on
python-dev and won't change.

----------
nosy: +georg.brandl
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1984>
__________________________________

From report at bugs.python.org  Fri Feb  1 00:57:39 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 31 Jan 2008 23:57:39 -0000
Subject: [issue1515] deepcopy doesn't copy instance methods
In-Reply-To: <1201820047.8.0.854944184446.issue1515@psf.upfronthosting.co.za>
Message-ID: <ca471dc20801311557o3dbdefa2u8a54f196cbba760b@mail.gmail.com>


Guido van Rossum added the comment:

On Jan 31, 2008 2:54 PM, Michael Van Biesbrouck wrote:
> Why do people want to use copy and deepcopy?  I think that the issue is
> that Python is an imperative language that passes and copies references.
>  If a library function doesn't treat its arguments as const, horrible
> things could happen.  Compounding this, several standard operations
> (such as sort) operate in place, so if you want to use them then you
> need to make shallow copies at the very least.

I see the point for shallow copies. I just don't see the point for deep copies.

> When non-scalar types
> nest, the whole structure can be deepcopied or copy can be used
> repeatedly in a selective manner (with a high chance of bugs).

I don't understand the use case. I still think this comes primarily
from a lack of familiarity with how Python is typically used.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1515>
__________________________________

From report at bugs.python.org  Fri Feb  1 03:14:20 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 01 Feb 2008 02:14:20 -0000
Subject: [issue1482] IMAP4 SSL isn't working
In-Reply-To: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za>
Message-ID: <1201832060.8.0.342909866879.issue1482@psf.upfronthosting.co.za>


Bill Janssen added the comment:

I guess I'll check it in.  There's no effective test case for the
imaplib module, though.  So if it's broken, we won't know.

When I try connecting to my local IMAP server, I get

>>> c = imaplib.IMAP4("127.0.0.1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/local/python/3k/src/Lib/imaplib.py", line 190, in __init__
    raise self.error(self.welcome)
imaplib.error: b'* OK [CAPABILITY IMAP4rev1 LOGINDISABLED STARTTLS]
UpLib IMAP Server (V4r1) ready.'
>>>

I think this is bug 1210.  However, it is able to connect to an
SSL-protected server (not the one above) and get the same error message,
so I think the SSL patch works.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482>
__________________________________

From report at bugs.python.org  Fri Feb  1 03:17:04 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 01 Feb 2008 02:17:04 -0000
Subject: [issue1482] IMAP4 SSL isn't working
In-Reply-To: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za>
Message-ID: <1201832224.46.0.0968396132834.issue1482@psf.upfronthosting.co.za>


Bill Janssen added the comment:

I've committed the patch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482>
__________________________________

From report at bugs.python.org  Fri Feb  1 03:23:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 01 Feb 2008 02:23:53 -0000
Subject: [issue1941] 2.6 stdlib using with statement
In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za>
Message-ID: <1201832633.69.0.516284859829.issue1941@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This new patch removes changes to the platform module.

Added file: http://bugs.python.org/file9342/stdlib-with-stmt2-no-platform.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1941>
__________________________________

From report at bugs.python.org  Fri Feb  1 03:53:42 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 01 Feb 2008 02:53:42 -0000
Subject: [issue1482] IMAP4 SSL isn't working
In-Reply-To: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za>
Message-ID: <1201834422.21.0.779362361893.issue1482@psf.upfronthosting.co.za>


Bill Janssen added the comment:

I guess I'll check it in.  There's no effective test case for the
imaplib module, though.  So if it's broken, we won't know.

When I try connecting to my local IMAP server, I get

>>> c = imaplib.IMAP4("127.0.0.1")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/local/python/3k/src/Lib/imaplib.py", line 190, in __init__
    raise self.error(self.welcome)
imaplib.error: b'* OK [CAPABILITY IMAP4rev1 LOGINDISABLED STARTTLS]
UpLib IMAP Server (V4r1) ready.'
>>>

I think this is bug 1210.  However, it is able to connect to an
SSL-protected server (not the one above) and get the same error message,
so I think the SSL patch works.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482>
__________________________________

From report at bugs.python.org  Fri Feb  1 03:53:55 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 01 Feb 2008 02:53:55 -0000
Subject: [issue1482] IMAP4 SSL isn't working
In-Reply-To: <1195637275.04.0.129181694073.issue1482@psf.upfronthosting.co.za>
Message-ID: <1201834435.42.0.120098308822.issue1482@psf.upfronthosting.co.za>


Changes by Bill Janssen:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1482>
__________________________________

From report at bugs.python.org  Fri Feb  1 03:58:13 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2008 02:58:13 -0000
Subject: [issue1941] 2.6 stdlib using with statement
In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za>
Message-ID: <1201834693.49.0.606487999153.issue1941@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Am unassigning because I don't have time for a detailed review.

For the most part, I'm not excited about this patch which targets 
modules that aren't being actively supervised by their original 
contributor.

----------
assignee: rhettinger -> 

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1941>
__________________________________

From report at bugs.python.org  Fri Feb  1 06:04:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Feb 2008 05:04:54 -0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201820979.09.0.06635507204.issue1983@psf.upfronthosting.co.za>
Message-ID: <47A2A871.7020205@v.loewis.de>


Martin v. L?wis added the comment:

> Do you want to port the fix to 2.5?

I'm not quite sure that the patch actually fixes the
problem. IIUC, HiStar is available in a 32-bit version,
too, yet it may still use a 64-bit pid_t (Ryan, can
you confirm whether that's the case?).

If so, Python would now fail to compile under that
patch. Backporting a change that causes Python to fail
to compile on some systems is not a good idea.

If that aspect was fixed also (e.g. by always returning
long ints on systems where sizeof(pid_t)>sizeof(long)),
a backport would be ok. For a perfect backport, that
change might still cause a behavior change:  on
a system where sizeof(pid_t)>sizeof(long), yet the
system only ever uses pid_t values < INT_MAX, people
would see that the fork return type changes unreasonably;
a perfect backport would only return longs if the values
are out of range. This is probably over-cautious, as
it's fairly unlikely that such systems actually exist.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________

From report at bugs.python.org  Fri Feb  1 07:07:01 2008
From: report at bugs.python.org (Ryan Stutsman)
Date: Fri, 01 Feb 2008 06:07:01 -0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1201846021.48.0.27345880113.issue1983@psf.upfronthosting.co.za>


Ryan Stutsman added the comment:

> IIUC, HiStar is available in a 32-bit version,
> too, yet it may still use a 64-bit pid_t (Ryan, can
> you confirm whether that's the case?).

Great point.  pid_t is always 64-bit on HiStar.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________

From report at bugs.python.org  Fri Feb  1 07:26:51 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 01 Feb 2008 06:26:51 -0000
Subject: [issue1965] Move trunc() to math module
In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za>
Message-ID: <1201847211.14.0.880248741041.issue1965@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Moved in r60486. I tried to improve the docstring too.

----------
resolution: accepted -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1965>
__________________________________

From report at bugs.python.org  Fri Feb  1 07:36:38 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2008 06:36:38 -0000
Subject: [issue1965] Move trunc() to math module
In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za>
Message-ID: <1201847798.94.0.549018546114.issue1965@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It would be nice in the docstring the definition of "truncate" wasn't 
assumed.  It would be more specific to say that it rounds towards zero 
or that it is ceil(x) for negatives and floor(x) for positives.  
Alternatively, state that it returns the integer portion of a Real.  
The word "truncate" in the docstring is close to being a circular 
definition -- if you don't know what math.trunc() does, being told it 
truncates isn't especially informative.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1965>
__________________________________

From report at bugs.python.org  Fri Feb  1 09:13:13 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 01 Feb 2008 08:13:13 -0000
Subject: [issue1963] marshal module is leaking references
In-Reply-To: <1201608887.67.0.254774790303.issue1963@psf.upfronthosting.co.za>
Message-ID: <1201853593.46.0.262155917449.issue1963@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Neal fixed it in r60488

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1963>
__________________________________

From report at bugs.python.org  Fri Feb  1 10:41:08 2008
From: report at bugs.python.org (Colin Watson)
Date: Fri, 01 Feb 2008 09:41:08 -0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1201858868.12.0.291898960418.issue1652@psf.upfronthosting.co.za>


Colin Watson added the comment:

To be quite honest I can't think of any incompatibilities that wouldn't
have the basic result of improving matters. I put the migration stuff in
my bug report in case somebody else could, because I don't want the bug
fix to stall on that.

My preference would be for Python to move to behaviour equivalent to
restore_sigpipe=True in the next release, but I would rather that it
gained restore_sigpipe with the wrong default than that it didn't gain
it at all.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
__________________________________

From report at bugs.python.org  Fri Feb  1 10:41:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 Feb 2008 09:41:57 -0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1201858917.71.0.222198082084.issue1652@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Martin, what do you think?

----------
assignee:  -> loewis
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
__________________________________

From report at bugs.python.org  Fri Feb  1 11:09:56 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 01 Feb 2008 10:09:56 -0000
Subject: [issue1864] test_locale doesn't use unittest
In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za>
Message-ID: <1201860596.79.0.283025030849.issue1864@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I think that we should separate this from #1222, and have two steps:
- first change test_locale, without any modification to localemodule.
- then add features and more tests.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1864>
__________________________________

From report at bugs.python.org  Fri Feb  1 11:53:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 Feb 2008 10:53:39 -0000
Subject: [issue800926] Python version numbers in headers/footers PDF
	documentation
Message-ID: <1201863219.47.0.873608241062.issue800926@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Added to Sphinx in r60490.

----------
resolution:  -> accepted
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue800926>
____________________________________

From report at bugs.python.org  Fri Feb  1 11:56:33 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 Feb 2008 10:56:33 -0000
Subject: [issue1222] locale.format bug if thousand separator is space (french
	separator as example)
In-Reply-To: <1191172668.69.0.513518274707.issue1222@psf.upfronthosting.co.za>
Message-ID: <1201863393.24.0.0823056685178.issue1222@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Looks good to me.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
__________________________________

From report at bugs.python.org  Fri Feb  1 12:18:48 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 01 Feb 2008 11:18:48 -0000
Subject: [issue1986] io.StringIO allows any parameter
In-Reply-To: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>
Message-ID: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>


New submission from Georg Brandl:

>>> x = io.StringIO(1)
>>> x.read()
'1'

----------
components: Extension Modules
messages: 61957
nosy: georg.brandl
priority: high
severity: normal
status: open
title: io.StringIO allows any parameter
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1986>
__________________________________

From report at bugs.python.org  Fri Feb  1 13:01:44 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2008 12:01:44 -0000
Subject: [issue1864] test_locale doesn't use unittest
In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za>
Message-ID: <1201867304.08.0.678446046378.issue1864@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well it was how I planned to do it at first (hence this bug entry) :-)
I can still try to split the #1222 patch if it makes things easier (but
does it?).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1864>
__________________________________

From report at bugs.python.org  Fri Feb  1 16:00:38 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 01 Feb 2008 15:00:38 -0000
Subject: [issue974019] ConfigParser non-string defaults broken with
	.getboolean()
Message-ID: <1201878038.4.0.449729996434.issue974019@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda:


----------
nosy: +draghuram

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue974019>
____________________________________

From report at bugs.python.org  Fri Feb  1 16:17:40 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 01 Feb 2008 15:17:40 -0000
Subject: [issue1049816] test_socket PORT conflict with boa-constructor
Message-ID: <1201879060.23.0.988438531417.issue1049816@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

test_socket.py now seems to use dynamically computed port number so
there should not be any port number conflicts.

----------
nosy: +draghuram
resolution:  -> out of date
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1049816>
_____________________________________

From report at bugs.python.org  Fri Feb  1 16:52:13 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Feb 2008 15:52:13 -0000
Subject: [issue1974] email.MIMEText.MIMEText.as_string incorrectly folding
	long subject header
In-Reply-To: <1201704485.29.0.575687789495.issue1974@psf.upfronthosting.co.za>
Message-ID: <1201881133.71.0.0273647537117.issue1974@psf.upfronthosting.co.za>


Changes by Guido van Rossum:


----------
assignee:  -> barry
nosy: +barry

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1974>
__________________________________

From report at bugs.python.org  Fri Feb  1 16:58:21 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Feb 2008 15:58:21 -0000
Subject: [issue1975] signals in thread problem
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1201881501.19.0.796486782079.issue1975@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Actually I see the same behavior under Linux and OSX: the first ^C
interrupts the select() call, after that ^C is ignored.

----------
nosy: +gvanrossum

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
__________________________________

From report at bugs.python.org  Fri Feb  1 17:00:25 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Feb 2008 16:00:25 -0000
Subject: [issue1978] Python(2.5.1) will be crashed when i use _ssl module in
	multi-threads environment in linux.
In-Reply-To: <1201733914.21.0.052632860787.issue1978@psf.upfronthosting.co.za>
Message-ID: <1201881625.06.0.462120148755.issue1978@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think it's worth applying this to 2.5.2 even if the patch is dead
after that.  More unittests are definitely in order.

----------
nosy: +gvanrossum
priority: low -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1978>
__________________________________

From report at bugs.python.org  Fri Feb  1 17:04:22 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Feb 2008 16:04:22 -0000
Subject: [issue1981] operator "is"
In-Reply-To: <1201796222.53.0.881330735735.issue1981@psf.upfronthosting.co.za>
Message-ID: <1201881862.6.0.648417336391.issue1981@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

id(a.__abs__) == id(a.__abs__)

has a completely different explanation -- it so happens that the first
instantiation of a.__abs__ is freed after id() is called on it and the
second instantiation happens to reuse that same memory block.

----------
nosy: +gvanrossum

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1981>
__________________________________

From report at bugs.python.org  Fri Feb  1 17:06:53 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Feb 2008 16:06:53 -0000
Subject: [issue1985] Bug/Patch: Problem with xml/__init__.py when using
	freeze.py
In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
Message-ID: <1201882013.98.0.769554853723.issue1985@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I think nobody really cares about freeze any more -- it isn't maintained.

----------
nosy: +gvanrossum
priority:  -> low

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1985>
__________________________________

From report at bugs.python.org  Fri Feb  1 17:32:09 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 01 Feb 2008 16:32:09 -0000
Subject: [issue974019] ConfigParser non-string defaults broken with
	.getboolean()
Message-ID: <1201883529.27.0.612872601205.issue974019@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

With the latest python, get() itself fails with boolean value default. I
tried with this script:

-------------
from ConfigParser import ConfigParser
cfg = ConfigParser({'var':True})
cfg.add_section('test_section')
print cfg.getboolean('test_section', 'var')
-------------

and it results in

-------------
Traceback (most recent call last):
  File "t.py", line 4, in <module>
    print cfg.getboolean('test_section', 'var')
  File "/localhome/raghu/localwork/cpython/trunk/Lib/ConfigParser.py",
line 349, in getboolean
    v = self.get(section, option)
  File "/localhome/raghu/localwork/cpython/trunk/Lib/ConfigParser.py",
line 545, in get
    return self._interpolate(section, option, value, d)
  File "/localhome/raghu/localwork/cpython/trunk/Lib/ConfigParser.py",
line 585, in _interpolate
    if "%(" in value:
TypeError: argument of type 'bool' is not iterable
-------------

I doubt if it is worth fixing the OP's issue considering that
_interpolate is assuming the value to be string. Can I close this issue?

----------
components: +Library (Lib) -None
versions: +Python 2.6

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue974019>
____________________________________

From report at bugs.python.org  Fri Feb  1 17:32:22 2008
From: report at bugs.python.org (Ryan Stutsman)
Date: Fri, 01 Feb 2008 16:32:22 -0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201810048.1.0.476779148094.issue1983@psf.upfronthosting.co.za>
Message-ID: <1201883542.73.0.06508514214.issue1983@psf.upfronthosting.co.za>


Ryan Stutsman added the comment:

Actually the current trunk of as of this morning (60484) is still broken
in a couple of ways.  First, converting the pid_t using PyInt is a
problem  and second the waitpids aren't corrected.  This would cause
waits on invalid pids.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________

From report at bugs.python.org  Fri Feb  1 17:54:47 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 01 Feb 2008 16:54:47 -0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <1201883542.73.0.06508514214.issue1983@psf.upfronthosting.co.za>
Message-ID: <47A34ED5.2010100@cheimes.de>


Christian Heimes added the comment:

Ryan Stutsman wrote:
> Actually the current trunk of as of this morning (60484) is still broken
> in a couple of ways.  First, converting the pid_t using PyInt is a
> problem  and second the waitpids aren't corrected.  This would cause
> waits on invalid pids.

I'll see what I kind do about it.

Christian

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________

From report at bugs.python.org  Fri Feb  1 18:38:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Feb 2008 17:38:02 -0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1201887482.96.0.0909153530021.issue1692335@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I'm against including this in 2.5.2. It reeks of a new feature, and the
code looks like it would risk breaking other apps.

(I'm fine with adding this to 2.6 of course.)

----------
nosy: +gvanrossum

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_____________________________________

From report at bugs.python.org  Fri Feb  1 18:53:35 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 01 Feb 2008 17:53:35 -0000
Subject: [issue1090076] Defaults in ConfigParser.get overrides section values
Message-ID: <1201888415.2.0.031226527096.issue1090076@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

The following two statements from ConfigParser document clearly mention
that what is passed in 'vars' are defaults and defaults come into
picture only when values are not explicitly set.

"Default values can be specified by passing them into the ConfigParser
constructor as a dictionary. Additional defaults may be passed into the
get() method which will override all others."

"ConfigParser.get(section, option[, raw[, vars]])?
    Get an option value for the named section. All the '%'
interpolations are expanded in the return values, based on the defaults
passed into the constructor, as well as the options vars provided,
unless the raw argument is true."

If we can not change the behaviour (as it will break existing code), we
should explicitly document this fact. Basically, get() looks for options
in the following order:

1) in 'vars'.
2) in the actual section
3) in default section

----------
nosy: +draghuram

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1090076>
_____________________________________

From report at bugs.python.org  Fri Feb  1 18:54:36 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 01 Feb 2008 17:54:36 -0000
Subject: [issue1090076] Defaults in ConfigParser.get overrides section values
Message-ID: <1201888476.32.0.76844790253.issue1090076@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda:


----------
components: +Documentation -Library (Lib)
versions: +Python 2.6 -Python 2.3

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1090076>
_____________________________________

From report at bugs.python.org  Fri Feb  1 19:04:26 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 01 Feb 2008 18:04:26 -0000
Subject: [issue1976] pybsddb leak in using cursors
In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za>
Message-ID: <1201889066.13.0.75937803378.issue1976@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

yes i'll take a look at this weekend.

jcea is doing his bsddb development in the pybsddb.sf.net project svn
repository for the time being.  I'll be merging his changes back into
the python tree.

We can get him python svn access soon but i wanted to make sure things
were going smoothly first.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1976>
__________________________________

From report at bugs.python.org  Fri Feb  1 19:13:48 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2008 18:13:48 -0000
Subject: [issue1995] localeconv() does not encode returned strings
In-Reply-To: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za>
Message-ID: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za>


New submission from Antoine Pitrou:

Some values in the dict returned by localeconv() may be non-ASCII
strings, yet they are not decoded according to the locale's character
set. This can be observed when the currency symbol is the euro sign:

>>> import locale
>>> locale.setlocale(locale.LC_MONETARY, 'fr_FR.UTF-8')
'fr_FR.UTF-8'
>>> locale.localeconv()['currency_symbol']
'\xe2\x82\xac'
>>> locale.setlocale(locale.LC_MONETARY, 'fr_FR.ISO8859-15')
'fr_FR.ISO8859-15'
>>> locale.localeconv()['currency_symbol']
'\xa4'

localeconv() is defined in the _locale module, which has no knowledge of
the current encoding - but the locale module does. So we could redefine
localeconv() in locale as a wrapper, to do the proper encoding dance.

----------
components: Extension Modules
messages: 61970
nosy: pitrou
severity: normal
status: open
title: localeconv() does not encode returned strings
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1995>
__________________________________

From report at bugs.python.org  Fri Feb  1 19:50:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2008 18:50:33 -0000
Subject: [issue1995] localeconv() does not encode returned strings
In-Reply-To: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za>
Message-ID: <1201891833.33.0.757920374987.issue1995@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is a patch fixing the problem. Note however that it will make
localeconv() quite slower. Perhaps _locale.localeconv should grow an
encoding parameter instead.

Added file: http://bugs.python.org/file9343/pylocaleconv.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1995>
__________________________________

From report at bugs.python.org  Fri Feb  1 20:18:33 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 01 Feb 2008 19:18:33 -0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <47A2A871.7020205@v.loewis.de>
Message-ID: <47A3707B.4050608@cheimes.de>


Christian Heimes added the comment:

Martin v. L?wis wrote:
> If so, Python would now fail to compile under that
> patch. Backporting a change that causes Python to fail
> to compile on some systems is not a good idea.

I added the size comparison to identify systems with sizeof(pid_t) >
sizeof(long).

> If that aspect was fixed also (e.g. by always returning
> long ints on systems where sizeof(pid_t)>sizeof(long)),
> a backport would be ok. For a perfect backport, that
> change might still cause a behavior change:  on
> a system where sizeof(pid_t)>sizeof(long), yet the
> system only ever uses pid_t values < INT_MAX, people
> would see that the fork return type changes unreasonably;
> a perfect backport would only return longs if the values
> are out of range. This is probably over-cautious, as
> it's fairly unlikely that such systems actually exist.

Your proposal looks sound and good to me, but it involves some work. The
chance would require a new format operator 'p' for argument parsing and
new functions like PyInt_FromPid_t() and PyInt_AsPid_t().

In r60504 I've changed the type for the remaining functions like waitpit
 and getsid to pid_t. It should make it easy to spot the lines that have
to be changed.

Christian

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________

From report at bugs.python.org  Fri Feb  1 20:32:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Feb 2008 19:32:40 -0000
Subject: [issue1995] localeconv() does not encode returned strings
In-Reply-To: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za>
Message-ID: <1201894360.73.0.530731196264.issue1995@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The locale module is completely broken; don't try to work around that
breakage. One option would be to remove it entirely.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1995>
__________________________________

From report at bugs.python.org  Fri Feb  1 20:39:57 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 01 Feb 2008 19:39:57 -0000
Subject: [issue1983] Return from fork() is pid_t, not int
In-Reply-To: <47A3707B.4050608@cheimes.de>
Message-ID: <47A3758A.5040805@v.loewis.de>


Martin v. L?wis added the comment:

> Your proposal looks sound and good to me, but it involves some work. The
> chance would require a new format operator 'p' for argument parsing and
> new functions like PyInt_FromPid_t() and PyInt_AsPid_t().

No, it doesn't require that. You could use conditional compilation
throughout to achieve this, and the function might be more list
int_from_pid_t (i.e. static).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1983>
__________________________________

From report at bugs.python.org  Fri Feb  1 20:45:02 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2008 19:45:02 -0000
Subject: [issue1996] float.as_integer_ratio() needs to return fraction in
	lowest terms
In-Reply-To: <1201895102.84.0.505025801473.issue1996@psf.upfronthosting.co.za>
Message-ID: <1201895102.84.0.505025801473.issue1996@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Just before the sign bit is restored, add code with the following effect:

    while not top&1:
        top >>= 1
        e += 1

Tests: 
  math.pi --> (884279719003555, 281474976710656)
  7.5 --> (15, 2)
  0.875 --> (7, 8)

----------
files: tmp_float_conv.py
messages: 61975
nosy: rhettinger
severity: normal
status: open
title: float.as_integer_ratio() needs to return fraction in lowest terms
Added file: http://bugs.python.org/file9344/tmp_float_conv.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1996>
__________________________________

From report at bugs.python.org  Fri Feb  1 20:45:53 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2008 19:45:53 -0000
Subject: [issue1996] float.as_integer_ratio() needs to return fraction in
	lowest terms
In-Reply-To: <1201895102.84.0.505025801473.issue1996@psf.upfronthosting.co.za>
Message-ID: <1201895153.63.0.664900279201.issue1996@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


----------
assignee:  -> jyasskin
components: +Interpreter Core
nosy: +jyasskin
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1996>
__________________________________

From report at bugs.python.org  Fri Feb  1 22:18:45 2008
From: report at bugs.python.org (Aaron Watters)
Date: Fri, 01 Feb 2008 21:18:45 -0000
Subject: [issue1997] unicode and string compare should not cause an exception
In-Reply-To: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>
Message-ID: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>


New submission from Aaron Watters:

As I understand it comparisons between two objects should
always work.  I get this at the interpreter prompt:

Python 2.6a0 (trunk, Jan 11 2008, 11:40:59) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-8)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> unichr(0xffff) < chr(128)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeDecodeError: 'ascii' codec can't decode byte 0x80 in position 0:
ordinal not in range(128)
>>> 

I think the fix for this case is to do something
arbitrary but consistent if possible?

----------
components: Interpreter Core
messages: 61976
nosy: aaron_watters
severity: normal
status: open
title: unicode and string compare should not cause an exception
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1997>
__________________________________

From report at bugs.python.org  Fri Feb  1 22:18:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Fri, 01 Feb 2008 21:18:53 -0000
Subject: [issue1995] localeconv() does not encode returned strings
In-Reply-To: <1201889628.47.0.925128224389.issue1995@psf.upfronthosting.co.za>
Message-ID: <1201900733.41.0.186420604817.issue1995@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Perhaps it is broken - it does look rather fragile - but are there any
plans to design a replacement?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1995>
__________________________________

From report at bugs.python.org  Fri Feb  1 22:31:00 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 01 Feb 2008 21:31:00 -0000
Subject: [issue1996] float.as_integer_ratio() needs to return fraction in
	lowest terms
In-Reply-To: <1201895102.84.0.505025801473.issue1996@psf.upfronthosting.co.za>
Message-ID: <1201901460.61.0.759651476776.issue1996@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Fixed in revision 60511.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1996>
__________________________________

From report at bugs.python.org  Fri Feb  1 22:38:13 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 01 Feb 2008 21:38:13 -0000
Subject: [issue1997] unicode and string compare should not cause an exception
In-Reply-To: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>
Message-ID: <1201901893.47.0.87003224441.issue1997@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

The change we did was for == and != comparisons to always work (they now
"raise" warnings) - mostly because doing otherwise resulted in strange
exceptions when dealing with dictionary lookups. 

However, this was not done for comparisons <, <=, >=, > since these test
for ordering and it's not at all clear what the default outcome should be.

>>> u'abc' == '???'
UnicodeWarning: Unicode equal comparison failed to convert both
arguments to Unicode - interpreting them as being unequal
False

>>> u'abc' < '???'
UnicodeDecodeError: 'ascii' codec can't decode byte 0xe4 in position 0:
ordinal not in range(128)

>>> 1 < 1j
TypeError: no ordering relation is defined for complex numbers

----------
nosy: +lemburg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1997>
__________________________________

From report at bugs.python.org  Fri Feb  1 23:22:18 2008
From: report at bugs.python.org (Malte Helmert)
Date: Fri, 01 Feb 2008 22:22:18 -0000
Subject: [issue1433694] normalize function in minidom unlinks empty child nodes
Message-ID: <1201904538.61.0.377160707797.issue1433694@psf.upfronthosting.co.za>


Malte Helmert added the comment:

I can reproduce the bug on trunk (r60511). At first I thought the
behaviour might be caused by the testcase removing items from the
children list while iterating over it, but this is not the case; the
exception is raised upon the first removal already.

Here is a shorter testcase:
========================================
from xml.dom import minidom

def testme(xmltext):
    node = minidom.parseString(xmltext).documentElement
    for child in node.childNodes:
        if child.nodeValue == "t":
            child.nodeValue = ""
    node.normalize()

    child = node.firstChild
    while child:
        next = child.nextSibling
        if child.nodeType == child.TEXT_NODE and child.nodeValue == "":
            node.removeChild(child)
        child = next
    return node

print testme("<o><i/>tt</o>").toxml()
print testme("<o><i/>t</o>").toxml()
========================================

The second call to testme fails with an xml.dom.NotFoundErr, but it
should succeed and print "<o><i/></o>".


While this appears to be a genuine bug, I don't agree with the proposed
fix. I'm not sure if calling removeChild (which mutates self.childNodes)
from within normalize (which iterates over self.childNodes at that time)
is safe, and even if it is, it would make normalize O(N^2) (not taking
into account recursion) where it should be O(N).

----------
nosy: +maltehelmert

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1433694>
_____________________________________

From report at bugs.python.org  Fri Feb  1 23:35:19 2008
From: report at bugs.python.org (Malte Helmert)
Date: Fri, 01 Feb 2008 22:35:19 -0000
Subject: [issue1433694] normalize function in minidom unlinks empty child nodes
Message-ID: <1201905319.9.0.91998157566.issue1433694@psf.upfronthosting.co.za>


Malte Helmert added the comment:

OK, I think I found the root cause. Node.normalize regenerates the list
of children L with their previousSibling/nextSibling references from
scratch; however, it fails to set the nextSibling reference for the very
last element of L to None at the end. This is necessary iff the last
node in the original child list is removed. The attached patch should
solve the problem.

In cases like this, should I also add a regression test?

Added file: http://bugs.python.org/file9345/MINIDOM-PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1433694>
_____________________________________

From report at bugs.python.org  Fri Feb  1 23:37:31 2008
From: report at bugs.python.org (Malte Helmert)
Date: Fri, 01 Feb 2008 22:37:31 -0000
Subject: [issue1433694] normalize function in minidom unlinks empty child nodes
Message-ID: <1201905451.1.0.843186145217.issue1433694@psf.upfronthosting.co.za>


Changes by Malte Helmert:


----------
versions: +Python 2.6 -Python 2.4

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1433694>
_____________________________________

From report at bugs.python.org  Fri Feb  1 23:46:13 2008
From: report at bugs.python.org (Malte Helmert)
Date: Fri, 01 Feb 2008 22:46:13 -0000
Subject: [issue1433694] normalize function in minidom unlinks empty child nodes
Message-ID: <1201905973.75.0.91672382171.issue1433694@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Here is a minimal testcase to more clearly expose the root of the
problem, in case a regression test is needed. Without the patch, the
assertion fails.

==========================================================
from xml.dom import minidom
node = minidom.parseString("<o><i/>t</o>").documentElement
node.childNodes[1].nodeValue = ""
node.normalize()
assert node.childNodes[-1].nextSibling == None
==========================================================

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1433694>
_____________________________________

From report at bugs.python.org  Sat Feb  2 00:47:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 01 Feb 2008 23:47:20 -0000
Subject: [issue1997] unicode and string compare should not cause an exception
In-Reply-To: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>
Message-ID: <1201909640.64.0.90739443005.issue1997@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

> As I understand it comparisons between two objects should
> always work.

Hi Aaron!  Glad to see you're back.

It used to be that way when you & Jim wrote the first Python book. :-)

Nowadays, comparisons *can* raise exceptions.  Marc-Andre has explained
why.  In 3.0, this particular issue will go away due to a different
treatment of Unicode, but many more cases will raise TypeError when < is
used.  == and != will generally work, though there are no absolute
guarantees.

----------
nosy: +gvanrossum
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1997>
__________________________________

From report at bugs.python.org  Sat Feb  2 01:14:59 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 02 Feb 2008 00:14:59 -0000
Subject: [issue1985] Bug/Patch: Problem with xml/__init__.py when using
	freeze.py
In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
Message-ID: <1201911299.21.0.830678461975.issue1985@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Should freeze be removed if it's no longer maintained? Freeze is partly
used by py2exe and py2app. Maybe the maintainers of the apps can step in
and maintain the parts of the freeze api they require. The rest could
then be deprecated for Python 2.6 and removed from 3.0.

----------
nosy: +tiran
versions: +Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1985>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:02:07 2008
From: report at bugs.python.org (Mick Charles Beaver)
Date: Sat, 02 Feb 2008 01:02:07 -0000
Subject: [issue1998] documentation grammatical error
In-Reply-To: <1201914127.03.0.970500113974.issue1998@psf.upfronthosting.co.za>
Message-ID: <1201914127.03.0.970500113974.issue1998@psf.upfronthosting.co.za>


New submission from Mick Charles Beaver:

On page:
http://docs.python.org/lib/sqlite3-Module-Contents.html

The following:
If you want to use other types, like you have to add support for them
yourself.

Should be:
If you want to use other types, you'll have to add support for them
yourself.

----------
components: Documentation
messages: 61985
nosy: mickbeaver
severity: minor
status: open
title: documentation grammatical error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1998>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:06:00 2008
From: report at bugs.python.org (Mick Charles Beaver)
Date: Sat, 02 Feb 2008 01:06:00 -0000
Subject: [issue1999] wrong tracker
In-Reply-To: <1201914360.49.0.525669196275.issue1999@psf.upfronthosting.co.za>
Message-ID: <1201914360.49.0.525669196275.issue1999@psf.upfronthosting.co.za>


New submission from Mick Charles Beaver:

When I found a small mistake in the documentation, I went to the
following URL, which in turn sent me to SourceForge, which then sent me
to the Roundup bug database.

http://docs.python.org/lib/about.html

----------
components: Documentation
messages: 61986
nosy: mickbeaver
severity: urgent
status: open
title: wrong tracker
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1999>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:08:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 02 Feb 2008 01:08:28 -0000
Subject: [issue1995] localeconv() does not encode returned strings
In-Reply-To: <1201900733.41.0.186420604817.issue1995@psf.upfronthosting.co.za>
Message-ID: <47A3C289.5030805@v.loewis.de>


Martin v. L?wis added the comment:

> Perhaps it is broken - it does look rather fragile - but are there any
> plans to design a replacement?

If people could contribute an ICU wrapper - that would be nice. However,
it's unlikely to happen. So I'll rather rewrite _locale to use wchar_t
functions, and give up on systems where these are not available, or
where wchar_t is not Unicode (not sure how to detect the latter case).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1995>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:11:06 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 02 Feb 2008 01:11:06 -0000
Subject: [issue1998] documentation grammatical error
In-Reply-To: <1201914127.03.0.970500113974.issue1998@psf.upfronthosting.co.za>
Message-ID: <1201914666.27.0.848601674156.issue1998@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> georg.brandl
keywords: +easy
nosy: +georg.brandl
priority:  -> low
type:  -> rfe
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1998>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:11:51 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 02 Feb 2008 01:11:51 -0000
Subject: [issue1999] wrong tracker
In-Reply-To: <1201914360.49.0.525669196275.issue1999@psf.upfronthosting.co.za>
Message-ID: <1201914711.58.0.545123008599.issue1999@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl
priority:  -> normal
type:  -> rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1999>
__________________________________

From report at bugs.python.org  Sat Feb  2 02:39:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 02 Feb 2008 01:39:27 -0000
Subject: [issue1999] wrong tracker
In-Reply-To: <1201914360.49.0.525669196275.issue1999@psf.upfronthosting.co.za>
Message-ID: <1201916367.69.0.632826991378.issue1999@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

This is a duplicate of issue 1462.

----------
nosy: +loewis
resolution:  -> duplicate
status: open -> closed
superseder:  -> About this document refers to SourceForge tracker

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1999>
__________________________________

From report at bugs.python.org  Sat Feb  2 03:05:25 2008
From: report at bugs.python.org (Bill Janssen)
Date: Sat, 02 Feb 2008 02:05:25 -0000
Subject: [issue1978] Python(2.5.1) will be crashed when i use _ssl module in
	multi-threads environment in linux.
In-Reply-To: <1201881625.06.0.462120148755.issue1978@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0802011805t30767ev944d833542b6c473@mail.gmail.com>


Bill Janssen added the comment:

OK, I'll read it more carefully and compare it to the 2.6 version of the
code.

Bill

On Feb 1, 2008 8:00 AM, Guido van Rossum <report at bugs.python.org> wrote:

>
> Guido van Rossum added the comment:
>
> I think it's worth applying this to 2.5.2 even if the patch is dead
> after that.  More unittests are definitely in order.
>
> ----------
> nosy: +gvanrossum
> priority: low -> normal
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1978>
> __________________________________
>

Added file: http://bugs.python.org/file9346/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1978>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080202/65ca4952/attachment.txt 

From report at bugs.python.org  Sat Feb  2 02:45:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 02 Feb 2008 01:45:16 -0000
Subject: [issue1985] Bug/Patch: Problem with xml/__init__.py when using
	freeze.py
In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
Message-ID: <1201916716.66.0.997743539408.issue1985@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Why don't you ask that question on python-dev? Maybe someone volunteers!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1985>
__________________________________

From report at bugs.python.org  Sat Feb  2 03:33:09 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Feb 2008 02:33:09 -0000
Subject: [issue1514428] NaN comparison in Decimal broken
Message-ID: <1201919589.84.0.244051696359.issue1514428@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

See issue #1979 for a possible fix.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1514428>
_____________________________________

From report at bugs.python.org  Sat Feb  2 06:07:37 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 02 Feb 2008 05:07:37 -0000
Subject: [issue1965] Move trunc() to math module
In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za>
Message-ID: <1201928857.56.0.0300678464135.issue1965@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Go ahead and fix the docstring. I don't really understand what was
incorrect about the original "returns the integral closest to x between
0 and x", so I'm not confident that I'll come up with something you'll like.

----------
assignee: jyasskin -> rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1965>
__________________________________

From report at bugs.python.org  Sat Feb  2 06:30:48 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2008 05:30:48 -0000
Subject: [issue1965] Move trunc() to math module
In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za>
Message-ID: <1201930248.83.0.879477134114.issue1965@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The latest version in Py2.6 has wording about truncating toward zero.  
This is fine.  Leaving the report closed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1965>
__________________________________

From report at bugs.python.org  Sat Feb  2 07:00:25 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 02 Feb 2008 06:00:25 -0000
Subject: [issue1965] Move trunc() to math module
In-Reply-To: <1201631207.75.0.681828749767.issue1965@psf.upfronthosting.co.za>
Message-ID: <1201932025.77.0.881743428697.issue1965@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

*sigh* That's the version I put there. Did you read the patch before
complaining about it?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1965>
__________________________________

From report at bugs.python.org  Sat Feb  2 08:24:53 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 02 Feb 2008 07:24:53 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1201937093.13.0.53343598459.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Whoops, sorry for taking a while to answer. +0 on adding support for
'2.' and '.3', given that they're allowed for float and Decimal. Not +1
because they'll make the regular expression more complicated, and
they're not exactly necessary, but if you want to add them, go ahead.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  2 08:39:48 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Feb 2008 07:39:48 -0000
Subject: [issue1998] documentation grammatical error
In-Reply-To: <1201914127.03.0.970500113974.issue1998@psf.upfronthosting.co.za>
Message-ID: <1201937988.22.0.0357695117798.issue1998@psf.upfronthosting.co.za>


Georg Brandl added the comment:

This seems already fixed in SVN.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1998>
__________________________________

From report at bugs.python.org  Sat Feb  2 09:07:24 2008
From: report at bugs.python.org (Jaroslav Pachola)
Date: Sat, 02 Feb 2008 08:07:24 -0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1201939643.94.0.448731387865.issue1692335@psf.upfronthosting.co.za>


Jaroslav Pachola added the comment:

To me it seems more like a bug fix - in Python 2.4 and older the
pickling works well and the current 2.5 behavior really breaks existing
code. That's why I plead for inclusion in 2.5.2; because this issue
prevents our company to move to 2.5.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_____________________________________

From report at bugs.python.org  Sat Feb  2 11:18:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Feb 2008 10:18:53 -0000
Subject: [issue1935] test_descr.py converted to unittest
In-Reply-To: <1201303696.01.0.217856610117.issue1935@psf.upfronthosting.co.za>
Message-ID: <1201947533.82.0.834890137557.issue1935@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The GHOP patch was now committed as r60521.

----------
nosy: +georg.brandl
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1935>
__________________________________

From report at bugs.python.org  Sat Feb  2 12:36:57 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 02 Feb 2008 11:36:57 -0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1201952217.83.0.759875856052.issue1692335@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Understood.  Can you get other developers on python-dev to weigh in? 
Maybe I am over-estimating the danger.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_____________________________________

From report at bugs.python.org  Sat Feb  2 14:19:00 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Feb 2008 13:19:00 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1201958340.92.0.198876818953.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

About Rational('3.') and Rational('.2'):

It's not so much to do with consistency with float and Decimal;  more to do 
with the fact that some people like to write floats these ways (which 
presumably is why float and Decimal allow such input).

It occurs to me that if you also allow things like Rational('1e+100') then 
conversions from Decimal to Rational could simply be spelled

Rational(str(decimal_instance))

eliminating the need for the special Decimal -> Rational conversion method.

Anyway, I'll change the regex to allow '3.' and '.3'.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  2 16:00:54 2008
From: report at bugs.python.org (Aaron Watters)
Date: Sat, 02 Feb 2008 15:00:54 -0000
Subject: [issue1997] unicode and string compare should not cause an exception
In-Reply-To: <1201909640.64.0.90739443005.issue1997@psf.upfronthosting.co.za>
Message-ID: <fc13a6500802020700o4a845b9fq3346854066036fc1@mail.gmail.com>


Aaron Watters added the comment:

Okay.  I haven't looked but this should be well documented
somewhere because I found it very surprising (it crashed a large
run somewhere in the middle).

In the case of strings versus unicode I think it is possible
to hack around this by catching the exceptional case and
comparing character by character -- treating out of band
characters as larger than all unicode characters.  I don't
see why this would cause any problems at any rate.

   -- Aaron Watters

On Feb 1, 2008 6:47 PM, Guido van Rossum <report at bugs.python.org> wrote:

>
> Guido van Rossum added the comment:
>
> > As I understand it comparisons between two objects should
> > always work.
>
> Hi Aaron!  Glad to see you're back.
>
> It used to be that way when you & Jim wrote the first Python book. :-)
>
> Nowadays, comparisons *can* raise exceptions.  Marc-Andre has explained
> why.  In 3.0, this particular issue will go away due to a different
> treatment of Unicode, but many more cases will raise TypeError when < is
> used.  == and != will generally work, though there are no absolute
> guarantees.
>
> ----------
> nosy: +gvanrossum
> resolution:  -> rejected
> status: open -> closed
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1997>
> __________________________________
>

Added file: http://bugs.python.org/file9348/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1997>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080202/284eeb3c/attachment.txt 

From report at bugs.python.org  Sat Feb  2 16:35:35 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Sat, 02 Feb 2008 15:35:35 -0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1201966535.08.0.951669169114.issue1757072@psf.upfronthosting.co.za>


Alan McIntyre added the comment:

It would seem that such a zip file is not consistent with the spec
(http://www.pkware.com/documents/casestudies/APPNOTE.TXT).  My first
reaction is that we shouldn't accept behavior outside the spec unless
it's something that's done by many popular ZIP applications.  However,
if somebody can convince me that this is a deviation from the spec that
we should support, I'll write a patch for it. :)

----------
nosy: +alanmcintyre

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_____________________________________

From report at bugs.python.org  Sat Feb  2 17:09:24 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 02 Feb 2008 16:09:24 -0000
Subject: [issue1997] unicode and string compare should not cause an exception
In-Reply-To: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>
Message-ID: <1201968564.64.0.61341718497.issue1997@psf.upfronthosting.co.za>


Changes by Guido van Rossum:


Removed file: http://bugs.python.org/file9348/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1997>
__________________________________

From report at bugs.python.org  Sat Feb  2 17:11:50 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 02 Feb 2008 16:11:50 -0000
Subject: [issue1997] unicode and string compare should not cause an exception
In-Reply-To: <1201900725.55.0.777594723625.issue1997@psf.upfronthosting.co.za>
Message-ID: <1201968710.53.0.793801364721.issue1997@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

You should be grateful. :-)

The error points out a bug in your program: you're mixing encoded and
unencoded text.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1997>
__________________________________

From report at bugs.python.org  Sat Feb  2 18:22:48 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Feb 2008 17:22:48 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1201972968.79.0.694564186516.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Regex changed in r60530.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  2 19:19:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 02 Feb 2008 18:19:38 -0000
Subject: [issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
In-Reply-To: <1201976378.64.0.881380024504.issue2000@psf.upfronthosting.co.za>
Message-ID: <1201976378.64.0.881380024504.issue2000@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

On Mac OS X, make fails with the following error
..
/usr/bin/ld: Undefined symbols:
_PyOS_mystrnicmp
collect2: ld returned 1 exit status
make: *** [python.exe] Error 1

The attached patch fixes the issue.

----------
components: Build
files: make-patch.diff
messages: 62006
nosy: belopolsky
severity: normal
status: open
title: Undefined symbols: _PyOS_mystrnicmp on Mac OS X
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file9349/make-patch.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2000>
__________________________________

From report at bugs.python.org  Sat Feb  2 20:10:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 02 Feb 2008 19:10:17 -0000
Subject: [issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
In-Reply-To: <1201976378.64.0.881380024504.issue2000@psf.upfronthosting.co.za>
Message-ID: <1201979417.0.0.116651318039.issue2000@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I assume this is on OS X 10.4?  I can't reproduce the failure on Leopard.

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2000>
__________________________________

From report at bugs.python.org  Sat Feb  2 20:45:33 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 02 Feb 2008 19:45:33 -0000
Subject: [issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
In-Reply-To: <1201976378.64.0.881380024504.issue2000@psf.upfronthosting.co.za>
Message-ID: <1201981533.88.0.161972270627.issue2000@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Looks like an SVN problem on my end.  I am getting a stale version of the 
makefile.  Please close the issue as invalid.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2000>
__________________________________

From report at bugs.python.org  Sat Feb  2 20:50:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 02 Feb 2008 19:50:07 -0000
Subject: [issue2000] Undefined symbols: _PyOS_mystrnicmp on Mac OS X
In-Reply-To: <1201976378.64.0.881380024504.issue2000@psf.upfronthosting.co.za>
Message-ID: <1201981807.79.0.753847315728.issue2000@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Closing.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2000>
__________________________________

From report at bugs.python.org  Sat Feb  2 21:27:51 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 02 Feb 2008 20:27:51 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1201984071.29.0.482855831888.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I think '1e+100' would constitute feature creep at this point, but
thanks for the suggestion, and the improvement in the readability of the
regex!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  2 22:17:22 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 02 Feb 2008 21:17:22 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1201987042.43.0.205292995935.issue1682@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The rational constructor should accept decimals directly.

Rational(Decimal('3.1')) does not suffer the same representation error 
problems as Rational(float('3.1')).  The conversion from decimal is 
lossless and does not depend on the decimal context.  There is no need 
for a separate constructor.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb  3 00:05:53 2008
From: report at bugs.python.org (Ron Adam)
Date: Sat, 02 Feb 2008 23:05:53 -0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>


New submission from Ron Adam:

This patch removes the gui tk control panel and replaces it with a
navigation bar on the served web pages.

This offers a nicer user experience because one no longer needs to jump
back and forth between windows.

The navbar supports getting specific modules, searching modules, and
returning to the main module index. I believe the file source view is
safer also.

Possible issues...
 
+ Restarting the server without ending it causes an error do to the port
already being used.  I think this is not new.

+ There may be some brakage if other applications depend on the tk
interface, but I don't think any do.  Or at least none that I know of.

+ I haven't tested this on windows.  (It works well on Ubuntu 7.10)

----------
components: Library (Lib)
files: pydocnotk.diff
messages: 62012
nosy: ron_adam
severity: normal
status: open
title: Pydoc interactive browsing enhancement
type: rfe
Added file: http://bugs.python.org/file9350/pydocnotk.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
__________________________________

From report at bugs.python.org  Sun Feb  3 00:34:38 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 02 Feb 2008 23:34:38 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1201995278.56.0.494849791817.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I think Rational should handle all floating types as consistently as
possible, whatever their radix or precision. It's unlikely that people
will convert from them often anyway, especially from Decimal, so the
shorter conversion from Decimal doesn't seem to outweigh the extra
complexity in the constructor's behavior. If I turn out to be wrong
about this, we can revisit it in 3.1.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb  3 00:44:52 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 02 Feb 2008 23:44:52 -0000
Subject: [issue2002] Make int() fall back to trunc()
In-Reply-To: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>
Message-ID: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

Per http://mail.python.org/pipermail/python-dev/2008-January/076564.html.

----------
assignee: jyasskin
messages: 62014
nosy: jyasskin
priority: high
severity: normal
status: open
title: Make int() fall back to trunc()
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Sun Feb  3 01:38:21 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 03 Feb 2008 00:38:21 -0000
Subject: [issue1914] test_plistlib fails
Message-ID: <1201999101.96.0.359568478926.issue1914@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1914>
__________________________________

From report at bugs.python.org  Sun Feb  3 03:33:26 2008
From: report at bugs.python.org (Thane Plummer)
Date: Sun, 03 Feb 2008 02:33:26 -0000
Subject: [issue2003] Incorrect definition of new-style class
In-Reply-To: <1202006006.49.0.160716735552.issue2003@psf.upfronthosting.co.za>
Message-ID: <1202006006.49.0.160716735552.issue2003@psf.upfronthosting.co.za>


New submission from Thane Plummer:

Python Reference Manual section 3.3 (p3 s2) contains the fragment "A 
new-style class neither more nor less than a user-defined type."  A 
well placed 2-letter verb would transform this sad little fragment into 
a delightful, pleasing, and ultimately useful sentence.

----------
components: Documentation
messages: 62015
nosy: thaneplummer
severity: minor
status: open
title: Incorrect definition of new-style class
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2003>
__________________________________

From report at bugs.python.org  Sun Feb  3 04:59:13 2008
From: report at bugs.python.org (Michael Brown)
Date: Sun, 03 Feb 2008 03:59:13 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>


New submission from Michael Brown:

python 2.5.1
tarfile.py line 1516 in extractall() 

sets directories created to world-writeable while extracting which means
an attacker can change/modify files before perms are fixed. Suggest 770
while extracting to fix.

----------
components: Library (Lib)
messages: 62016
nosy: mebrown
severity: major
status: open
title: tarfile extractall() allows local attacker to overwrite files while extracting
type: security
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Sun Feb  3 05:12:44 2008
From: report at bugs.python.org (Michael Brown)
Date: Sun, 03 Feb 2008 04:12:44 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202011964.22.0.485449504996.issue2004@psf.upfronthosting.co.za>


Michael Brown added the comment:

I can confirm that this issue has been addressed in trunk tarfile.py.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Sun Feb  3 06:29:03 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Sun, 03 Feb 2008 05:29:03 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202016543.31.0.533141774394.issue2004@psf.upfronthosting.co.za>


Alan McIntyre added the comment:

I noticed that in the trunk, ZipFile._extract_member, at line 865, still
uses 777 (the default of os.makedirs) to create directories.  I attached
a patch for it.

A quick grep shows that tarfile still uses the default permissions for
os.makedirs and mkdir.  Should these all be changed to 700?

----------
nosy: +alanmcintyre
Added file: http://bugs.python.org/file9351/zipfile-dirperm.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Sun Feb  3 07:40:10 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 03 Feb 2008 06:40:10 -0000
Subject: [issue2002] Make int() fall back to trunc()
In-Reply-To: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>
Message-ID: <1202020810.03.0.624200624776.issue2002@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Here's a patch to implement the fallback for both int and long. I'm
pretty sure that _PyNumber_ConvertIntegralToInt() is in the wrong place.
Where would be a better place for it?

----------
keywords: +patch
nosy: +rhettinger
Added file: http://bugs.python.org/file9352/int_fall_back_to_trunc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Sun Feb  3 08:18:05 2008
From: report at bugs.python.org (Ignacio Vazquez-Abrams)
Date: Sun, 03 Feb 2008 07:18:05 -0000
Subject: [issue1294959] Problems with /usr/lib64 builds.
Message-ID: <1202023085.45.0.131824053783.issue1294959@psf.upfronthosting.co.za>


Changes by Ignacio Vazquez-Abrams:


----------
nosy: +ivazquez

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1294959>
_____________________________________

From report at bugs.python.org  Sun Feb  3 08:57:11 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 03 Feb 2008 07:57:11 -0000
Subject: [issue2002] Make int() fall back to trunc()
In-Reply-To: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>
Message-ID: <1202025431.87.0.450263532237.issue2002@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Guido, are these basically the mechanics you intended?  All calls to 
PyNumber_Int() and PyNumber_Long() attempt the usual path and if those 
would fail, it tries __trunc__ if it exists and coerces the result of 
that call back to an int or long.  

The logic looks basically correct, but I'm not sure what it buys us 
since the returned Integral has to be converted back to an int or long 
anyway.  On the plus side, it does not slow down the common case where 
PyNumber_Int() and PyNumberLong() would ordinarily succeed.  

An alternative to this patch would be to have math.trunc() try to 
return __trunc__() and if it doesn't exist, fallback to __int__.  That 
avoids having arbitrary Integrals forced back into ints/longs, but it 
may not be what you guys were after.

Either way will allow a user to define a __trunc__() method and have 
math.trunc() return an arbitrary Integral, not necessarily and int or 
long.

There is also part of this patch that touches classobject.c but I'm not 
yet sure what the visible effect of that change would be or what the 
change was hoping to accomplish.

----------
assignee: jyasskin -> gvanrossum
nosy: +gvanrossum

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Sun Feb  3 09:01:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 03 Feb 2008 08:01:09 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202025669.71.0.250246767435.issue2004@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Lars, can you take a look?

----------
assignee:  -> lars.gustaebel
nosy: +lars.gustaebel, loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Sun Feb  3 09:17:28 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 03 Feb 2008 08:17:28 -0000
Subject: [issue1976] pybsddb leak in using cursors
In-Reply-To: <1201711707.54.0.724149524607.issue1976@psf.upfronthosting.co.za>
Message-ID: <1202026648.41.0.533280963738.issue1976@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

Fix committed as r60544 in trunk and r60545 in release25-maint.

i assume it'll be merged into py3k in the regular py3k merge sweeps.

----------
resolution:  -> accepted
status: open -> closed
versions: +Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1976>
__________________________________

From report at bugs.python.org  Sun Feb  3 13:29:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 03 Feb 2008 12:29:43 -0000
Subject: [issue2003] Incorrect definition of new-style class
In-Reply-To: <1202006006.49.0.160716735552.issue2003@psf.upfronthosting.co.za>
Message-ID: <1202041783.83.0.984566394609.issue2003@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks for the delightful analysis! Fixed in r60550 :)

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2003>
__________________________________

From report at bugs.python.org  Sun Feb  3 19:12:43 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 03 Feb 2008 18:12:43 -0000
Subject: [issue2002] Make int() fall back to trunc()
In-Reply-To: <1202025431.87.0.450263532237.issue2002@psf.upfronthosting.co.za>
Message-ID: <5d44f72f0802031012h16edeb95ne6740d6dbbbac1f6@mail.gmail.com>


Jeffrey Yasskin added the comment:

> There is also part of this patch that touches classobject.c but I'm not
> yet sure what the visible effect of that change would be or what the
> change was hoping to accomplish.

All classic classes take the (m && m->nb_int) branch, so without the
change to classobject.c, they'd never hit the fallback to __trunc__.
The unfortunate side-effect is that when you call int() or long() on a
classic class without the right methods, you get an AttributeError
complaining about __trunc__ instead of about __int__. Since long()
already mistakenly complained about __int__, I didn't consider this a
showstopper, but it should be possible to fix if you want.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Sun Feb  3 20:04:05 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 03 Feb 2008 19:04:05 -0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1202065445.26.0.925950796715.issue1692335@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I tested exception_pickling_25.diff, and it may break existing code.
In 2.5.1, Exception("Hello,4).__reduce__() gives 
(<type 'exceptions.Exception'>, ('Hello', 4))

With the patch, it gives

TypeError: can't pickle Exception objects

IMO, that is an unacceptable change for a bugfix release.

Aside: please give unique file names to the patches, or remove patches
if you want to replace a previous patch.

----------
nosy: +loewis

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_____________________________________

From report at bugs.python.org  Sun Feb  3 20:58:45 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 03 Feb 2008 19:58:45 -0000
Subject: [issue2005] posixmodule expects sizeof(pid_t/gid_t/uid_t) <=
	sizeof(long)
In-Reply-To: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>
Message-ID: <1202068724.99.0.704404319493.issue2005@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The posix module except that a pid_t, uid_t and gid_t always fit into a
long or can be parsed by "i". On some OSes and combination of 64bit
typess and 32bit long it's an invalid assumption.

The code should use long long where available or at least do some
overflow checks.

See r1983

----------
components: Extension Modules
keywords: easy
messages: 62026
nosy: tiran
priority: normal
severity: normal
status: open
title: posixmodule expects sizeof(pid_t/gid_t/uid_t) <= sizeof(long)
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2005>
__________________________________

From report at bugs.python.org  Sun Feb  3 20:59:26 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 03 Feb 2008 19:59:26 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202068766.81.0.907475657038.issue2004@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
priority:  -> high
versions: +Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Sun Feb  3 21:25:40 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sun, 03 Feb 2008 20:25:40 -0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1202070340.2.0.829505406786.issue2001@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola':


----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
__________________________________

From report at bugs.python.org  Sun Feb  3 22:28:07 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 03 Feb 2008 21:28:07 -0000
Subject: [issue1941] 2.6 stdlib using with statement
In-Reply-To: <1201375289.15.0.528782395183.issue1941@psf.upfronthosting.co.za>
Message-ID: <1202074087.69.0.85499756167.issue1941@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I could break this patch into per-module patches. Then as authors
approved them, they could gradually be committed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1941>
__________________________________

From report at bugs.python.org  Mon Feb  4 00:52:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 03 Feb 2008 23:52:34 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202082754.77.0.637828196497.issue1682@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

FWIW, if Rational(Decimal(...)) is to be accepted, then
Decimal(Rational(...)) should also be accepted, and arguably mixed
binary operations as well (Rational(...) + Decimal(...) etc.).

----------
assignee: gvanrossum -> jyasskin

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Mon Feb  4 01:36:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Feb 2008 00:36:01 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202085360.97.0.794291570643.issue1682@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I would rather drop it than see that mess.

FWIW, there is a difference.  Rational(Decimal(...)) takes place 
without reference to a decimal.Context and is always lossless.  

In contrast, Decimal(Rational(...)) is context sensitive (the division 
is subject to rounding and precision limits) and is typically lossy as 
would be the case with Decimal(Rational(1, 3)) which like most 
rationals cannot be exactly represented in Decimal.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Mon Feb  4 01:41:41 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Feb 2008 00:41:41 -0000
Subject: [issue2002] Make int() fall back to trunc()
In-Reply-To: <1202025431.87.0.450263532237.issue2002@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802031615n5a1ec626m9b1ade4f10c828f6@mail.gmail.com>


Guido van Rossum added the comment:

> Guido, are these basically the mechanics you intended?  All calls to
> PyNumber_Int() and PyNumber_Long() attempt the usual path and if those
> would fail, it tries __trunc__ if it exists and coerces the result of
> that call back to an int or long.

Yes, that's exactly what I suggested.

> The logic looks basically correct, but I'm not sure what it buys us
> since the returned Integral has to be converted back to an int or long
> anyway.

Unless it's already an int or long. I would expect a type that wants
to play along with the ABCs defined in numbers.py will define
__trunc__ and not __int__ (since the latter isn't part of the ABC) but
it would have to be a pretty esoteric type not to return an int or
long.

> On the plus side, it does not slow down the common case where
> PyNumber_Int() and PyNumberLong() would ordinarily succeed.

Great -- so no penalty for builtin types.

> An alternative to this patch would be to have math.trunc() try to
> return __trunc__() and if it doesn't exist, fallback to __int__.  That
> avoids having arbitrary Integrals forced back into ints/longs, but it
> may not be what you guys were after.

Definitely not -- that would imply that math.trunc("42") would return
the integer 42!

> Either way will allow a user to define a __trunc__() method and have
> math.trunc() return an arbitrary Integral, not necessarily and int or
> long.

Correct, and that's as intended.

> There is also part of this patch that touches classobject.c but I'm not
> yet sure what the visible effect of that change would be or what the
> change was hoping to accomplish.

Looks like Jeffrey expained that already.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Mon Feb  4 01:44:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 04 Feb 2008 00:44:01 -0000
Subject: [issue2002] Make int() fall back to trunc()
In-Reply-To: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>
Message-ID: <1202085841.01.0.325122413117.issue2002@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Go for it.

----------
assignee: gvanrossum -> jyasskin
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Mon Feb  4 02:05:29 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 04 Feb 2008 01:05:29 -0000
Subject: [issue2002] Make int() fall back to trunc()
In-Reply-To: <1201995892.7.0.946223486905.issue2002@psf.upfronthosting.co.za>
Message-ID: <1202087129.65.0.379587219718.issue2002@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Submitted as r60566.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2002>
__________________________________

From report at bugs.python.org  Mon Feb  4 06:47:13 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 05:47:13 -0000
Subject: [issue909005] asyncore fixes and improvements
Message-ID: <1202104033.34.0.802187237363.issue909005@psf.upfronthosting.co.za>


Bill Janssen added the comment:

I should point out that I'm doing a big project with SSL and Python,
using Medusa, and asyncore.  I've been re-working the 2.6 and 3.x SSL
support (with guidance from Giampolo :-) so that true async capability
is possible for SSL.

----------
nosy: +janssen

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue909005>
____________________________________

From report at bugs.python.org  Mon Feb  4 06:52:08 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 05:52:08 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>


New submission from Bill Janssen:

I've been reading asyncore lately, and feel that it's showing its age. 
Most loops of this sort (we developed something similar for ILU, about
15 years ago) contain handlers for timers and work tasks, in addition to
input handling.  For timers, typically there's a list of tasks and
times, often with a repeat period.  A system timer is set to the time of
the next task to fire, and the select() loop is exited when it fires. 
The loop handler then looks down the list of timer tasks, and executes
those ready to run.  Similarly, most loops of this sort include a list
of work tasks, and a policy for executing them, such as "take one task
from the front of the list and run it, then do the select".  This allows
background tasks to get run that don't have associated input or output fds.

----------
components: Library (Lib)
messages: 62034
nosy: janssen
severity: normal
status: open
title: asyncore loop lacks timers and work tasks
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Mon Feb  4 06:56:39 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 05:56:39 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202104599.65.0.412694940995.issue2006@psf.upfronthosting.co.za>


Bill Janssen added the comment:

Looks like Giampaolo has already submitted a patch for part of this, in
http://bugs.python.org/issue1641

----------
nosy: +giampaolo.rodola, josiahcarlson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Mon Feb  4 07:31:37 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 04 Feb 2008 06:31:37 -0000
Subject: [issue1953] Compact int and float freelists
In-Reply-To: <1201491269.72.0.799398122167.issue1953@psf.upfronthosting.co.za>
Message-ID: <1202106697.18.0.532340244715.issue1953@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

I think sys is appropriate for clearing the cache.  Lib/test/regrtest.py
still has a reference to gc rather than sys.

Why do the CompactFreeList APIs return an int that is always 0?  Seems
like they should return a real value or be void.

I'm not sure why you changed the functions to keep a block_list_length.
 I doubt this API would be requested very often.  Seems like it would be
better to just calculate when necessary (or perhaps not even add the APIs).

The only issue I have with the patch is the casting in the printf calls.
 These can lose information.  On Win64, long is 32-bits, but size_t is
64-bits.  See PY_FORMAT_SIZE_T in Include/pyport.h for how to handle this.

----------
assignee: nnorwitz -> tiran
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1953>
__________________________________

From report at bugs.python.org  Mon Feb  4 07:37:25 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 04 Feb 2008 06:37:25 -0000
Subject: [issue1750076] Python 2.5+ skips while statements in debuggers
Message-ID: <1202107045.12.0.3475804515.issue1750076@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

I was hoping you could get rid of my entire hack.  I didn't (still
don't) completely understand the intention of the code, so can't really
offer any more advice.  IMO, the patch is an improvement so you should
check it in.

----------
assignee: nnorwitz -> amaury.forgeotdarc
resolution:  -> accepted

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1750076>
_____________________________________

From report at bugs.python.org  Mon Feb  4 10:54:24 2008
From: report at bugs.python.org (Andriy Pylypenko)
Date: Mon, 04 Feb 2008 09:54:24 -0000
Subject: [issue1975] signals in thread problem
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1202118864.17.0.651480637206.issue1975@psf.upfronthosting.co.za>


Andriy Pylypenko added the comment:

I'm sorry I've forgotten to add one important thing to the script - the
t.setDaemon(True) call, as without it the main thread will wait for the
user thread to stop explicitly. So the correct script is:

    some_time = 6000000 # seconds

    class MyThread(Thread):
        def run(self):
            while (True):
                time.sleep(some_time)

    t = MyThread()
    t.setDaemon(True)
    t.start()
    while(True):
        select.select(None, None, None, some_time)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
__________________________________

From report at bugs.python.org  Mon Feb  4 11:51:47 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 04 Feb 2008 10:51:47 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202122307.52.0.901452647064.issue2004@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

This was fixed in the trunk in r53526 about a year ago following
issue1507247. I did not backport it to 2.5 at that time, because it
would have changed existing behaviour. If there are no objections I
could do this now.

The os.mkdir() call in TarFile.makedir() uses the default mode, but the
real mode from the TarInfo object is applied two instructions later in
TarFile._extract_member(). I have nothing against using 0700 in
TarFile.makedir().

The os.makedirs() call in _extract_member() (trunk) is fine. It creates
missing directories that are not part of the archive with default
permissions, that is mode 0777 with the current umask masked out.

I attached a patchset against the release25-maint branch and the trunk
that is supposed to fix the issue and harmonizes the code between the
two versions.

Added file: http://bugs.python.org/file9353/tarfile-diffs.tar.gz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Mon Feb  4 15:57:35 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 04 Feb 2008 14:57:35 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202137055.37.0.767159045287.issue2006@psf.upfronthosting.co.za>


Christian Heimes added the comment:

If you are going to spend some time with async event io you may be
interested in my patch #1657. It adds epoll and kqueue.

----------
nosy: +tiran
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Mon Feb  4 16:11:47 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 04 Feb 2008 15:11:47 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1202137907.96.0.525380881024.issue1657@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola':


----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Mon Feb  4 16:17:56 2008
From: report at bugs.python.org (Chris Mellon)
Date: Mon, 04 Feb 2008 15:17:56 -0000
Subject: [issue1757072] Zipfile robustness
Message-ID: <1202138276.81.0.589831797515.issue1757072@psf.upfronthosting.co.za>


Chris Mellon added the comment:

I agree that the zipfile is out of spec. Here are my arguments in favor
of making the change anyway:

Existing zip tools like 7zip, pkzip, and winzip handle these files "as
expected"

As far as I know, it won't break any valid zipfiles.

Because the fix necessary is buried inside a private function in the
zipfile module, it's difficult to monkey-patch the behavior into place
and it's quite hard to figure out what needs to be done.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1757072>
_____________________________________

From report at bugs.python.org  Mon Feb  4 16:20:46 2008
From: report at bugs.python.org (David Ripton)
Date: Mon, 04 Feb 2008 15:20:46 -0000
Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children
In-Reply-To: <1190316942.33.0.242562253308.issue1183@psf.upfronthosting.co.za>
Message-ID: <1202138446.52.0.635690764849.issue1183@psf.upfronthosting.co.za>


David Ripton added the comment:

Just noticed that this is a partial duplicate of issue 1540386.

----------
versions: +Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1183>
__________________________________

From report at bugs.python.org  Mon Feb  4 16:25:49 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 04 Feb 2008 15:25:49 -0000
Subject: [issue540952] Memory Usage Reporting
Message-ID: <1202138749.91.0.750593027432.issue540952@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

This has evolved into a general discussion without any specific
direction (which is more suitable for a mailing list than in a bug
tracker). So I am closing it. Please do reopen if required.

I don't know what resolution to select for this one. None of the
available choices seem to apply.

----------
nosy: +draghuram
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue540952>
____________________________________

From report at bugs.python.org  Mon Feb  4 17:06:01 2008
From: report at bugs.python.org (Ron Adam)
Date: Mon, 04 Feb 2008 16:06:01 -0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1202141161.63.0.468776169382.issue2001@psf.upfronthosting.co.za>


Changes by Ron Adam:


----------
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
__________________________________

From report at bugs.python.org  Mon Feb  4 17:43:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 04 Feb 2008 16:43:34 -0000
Subject: [issue1975] signals in thread problem
In-Reply-To: <1201711085.9.0.419365608938.issue1975@psf.upfronthosting.co.za>
Message-ID: <1202143414.77.0.402645682036.issue1975@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well okay than I can confirm that OSX is *not* affected by this OS
bugginess.

----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1975>
__________________________________

From report at bugs.python.org  Mon Feb  4 18:27:41 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 04 Feb 2008 17:27:41 -0000
Subject: [issue1090076] Defaults in ConfigParser.get overrides section values
Message-ID: <1202146061.17.0.315980185079.issue1090076@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

The patch "cfgdoc.diff" contains changes to rst as well as to the doc
string. Can some one please review it?

Added file: http://bugs.python.org/file9354/cfgdoc.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1090076>
_____________________________________

From report at bugs.python.org  Mon Feb  4 20:35:53 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 19:35:53 -0000
Subject: [issue2007] cookielib lacks FileCookieJar class for Internet Explorer
In-Reply-To: <1202153753.42.0.88577975251.issue2007@psf.upfronthosting.co.za>
Message-ID: <1202153753.42.0.88577975251.issue2007@psf.upfronthosting.co.za>


New submission from Bill Janssen:

cookielib contains an implementation of FileCookieJar for Mozilla
Firefox, which will work with most of the various Mozilla browsers, but
no implementation for Internet Explorer, standard on Windows and used by
some 80% of computer users.

----------
components: Library (Lib)
messages: 62046
nosy: janssen
severity: normal
status: open
title: cookielib lacks FileCookieJar class for Internet Explorer
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2007>
__________________________________

From report at bugs.python.org  Mon Feb  4 20:37:26 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 19:37:26 -0000
Subject: [issue2008] cookielib lacks FileCookieJar class for Safari
In-Reply-To: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za>
Message-ID: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za>


New submission from Bill Janssen:

cookielib has no FileCookieJar class for Safari, Apple's standard and
default browser for OS X.

----------
components: Library (Lib)
messages: 62047
nosy: janssen
severity: normal
status: open
title: cookielib lacks FileCookieJar class for Safari
type: behavior
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2008>
__________________________________

From report at bugs.python.org  Mon Feb  4 20:38:37 2008
From: report at bugs.python.org (Bill Janssen)
Date: Mon, 04 Feb 2008 19:38:37 -0000
Subject: [issue2008] cookielib lacks FileCookieJar class for Safari
In-Reply-To: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za>
Message-ID: <1202153917.66.0.67632187929.issue2008@psf.upfronthosting.co.za>


Bill Janssen added the comment:

I have code to read Safari cookies, but no code to write them.  I'll
have to look at the FileCookieJar interface.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2008>
__________________________________

From report at bugs.python.org  Mon Feb  4 20:44:49 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 04 Feb 2008 19:44:49 -0000
Subject: [issue1692335] Fix exception pickling: Move initial args assignment
	to BaseException.__new__
Message-ID: <1202154289.26.0.766091860955.issue1692335@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti:


----------
nosy: +alexandre.vassalotti

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1692335>
_____________________________________

From report at bugs.python.org  Mon Feb  4 20:56:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Feb 2008 19:56:05 -0000
Subject: [issue2008] cookielib lacks FileCookieJar class for Safari
In-Reply-To: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za>
Message-ID: <1202154965.43.0.799676468471.issue2008@psf.upfronthosting.co.za>


Changes by Georg Brandl:


----------
type: behavior -> rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2008>
__________________________________

From report at bugs.python.org  Mon Feb  4 20:56:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 04 Feb 2008 19:56:09 -0000
Subject: [issue2007] cookielib lacks FileCookieJar class for Internet Explorer
In-Reply-To: <1202153753.42.0.88577975251.issue2007@psf.upfronthosting.co.za>
Message-ID: <1202154969.28.0.751679860336.issue2007@psf.upfronthosting.co.za>


Changes by Georg Brandl:


----------
type: behavior -> rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2007>
__________________________________

From report at bugs.python.org  Mon Feb  4 21:57:11 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 04 Feb 2008 20:57:11 -0000
Subject: [issue1572320] parser stack overflow
Message-ID: <1202158631.01.0.581198384662.issue1572320@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

this is a duplicate of http://bugs.python.org/issue215555.
Please close.

----------
nosy: +schmir

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1572320>
_____________________________________

From report at bugs.python.org  Mon Feb  4 22:00:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 04 Feb 2008 21:00:58 -0000
Subject: [issue1572320] parser stack overflow
Message-ID: <1202158858.53.0.972868255203.issue1572320@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc:


----------
resolution:  -> duplicate
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1572320>
_____________________________________

From report at bugs.python.org  Mon Feb  4 22:25:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 04 Feb 2008 21:25:52 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202160352.24.0.235855217521.issue2004@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Even though it does change existing behaviour, can anybody imagine a
case where extracting a tarfile now fails when it previously succeeds?

If not, I would consider this a security-relevant fix, and thus a
candidate for a backport. Perhaps this should be raised with
security at python.org.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Mon Feb  4 22:52:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 04 Feb 2008 21:52:20 -0000
Subject: [issue1750076] Python 2.5+ skips while statements in debuggers
Message-ID: <1202161940.63.0.0224853237019.issue1750076@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I finally got rid of the entire hack, by removing the "compression" of
the lnotab: now each (effective) call to compiler_set_lineno() will
generate an entry in lnotab.
The patch is even simpler.
the lnotab will grow a little, but only when several statements are on
the same line: semicolons, and also one-line suites (like "if x: return").

Commited r60575.

----------
status: open -> pending

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1750076>
_____________________________________

From report at bugs.python.org  Mon Feb  4 23:00:33 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 04 Feb 2008 22:00:33 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202162433.7.0.199779813194.issue2006@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I'm not sure to understand what do you mean by "work tasks".
Do you need them to have ssl module work with asyncore?

> I've been reading asyncore lately, and feel that it's showing its age. 

Absolutely. I'd have some ideas about some asyncore/chat enhancements,
including writing a poller suitable with epoll and kqueue, but it seems
there are not enough people who cares enough about asyncore.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Mon Feb  4 23:16:00 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 04 Feb 2008 22:16:00 -0000
Subject: [issue1750076] Python 2.5+ skips while statements in debuggers
Message-ID: <1202163360.4.0.954170817467.issue1750076@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Very nice solution Amaury. As far as I can tell, this should be
backported to 2.5 as well.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1750076>
_____________________________________

From report at bugs.python.org  Mon Feb  4 23:37:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 04 Feb 2008 22:37:03 -0000
Subject: [issue1750076] Python 2.5+ skips while statements in debuggers
Message-ID: <1202164623.35.0.0340290256528.issue1750076@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Committed r60579 in release25-maint.

----------
status: pending -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1750076>
_____________________________________

From report at bugs.python.org  Tue Feb  5 01:19:50 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 05 Feb 2008 00:19:50 -0000
Subject: [issue2009] Grammar change to prevent shift/reduce problem with
	varargslist
In-Reply-To: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>
Message-ID: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>


New submission from Andrew Dalke:

I wrote a translator from the CFG used in the Grammar file into a form for PLY.  I 
found one problem with

varargslist: ((fpdef ['=' test] ',')*
              ('*' NAME [',' '**' NAME] | '**' NAME) |
              fpdef ['=' test] (',' fpdef ['=' test])* [','])

This grammar definition is ambiguous until the presence/lack of a "*".  PLY 
complains:

state 469

    (28) varargslist -> fpdef EQUAL test COMMA .
    (32) varargslist_star -> fpdef EQUAL test COMMA .
    (35) varargslist_star3 -> COMMA . fpdef
    (36) varargslist_star3 -> COMMA . fpdef EQUAL test
    (39) fpdef -> . NAME
    (40) fpdef -> . LPAR fplist RPAR

  ! shift/reduce conflict for NAME resolved as shift.
  ! shift/reduce conflict for LPAR resolved as shift.

    RPAR            reduce using rule 28 (varargslist -> fpdef EQUAL test COMMA .)
    COLON           reduce using rule 28 (varargslist -> fpdef EQUAL test COMMA .)
    STAR            reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA .)
    DOUBLESTAR      reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA .)
    NAME            shift and go to state 165
    LPAR            shift and go to state 163

  ! NAME            [ reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA 
.) ]
  ! LPAR            [ reduce using rule 32 (varargslist_star -> fpdef EQUAL test 
COMMA 
.) ]

    fpdef                          shift and go to state 515



My fix was to use this definition when I did the translation.

varargslist: ((fpdef ['=' test] (',' fpdef ['=' test])* 
                   (',' '*' NAME [',' '**' NAME] | ',' '**' NAME | [','])) |
              ('*' NAME [',' '**' NAME]) |
              ('**' NAME))


So far I've not found a functional difference between these two definitions, and 
the only change to ast.c is to update the comment based on this section.

By making this change it would be easier for the handful of people who write 
parsers for Python based on a yacc-like look-ahead(1) parser to use that file more 
directly.

----------
components: None
messages: 62055
nosy: dalke
severity: minor
status: open
title: Grammar change to prevent shift/reduce problem with varargslist
type: rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2009>
__________________________________

From report at bugs.python.org  Tue Feb  5 01:33:32 2008
From: report at bugs.python.org (Karl Norby)
Date: Tue, 05 Feb 2008 00:33:32 -0000
Subject: [issue2010] Link to howto section on re module documentation incorrect
In-Reply-To: <1202171612.68.0.248444949572.issue2010@psf.upfronthosting.co.za>
Message-ID: <1202171612.68.0.248444949572.issue2010@psf.upfronthosting.co.za>


New submission from Karl Norby:

The link on "http://docs.python.org/lib/re-syntax.html" to the HOWTO
section of documentation redirects incorrectly to
"http://docs.python.org/dev/howto/index.html/". It should be
"http://docs.python.org/dev/howto/" or
"http://docs.python.org/dev/howto/index.html".

----------
components: Documentation
messages: 62056
nosy: knorby
severity: minor
status: open
title: Link to howto section on re module documentation incorrect
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2010>
__________________________________

From report at bugs.python.org  Tue Feb  5 01:46:41 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 05 Feb 2008 00:46:41 -0000
Subject: [issue2011] compiler.parse("1;
	") adds unexpected extra Discard(Const(None)) to parse tree
In-Reply-To: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>
Message-ID: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>


New submission from Andrew Dalke:

Python 2.6a0 (trunk:60565M, Feb  4 2008, 01:21:28) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from compiler import parse
>>> parse("1;")
Module(None, Stmt([Discard(Const(1)), Discard(Const(None))]))

I did not expect the Discard(Const(None)).  Instead, I expected

Module(None, Stmt([Discard(Const(1))]))

----------
components: Library (Lib)
messages: 62057
nosy: dalke
severity: minor
status: open
title: compiler.parse("1;") adds unexpected extra Discard(Const(None)) to parse tree
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2011>
__________________________________

From report at bugs.python.org  Tue Feb  5 02:32:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2008 01:32:31 -0000
Subject: [issue2012] Add migration step for DictMixin ->
	collections.MutableMapping
In-Reply-To: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>
Message-ID: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>


New submission from Christian Heimes:

See r60577

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 62058
nosy: collinwinter, tiran
priority: normal
severity: normal
status: open
title: Add migration step for DictMixin -> collections.MutableMapping
type: rfe
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2012>
__________________________________

From report at bugs.python.org  Tue Feb  5 02:34:37 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2008 01:34:37 -0000
Subject: [issue2009] Grammar change to prevent shift/reduce problem with
	varargslist
In-Reply-To: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>
Message-ID: <1202175277.71.0.408631411545.issue2009@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
components: +Interpreter Core -None
nosy: +ncoghlan, nnorwitz
priority:  -> normal
versions: +Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2009>
__________________________________

From report at bugs.python.org  Tue Feb  5 02:35:07 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2008 01:35:07 -0000
Subject: [issue2010] Link to howto section on re module documentation incorrect
In-Reply-To: <1202171612.68.0.248444949572.issue2010@psf.upfronthosting.co.za>
Message-ID: <1202175307.84.0.0373168051327.issue2010@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl
priority:  -> low
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2010>
__________________________________

From report at bugs.python.org  Tue Feb  5 02:36:21 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2008 01:36:21 -0000
Subject: [issue2011] compiler.parse("1;
	") adds unexpected extra Discard(Const(None)) to parse tree
In-Reply-To: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>
Message-ID: <1202175381.64.0.0895852278804.issue2011@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
components: +Interpreter Core
nosy: +gvanrossum, ncoghlan, nnorwitz
priority:  -> low

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2011>
__________________________________

From report at bugs.python.org  Tue Feb  5 02:46:24 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2008 01:46:24 -0000
Subject: [issue2011] compiler.parse("1;
	") adds unexpected extra Discard(Const(None)) to parse tree
In-Reply-To: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>
Message-ID: <1202175984.02.0.680016686767.issue2011@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

What on earth is this about?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2011>
__________________________________

From report at bugs.python.org  Tue Feb  5 04:07:48 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 05 Feb 2008 03:07:48 -0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch adds a free list of long objects with size 1 or -1. It has
quite a tremendous effect on code like list(range(1000)).

$ ./python -m timeit "for i in range(100): list(range(1000))"

Without patch:
10 loops, best of 3: 79 msec per loop

With patch:
10 loops, best of 3: 20.8 msec per loop

----------
components: Interpreter Core
files: long_freelist.patch
keywords: patch
messages: 62060
nosy: tiran
priority: normal
severity: normal
status: open
title: Long object free list optimization
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9355/long_freelist.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
__________________________________

From report at bugs.python.org  Tue Feb  5 04:21:12 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 05 Feb 2008 03:21:12 -0000
Subject: [issue2011] compiler.parse("1;
	") adds unexpected extra Discard(Const(None)) to parse tree
In-Reply-To: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>
Message-ID: <1202181672.31.0.71879582174.issue2011@psf.upfronthosting.co.za>


Andrew Dalke added the comment:

This really is a minor point.  I don't track the 3K list and I see now that the 
compiler module won't be in Python 3k - good riddance - so feel free to discard 
this as well as the other open compiler module bugs.

I want to experiment with adding instrumentation for branch coverage.  To do that I 
want to get the character ranges of each term in the AST.  The Python compiler 
module doesn't keep track of that so I'm developing a new parser based on PLY.

I've developed it and I'm now cross-checking the generated ASTs to verify they are 
identical.  In this case the compiler module generates an extra node in the AST so 
I had to add backwards compatibility support.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2011>
__________________________________

From report at bugs.python.org  Tue Feb  5 05:13:26 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 05 Feb 2008 04:13:26 -0000
Subject: [issue846388] Check for signals during regular expression matches
Message-ID: <1202184806.76.0.166859267358.issue846388@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Backported to 2.5.2 as r60576.  (The other deltas are not backported.)

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue846388>
____________________________________

From report at bugs.python.org  Tue Feb  5 09:12:02 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 05 Feb 2008 08:12:02 -0000
Subject: [issue2012] Add migration step for DictMixin ->
	collections.MutableMapping
In-Reply-To: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>
Message-ID: <1202199122.74.0.664819882868.issue2012@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The difference is the underlying methods.  DictMixin depended on 
getitem, setitem, delitem, and keys.  MutableMapping doesn't need keys 
but wants __iter__ and __len__.  Also, DictMixin did not insist on all 
of those being present, while MutableMapping won't let you skip any 
(with delitem being the one most likely omitted).

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2012>
__________________________________

From report at bugs.python.org  Tue Feb  5 11:56:46 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 05 Feb 2008 10:56:46 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202209006.36.0.331482531281.issue2004@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

os.mkdir() and os.makedirs() always apply the current umask to the mode.
We cannot be responsible for poorly chosen umasks. In general, tarfile
and zipfile create directories with reasonable modes. So, IMO the
zipfile-dirperm.diff is not needed and Michael's problem depends on the
current umask.

The only exception is in TarFile._extract_member() in Python <= 2.5.x
that creates missing directories that are not part of the archive(!) and
uses os.chmod() to force a 0777 mode. That problem was addressed in
issue1507247 but only for Python 2.6 and should be backported. Although
this would change behaviour it would not cause failures.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Tue Feb  5 12:31:19 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Feb 2008 11:31:19 -0000
Subject: [issue2009] Grammar change to prevent shift/reduce problem with
	varargslist
In-Reply-To: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>
Message-ID: <1202211079.6.0.474441778498.issue2009@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I don't have any objection in principle, but I would like to see the
updated rules based on the 2.6 and 3.0 Grammar files (they should only
be minor variants of what you have already done for 2.5)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2009>
__________________________________

From report at bugs.python.org  Tue Feb  5 12:48:42 2008
From: report at bugs.python.org (Andrew Dalke)
Date: Tue, 05 Feb 2008 11:48:42 -0000
Subject: [issue2009] Grammar change to prevent shift/reduce problem with
	varargslist
In-Reply-To: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>
Message-ID: <1202212122.94.0.539063625444.issue2009@psf.upfronthosting.co.za>


Andrew Dalke added the comment:

I've been working from the Grammar file from CVS for 2.6 ... I thought.  
For example, I see "# except_clause: 'except' [test [('as' | ',') 
test]]" which is a 2.6-ism.

"svn log" says it hasn't changed since 2007-05-19, when except/as was 
added.

What did I miss?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2009>
__________________________________

From report at bugs.python.org  Tue Feb  5 12:48:59 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Feb 2008 11:48:59 -0000
Subject: [issue2011] compiler.parse("1;
	") adds unexpected extra Discard(Const(None)) to parse tree
In-Reply-To: <1202172401.58.0.984880903908.issue2011@psf.upfronthosting.co.za>
Message-ID: <1202212139.52.0.323923806123.issue2011@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Marking this as Won't Fix.

I'd suggest looking at the _ast module
(http://docs.python.org/dev/library/_ast.html) as a reference rather
than the compiler module. The maintenance on the latter has been sketchy
at best, and as you note, it is scheduled for a well earned retirement
in 3.0.

Passing _ast.PyCF_ONLY_AST as a flag to the builtin function compile()
will let you get an AST using the actual runtime compiler, so any odd
nodes you find in there are likely to be there for a reason (e.g. None
is implicitly inserted into most function namespaces due to the implied
'return None' at the end of the function).

----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2011>
__________________________________

From report at bugs.python.org  Tue Feb  5 13:01:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Feb 2008 12:01:35 -0000
Subject: [issue2010] Link to howto section on re module documentation incorrect
In-Reply-To: <1202171612.68.0.248444949572.issue2010@psf.upfronthosting.co.za>
Message-ID: <1202212895.19.0.856490678189.issue2010@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed in r60590.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2010>
__________________________________

From report at bugs.python.org  Tue Feb  5 13:06:44 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Tue, 05 Feb 2008 12:06:44 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202213204.79.0.282644680143.issue2004@psf.upfronthosting.co.za>


Lars Gust?bel added the comment:

I took the liberty of applying my patches to the trunk (r60588) and the
release25-maint branch (r60589).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Tue Feb  5 13:07:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 05 Feb 2008 12:07:43 -0000
Subject: [issue2004] tarfile extractall() allows local attacker to overwrite
	files while extracting
In-Reply-To: <1202011153.73.0.0833904049778.issue2004@psf.upfronthosting.co.za>
Message-ID: <1202213263.36.0.68595265771.issue2004@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Closing as fixed.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2004>
__________________________________

From report at bugs.python.org  Tue Feb  5 13:11:46 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 05 Feb 2008 12:11:46 -0000
Subject: [issue2009] Grammar change to prevent shift/reduce problem with
	varargslist
In-Reply-To: <1202170790.58.0.28997794645.issue2009@psf.upfronthosting.co.za>
Message-ID: <1202213506.37.0.792011454278.issue2009@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Sorry, I misread slightly (or else just got confused as to which of the
3 Grammar files I was looking at on my local machine). What you've
posted already is indeed the relevant change for 2.6 - it's only 3.0
that is slightly different because it allows the definition of
keyword-only arguments (I believe that feature may also be on the list
of items that may be backported to 2.6).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2009>
__________________________________

From report at bugs.python.org  Tue Feb  5 15:07:15 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Tue, 05 Feb 2008 14:07:15 -0000
Subject: [issue1391] Adds the .compact() method to bsddb db.DB objects
In-Reply-To: <1194227398.84.0.43254190344.issue1391@psf.upfronthosting.co.za>
Message-ID: <1202220435.47.0.0559495532112.issue1391@psf.upfronthosting.co.za>


Changes by Ismail Donmez:


----------
nosy: +cartman

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1391>
__________________________________

From report at bugs.python.org  Tue Feb  5 18:45:53 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 05 Feb 2008 17:45:53 -0000
Subject: [issue619222] os.listdir-alike that includes file type
Message-ID: <1202233553.79.0.380340319721.issue619222@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

No activity for long time.

----------
nosy: +draghuram
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue619222>
____________________________________

From report at bugs.python.org  Tue Feb  5 18:57:58 2008
From: report at bugs.python.org (James Cooper)
Date: Tue, 05 Feb 2008 17:57:58 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202234278.12.0.963851820802.issue1722344@psf.upfronthosting.co.za>


James Cooper added the comment:

Though these exceptions while shutting down are mostly harmless, they
are very noisy and must be squelched in a production application.  Here
is the patch which we at Solido Design (www.solidodesign.com) are using
to hide the exceptions.  Note that this doesn't fix the problem, but it
does hide the exception for the purposes of releasing an application to
the public.

----------
nosy: +jamescooper
Added file: http://bugs.python.org/file9356/1722344_squelch_exception.patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Tue Feb  5 19:19:34 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 05 Feb 2008 18:19:34 -0000
Subject: [issue1946] re.search hangs on this
In-Reply-To: <1201449544.57.0.177227713029.issue1946@psf.upfronthosting.co.za>
Message-ID: <1202235574.33.0.287718694995.issue1946@psf.upfronthosting.co.za>


Facundo Batista added the comment:

facundo at virtub:~$ time python -c "import
re;re.search(r'a(b[^b]*b|[^c])*cxxx','abbcacabbbbcabbbbbbcabbbbbbbbbbbbbbcacabbbbbbbbbbbbbbcabbbbcac')"

real    0m2.510s
user    0m2.308s
sys     0m0.028s
facundo at virtub:~$ 

This is a Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32) [GCC 4.1.3
20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

Note that it took some seconds on my fairly fast computer... could this
be a problem, that it takes long, but does not hang?

----------
nosy: +facundobatista
resolution:  -> works for me
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1946>
__________________________________

From report at bugs.python.org  Tue Feb  5 19:29:36 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 05 Feb 2008 18:29:36 -0000
Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in
	<module 'threading'
In-Reply-To: <1201455435.45.0.790953321864.issue1947@psf.upfronthosting.co.za>
Message-ID: <1202236176.65.0.559352551865.issue1947@psf.upfronthosting.co.za>


Facundo Batista added the comment:

This is not a bug report.

I've run your code, didn't see any exception, and works as expected (in
linux and win2k).

Please, if still happens to you, provide what are you doing to reproduce
the issue, what do you expect to happen, and the system where you're
running this.

Thank you!

----------
nosy: +facundobatista
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1947>
__________________________________

From report at bugs.python.org  Tue Feb  5 19:39:50 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 05 Feb 2008 18:39:50 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202162433.7.0.199779813194.issue2006@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0802051039t48cbc7d7y8b1bce8644b0a329@mail.gmail.com>


Bill Janssen added the comment:

*I'm not sure to understand what do you mean by "work tasks".*

They're low-priority tasks that need to get run sometime, but aren't
associated with an input source.  In ILU, we had a function called
"do_soon", and you could call it with a function that should be called
sometime in the near future.

*writing a poller suitable with epoll and kqueue*

Christian's patch looks interesting, in that respect.  I haven't applied it
to a codebase yet.

Bill

On Feb 4, 2008 2:00 PM, Giampaolo Rodola' <report at bugs.python.org> wrote:

>
> Giampaolo Rodola' added the comment:
>
> I'm not sure to understand what do you mean by "work tasks".
> Do you need them to have ssl module work with asyncore?
>
> > I've been reading asyncore lately, and feel that it's showing its age.
>
> Absolutely. I'd have some ideas about some asyncore/chat enhancements,
> including writing a poller suitable with epoll and kqueue, but it seems
> there are not enough people who cares enough about asyncore.
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2006>
> __________________________________
>

Added file: http://bugs.python.org/file9357/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080205/3258be40/attachment.txt 

From report at bugs.python.org  Tue Feb  5 20:06:56 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 05 Feb 2008 19:06:56 -0000
Subject: [issue1951] test_wave.py converted to unittest
In-Reply-To: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za>
Message-ID: <1202238416.2.0.519808402541.issue1951@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r60602. Thank you very much!

Note that I had to apply the patch by hand... I think that the problem
was in the header: if I get a svn diff, it starts differently than you
patch:

facundo at virtub:~/devel/reps/python/trunk$ svn diff -r 60601
Lib/test/test_wave.py
Index: Lib/test/test_wave.py
===================================================================
--- Lib/test/test_wave.py       (revisi?n: 60601)
+++ Lib/test/test_wave.py       (copia de trabajo)
@@ -1,32 +1,45 @@
...

I noted that you submitted other patch in other issue, please check that
one to be ok.

Thanks again!!

----------
nosy: +facundobatista
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1951>
__________________________________

From report at bugs.python.org  Tue Feb  5 21:01:29 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Feb 2008 20:01:29 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202241689.13.0.619439022389.issue1722344@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I think the general idea of the problem has been stated, but I figured I
would state the official issue.  When Python begins to shutdown it takes
each module and sets each variable in the global namespace to None. If a
thread has not terminated before the interpreter terminates then the
thread tries to use a global variable which has been set to None.

This is not about to change since this occurs because of coding
"errors". You must make sure that either your thread is as safe as a
__del__ method (which means no global namespace access) or you can't let
the app exit until you are positive all of your threads have terminated,
not just asked them to shutdown since this is all asynchronous.

----------
nosy: +brett.cannon
resolution:  -> wont fix
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Tue Feb  5 22:25:49 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 05 Feb 2008 21:25:49 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202246749.31.0.474306743872.issue1722344@psf.upfronthosting.co.za>


Adam Olsen added the comment:

Py_Main calls WaitForThreadShutdown before calling Py_Finalize, which
should wait for all these threads to finish shutting down before it
starts wiping their globals.

However, if SystemExit is raised (such as via sys.exit()), Py_Exit is
called, and it directly calls Py_Finalize, bypassing the
WaitForThreadShutdown.

Can someone who's experienced this bug check if they're using
SystemExit/sys.exit?

----------
nosy: +Rhamphoryncus

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Tue Feb  5 22:33:13 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 05 Feb 2008 21:33:13 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202247193.15.0.711139633426.issue1722344@psf.upfronthosting.co.za>


Adam Olsen added the comment:

To put it another way: SystemExit turns non-daemon threads into daemon
threads.  This is clearly wrong.  Brent, could you reopen the bug?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Tue Feb  5 23:57:53 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Feb 2008 22:57:53 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202252273.95.0.0074960983569.issue1722344@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Hold on, why is that wrong? What if the threads block forever,
preventing shutdown? sys.exit() is not exactly some namby-pamby function
but a forced shutdown of the interpreter that should guarantee that the
interpreter quits. Changing its semantics now would take that away.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Wed Feb  6 00:12:37 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 05 Feb 2008 23:12:37 -0000
Subject: [issue2014] xmlrpclib cannot send datetime objects with dates before
	1900
In-Reply-To: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>
Message-ID: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>


New submission from Ralf Schmitt:

xmlrpclib uses datetime.strftime which cannot handle dates before 1900.
this patch adds a custom date formatting function, which does not have
this restriction. It also contains 2 additional unit tests, which both
fail with the unpatched version.

----------
components: Library (Lib)
files: xmlrpc_date_before_1900.txt
messages: 62082
nosy: schmir
severity: normal
status: open
title: xmlrpclib cannot send datetime objects with dates before 1900
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9358/xmlrpc_date_before_1900.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Wed Feb  6 00:20:22 2008
From: report at bugs.python.org (Adam Olsen)
Date: Tue, 05 Feb 2008 23:20:22 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202253622.38.0.665958561984.issue1722344@psf.upfronthosting.co.za>


Adam Olsen added the comment:

I disagree.  sys.exit() attempts to gracefully shutdown the interpreter,
invoking try/finally blocks and the like.  If you want to truly force
shutdown you should use os.abort() or os._exit().

Note that, as python doesn't call a main function, you have to use
sys.exit() to have an exit status.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Wed Feb  6 00:22:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 05 Feb 2008 23:22:47 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202253767.96.0.404840223962.issue1722344@psf.upfronthosting.co.za>


Brett Cannon added the comment:

OK, I will re-open to see if some other core developer wants to take
this on, but personally I am passing.

----------
resolution: wont fix -> 
status: closed -> open

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Wed Feb  6 01:45:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Feb 2008 00:45:15 -0000
Subject: [issue2015] Possible optimisations in kwargs handling
In-Reply-To: <1202258715.2.0.486542039944.issue2015@psf.upfronthosting.co.za>
Message-ID: <1202258715.2.0.486542039944.issue2015@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

This is a reminder for the comment on top of ceval.c:
/* XXX TO DO:
   XXX speed up searching for keywords by using a dictionary
   XXX document it!
   */

It was also suggested to disallow subclasses of str in variable names,
in order to optimize comparisons. This restriction is not necessary if a
dict lookup is used: comparisons are less frequent and will often
succeed when comparing pointers of interned strings.

----------
messages: 62085
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Possible optimisations in kwargs handling
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2015>
__________________________________

From report at bugs.python.org  Wed Feb  6 02:01:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Feb 2008 01:01:11 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

The following script exploits a comment in funcobject.c:
   /* XXX This is broken if the caller deletes dict items! */
Because the code only borrows references to the items, it is possible to
have them destroyed before they are copied into the called frame.

class Name(str):
  def __eq__(self, other):
     del x[self]
     return str.__eq__(self, other)
  def __hash__(self):
     return str.__hash__(self)

x = {Name("a"):1, Name("b"):2}
def f(a, b): print a,b

f(**x)   # Segfault

----------
messages: 62086
nosy: amaury.forgeotdarc
severity: normal
status: open
title: Crash when modifying the **kwargs passed to a function.
type: crash
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Wed Feb  6 03:38:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2008 02:38:47 -0000
Subject: [issue705836] struct.pack of floats in non-native endian order
Message-ID: <1202265527.73.0.968025243664.issue705836@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I'm stealing this issue from Tim, and downgrading the priority to normal 
(it was the original bug that was high priority).

----------
assignee: tim_one -> marketdickinson
priority: high -> normal
versions: +Python 2.6, Python 3.0

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue705836>
____________________________________

From report at bugs.python.org  Wed Feb  6 06:44:29 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Wed, 06 Feb 2008 05:44:29 -0000
Subject: [issue2017] Calendar.yeardatescalendar etc. do not take 'month'
	argument
In-Reply-To: <1202276668.89.0.427395659293.issue2017@psf.upfronthosting.co.za>
Message-ID: <1202276668.89.0.427395659293.issue2017@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi:

Similar to the issue 1046,
The documentation of Calendar.year*calendar incorrectly have 'month'
argument.

>>> cal = calendar.Calendar(5)
>>> cal.yeardatescalendar(2008,2,3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: yeardatescalendar() takes at most 3 arguments (4 given)
>>>

----------
components: Documentation
messages: 62088
nosy: mft
severity: normal
status: open
title: Calendar.yeardatescalendar etc. do not take 'month' argument
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2017>
__________________________________

From report at bugs.python.org  Wed Feb  6 08:57:13 2008
From: report at bugs.python.org (Toni Brkic)
Date: Wed, 06 Feb 2008 07:57:13 -0000
Subject: [issue1985] Bug/Patch: Problem with xml/__init__.py when using
	freeze.py
In-Reply-To: <1201819314.87.0.163541496288.issue1985@psf.upfronthosting.co.za>
Message-ID: <1202284633.2.0.777232676986.issue1985@psf.upfronthosting.co.za>


Toni Brkic added the comment:

I still think the __init__ file should be changed and use
the extend_path function instead of extend. 


Se below for answer I got on the python list.


The extend_path function (found in the pkgutil standard module) can handle  
this.
http://docs.python.org/lib/module-pkgutil.html

-- 
Gabriel Genellina

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1985>
__________________________________

From report at bugs.python.org  Wed Feb  6 10:42:01 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Wed, 06 Feb 2008 09:42:01 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>


New submission from MATSUI Tetsushi:

TextCalendar.formatmonth is not influenced by setfirstweekday,
but the argument of constructor.

Documentation:
Depends on the first weekday as set by setfirstweekday().

actual behavior:
>>> cal0 = calendar.TextCalendar()
>>> print cal0.formatmonth(2008, 2)
   February 2008
Mo Tu We Th Fr Sa Su
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29

>>> calendar.setfirstweekday(4)
>>> print cal0.formatmonth(2008, 2)
   February 2008
Mo Tu We Th Fr Sa Su
             1  2  3
 4  5  6  7  8  9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29

----------
components: Documentation
messages: 62090
nosy: mft
severity: normal
status: open
title: TextCalendar.formatmonth is not influenced by setfirstweekday
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Wed Feb  6 12:36:18 2008
From: report at bugs.python.org (Thomas Dybdahl Ahle)
Date: Wed, 06 Feb 2008 11:36:18 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202297778.13.0.752934592782.issue1722344@psf.upfronthosting.co.za>


Thomas Dybdahl Ahle added the comment:

> which means no global namespace access
Does that mean that you cannot use len and range in a Thread?

----------
nosy: +lobais

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Wed Feb  6 13:06:24 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 12:06:24 -0000
Subject: [issue2014] xmlrpclib cannot send datetime objects with dates before
	1900
In-Reply-To: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>
Message-ID: <1202299584.72.0.521665111265.issue2014@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Does your patch also work on systems which don't allow negative values
for time_t?

----------
keywords: +patch
nosy: +tiran
priority:  -> normal
type: behavior -> rfe
versions: +Python 3.0 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Wed Feb  6 13:06:30 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 12:06:30 -0000
Subject: [issue2015] Possible optimisations in kwargs handling
In-Reply-To: <1202258715.2.0.486542039944.issue2015@psf.upfronthosting.co.za>
Message-ID: <1202299590.8.0.0885608883736.issue2015@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
components: +Interpreter Core
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2015>
__________________________________

From report at bugs.python.org  Wed Feb  6 13:07:24 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 12:07:24 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202299644.66.0.411524570246.issue2016@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
components: +Interpreter Core
priority:  -> high

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Wed Feb  6 13:08:07 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 12:08:07 -0000
Subject: [issue2017] Calendar.yeardatescalendar etc. do not take 'month'
	argument
In-Reply-To: <1202276668.89.0.427395659293.issue2017@psf.upfronthosting.co.za>
Message-ID: <1202299687.88.0.273277371238.issue2017@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> georg.brandl
keywords: +easy
nosy: +georg.brandl
priority:  -> normal
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2017>
__________________________________

From report at bugs.python.org  Wed Feb  6 13:08:39 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 12:08:39 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202299719.78.0.0494010549718.issue2018@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +easy
priority:  -> normal
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Wed Feb  6 13:16:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 12:16:20 -0000
Subject: [issue2007] cookielib lacks FileCookieJar class for Internet Explorer
In-Reply-To: <1202153753.42.0.88577975251.issue2007@psf.upfronthosting.co.za>
Message-ID: <1202300180.14.0.366096064937.issue2007@psf.upfronthosting.co.za>


Christian Heimes added the comment:

>From the doc string:
note that BSDDBCookieJar and the MSIE* classes are not
distributed with the Python standard library, but are available from
http://wwwsearch.sf.net/

----------
nosy: +tiran
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2007>
__________________________________

From report at bugs.python.org  Wed Feb  6 13:18:47 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 06 Feb 2008 12:18:47 -0000
Subject: [issue2014] xmlrpclib cannot send datetime objects with dates before
	1900
In-Reply-To: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>
Message-ID: <1202300327.05.0.739022883202.issue2014@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

Well, all it basically does is changing calls to obj.strftime to a
custom string formatting function (where obj is a datetime.datetime,
datetime.date or datetime.time). These strftime calls are made during
object marshalling. So, all the objects to be marshalled are created by
the program itself. The datetime module allows those dates to be
created, so I think it should be safe. 
The unmarshalling code did not change, so it's possible to receive a
date before 1900, but not to send it back...

But to answer your question. I don't know, I don't even know a platform,
which use an unsigned time_t.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Wed Feb  6 14:00:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Feb 2008 13:00:15 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
Message-ID: <1202302815.25.0.104771905605.issue1722344@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc:


----------
nosy: +amaury.forgeotdarc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Wed Feb  6 15:39:56 2008
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 06 Feb 2008 14:39:56 -0000
Subject: [issue2017] Calendar.yeardatescalendar etc. do not take 'month'
	argument
In-Reply-To: <1202276668.89.0.427395659293.issue2017@psf.upfronthosting.co.za>
Message-ID: <1202308795.98.0.741908632554.issue2017@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

Fixed in r60618 (trunk) and r60619 (release25-maint)

----------
nosy: +doerwalter
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2017>
__________________________________

From report at bugs.python.org  Wed Feb  6 15:47:13 2008
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Wed, 06 Feb 2008 14:47:13 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202309233.05.0.0454914868627.issue2018@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

setfirstweekday() isn't supposed to have any influence on calendar
objects created explicitely. The function setfirstweekday() is only for
the module level interface. The documentation is wrong here. However you
*can* change the first weekday with the setfirstweekday() *method*.

----------
assignee:  -> doerwalter
nosy: +doerwalter
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Wed Feb  6 15:48:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 14:48:08 -0000
Subject: [issue2019] API to clear most free lists
In-Reply-To: <1202309288.05.0.27913279331.issue2019@psf.upfronthosting.co.za>
Message-ID: <1202309288.05.0.27913279331.issue2019@psf.upfronthosting.co.za>


New submission from Christian Heimes:

As discussed at
http://permalink.gmane.org/gmane.comp.python.python-3000.devel/11694 the
patch adds several PyName_ClearFreelist() functions and extends
sys._compact_freelists() to clear all free lists.

----------
components: Interpreter Core
files: trunk_clearfreelists.patch
keywords: patch
messages: 62097
nosy: brett.cannon, tiran
priority: normal
severity: normal
status: open
title: API to clear most free lists
versions: Python 2.6
Added file: http://bugs.python.org/file9359/trunk_clearfreelists.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2019>
__________________________________

From report at bugs.python.org  Wed Feb  6 16:12:15 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Wed, 06 Feb 2008 15:12:15 -0000
Subject: [issue419153] Issue warning when LC_NUMERIC is not "C"
Message-ID: <1202310735.32.0.793083232244.issue419153@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

Closing as there is no activity for long time.

----------
nosy: +draghuram
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue419153>
____________________________________

From report at bugs.python.org  Wed Feb  6 16:23:18 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 06 Feb 2008 15:23:18 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202311398.08.0.199018510317.issue1682@psf.upfronthosting.co.za>


Facundo Batista added the comment:

I'm +0 to make Decimal(Rational(x,y)) available.

I'd make it something like:

Decimal(R) == Decimal(R.numerator) / Decimal(R.denominator)

Note, as Raymond says, that this division implies the use of the
context. So the following will NOT be true:

R == Rational(Decimal(R))

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Wed Feb  6 16:24:25 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Wed, 06 Feb 2008 15:24:25 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202311465.03.0.0319423336505.issue2018@psf.upfronthosting.co.za>


MATSUI Tetsushi added the comment:

Thank you for the clarification.
But then, where is the documentation about the setfirstweekday() method?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Wed Feb  6 16:45:44 2008
From: report at bugs.python.org (Peter Saunders)
Date: Wed, 06 Feb 2008 15:45:44 -0000
Subject: [issue2020] _sha256 module missing if openssl is not in a "normal"
	directory.
In-Reply-To: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za>
Message-ID: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za>


New submission from Peter Saunders:

When compiling python 2.5.1 on Solaris 10 (sparc and x86), with openssl
0.9.8e - test_md5 fails with No module named _sha256. (As does doing an
"import md5")

When compiling, setup.dist was modified, the ssl parts were uncommented,
and modified to use the directory that we have ssl installed in.

SSL=/opt/IB
_ssl _ssl.c \
       -DUSE_SSL -I$(SSL)/include -I$(SSL)/include/openssl \
       -L$(SSL)/lib -R$(SSL)/lib -lssl -lcrypto

The compiling env (on sol x86):
CC=cc
CFLAGS=-xO5 -m32 -xarch=sse3 -xcache=generic -xchip=generic
CPPFLAGS=-I/opt/IB/include
CXX=CC
CXXFLAGS=-xO5 -m32 -xarch=sse3 -xcache=generic -xchip=generic
LDFLAGS=-L/opt/IB/lib -R/opt/IB/lib
LD_RUN_PATH=/opt/IB/lib
PATH=/usr/bin:/sbin:/usr/sbin:/opt/IB/bin:/usr/ccs/bin:/opt/SUNWspro/bin

configure --prefix=/opt/IBpython/2.5.1 --without-gcc --with-threads

However, if I modify setup.py, and replace every occurrence of
"/usr/local" with "/opt/IB" (we don't use /usr/local) - then it compiles
fine, and the md5 module works correctly.

Is it possible for this to be made a configure argument, or a
environment setting?

----------
components: Build
messages: 62101
nosy: pajs at fodder.org.uk
severity: normal
status: open
title: _sha256 module missing if openssl is not in a "normal" directory.
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2020>
__________________________________

From report at bugs.python.org  Wed Feb  6 17:14:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 06 Feb 2008 16:14:24 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

In the spirit of files becoming context managers in 2.5, the attached
patch defines __enter__ and __exit__ methods for
tempfile.NamedTemporaryFile.

BTW, I was not able to add a "patch" keyword which seems appropriate here.

----------
components: Library (Lib)
files: with_NamedTemporaryFile.diff
messages: 62102
nosy: belopolsky
severity: normal
status: open
title: Turn NamedTemporaryFile into a context manager
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9360/with_NamedTemporaryFile.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Wed Feb  6 17:20:56 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Wed, 06 Feb 2008 16:20:56 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202314856.14.0.69479145193.issue2021@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda:


----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Wed Feb  6 17:25:55 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Wed, 06 Feb 2008 16:25:55 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202315155.16.0.68053500102.issue2018@psf.upfronthosting.co.za>


MATSUI Tetsushi added the comment:

There is another wrong documentation about firstweekday. 
In the part of Calendar.iterweekdays, a method "firstweekday" appered.
But indeed it means the method "getfirstweekday()", since firstweekday
is merely an uncallable integer attribute of Calendar objects.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Wed Feb  6 17:43:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 06 Feb 2008 16:43:22 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202316202.81.0.570167154556.issue2016@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

It also appears that the tuple and dict checks in function_call are
redundant.  If there is a use case that results in function_call getting
anything (non null) other than dict and tuple in arg and kw, I don't
think silently ignoring such arguments is the right behavior.

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Wed Feb  6 18:08:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 06 Feb 2008 17:08:02 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202317682.48.0.696331926142.issue2016@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

This could be turned into an assertion.
But beware that some extension writers may use code like
    PyObject_Call(callable, args, Py_None)
which works perfectly today.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Wed Feb  6 18:09:58 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 17:09:58 -0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1202317797.83.0.469405041662.issue2013@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The updated patch limits the free list.

----------
type:  -> rfe
Added file: http://bugs.python.org/file9361/py3k_longfreelist.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
__________________________________

From report at bugs.python.org  Wed Feb  6 18:52:23 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 06 Feb 2008 17:52:23 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202320343.79.0.949959474533.issue2016@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

According to http://docs.python.org/api/object.html,

"""
PyObject* PyObject_Call(	PyObject *callable_object, PyObject *args,
PyObject *kw)
    Return value: New reference.
    Call a callable Python object callable_object, with arguments given
by the tuple args, and named arguments given by the dictionary kw. If no
named arguments are needed, kw may be NULL. args must not be NULL, use
an empty tuple if no arguments are needed. Returns the result of the
call on success, or NULL on failure. 
"""

passing Py_None as kw is not allowed.  Interestingly, the documentation
also says that "args must not be NULL," while the code is clearly more
forgiving.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Wed Feb  6 18:55:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Wed, 06 Feb 2008 17:55:09 -0000
Subject: [issue1722344] Thread shutdown exception in Thread.notify()
In-Reply-To: <1202297778.13.0.752934592782.issue1722344@psf.upfronthosting.co.za>
Message-ID: <bbaeab100802060955y6bf0eabane458f21c1c000fae@mail.gmail.com>


Brett Cannon added the comment:

> > which means no global namespace access
> Does that mean that you cannot use len and range in a Thread?

No, it means you have to be careful if you do. Shutting down properly
will take care of things. Otherwise you need to save a reference
locally (either on an object or as a local variable) and use that
reference instead of relying on the one defined in the global
namespace.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1722344>
_____________________________________

From report at bugs.python.org  Wed Feb  6 18:57:14 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 06 Feb 2008 17:57:14 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202320633.96.0.797550049589.issue2016@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Sorry, please ignore my last comment about arg.  The null and tuple
checks are for argdefs, not arg.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Wed Feb  6 19:04:12 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 06 Feb 2008 18:04:12 -0000
Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary
In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za>
Message-ID: <1202321052.02.0.994849437626.issue1979@psf.upfronthosting.co.za>


Facundo Batista added the comment:

I'm +0 regarding this.

If this will go in, a comment should explicit all this in the code, as
this behaviour doesn't come from Decimal spec or the PEP.

Thanks!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1979>
__________________________________

From report at bugs.python.org  Wed Feb  6 19:15:33 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 18:15:33 -0000
Subject: [issue2020] _sha256 module missing if openssl is not in a "normal"
	directory.
In-Reply-To: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za>
Message-ID: <1202321733.79.0.907906168747.issue2020@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
priority:  -> normal
type:  -> rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2020>
__________________________________

From report at bugs.python.org  Wed Feb  6 19:19:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 06 Feb 2008 18:19:20 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202321960.05.0.939432220741.issue2021@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks for the patch! It even has a unit test, very good. :)

The __future__ statement isn't necessary for Python 2.6. The with
statement is always available.

----------
nosy: +tiran
priority:  -> normal
type: behavior -> rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Wed Feb  6 19:21:18 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 06 Feb 2008 18:21:18 -0000
Subject: [issue2020] _sha256 module missing if openssl is not in a "normal"
	directory.
In-Reply-To: <1202312744.16.0.269773483749.issue2020@psf.upfronthosting.co.za>
Message-ID: <1202322078.58.0.925930293183.issue2020@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

You need to add _hashopenssl to Setup.dist/Setup.local; then it should
provide the missing module. Apparently, when _hashopenssl was added,
nobody put it into Setup.dist. Once you have tested an appropriate
change to Setup.dist, please provide it as a patch.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2020>
__________________________________

From report at bugs.python.org  Wed Feb  6 19:49:34 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 18:49:34 -0000
Subject: [issue1951] test_wave.py converted to unittest
In-Reply-To: <1201478619.82.0.744977170557.issue1951@psf.upfronthosting.co.za>
Message-ID: <1202323774.08.0.507584932275.issue1951@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

You're right. It seems that TortoiseSVN generated diff files are
different than using the original svn cmd line tool (probably I'm using
TortoiseSVN in the wrong way).
I'll update the other patches.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1951>
__________________________________

From report at bugs.python.org  Wed Feb  6 19:56:56 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 18:56:56 -0000
Subject: [issue1960] test_gdbm.py converted to unittest
In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za>
Message-ID: <1202324216.38.0.941524876383.issue1960@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

The diff file in attachment was generated by using TortoiseSVN and it
seems to be different than using "svn diff".
The new diff file is in attachment.

Added file: http://bugs.python.org/file9363/test_gdbm.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1960>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:01:05 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:01:05 -0000
Subject: [issue1959] test_contains.py converted to unittest
In-Reply-To: <1201557754.63.0.944783137976.issue1959@psf.upfronthosting.co.za>
Message-ID: <1202324465.02.0.558112192478.issue1959@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

The diff file in attachment was generated by using TortoiseSVN and it
seems to be different than using "svn diff".
The new diff file is in attachment.

Added file: http://bugs.python.org/file9364/test_contains.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1959>
__________________________________

From report at bugs.python.org  Wed Feb  6 19:34:21 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 06 Feb 2008 18:34:21 -0000
Subject: [issue2007] cookielib lacks FileCookieJar class for Internet Explorer
In-Reply-To: <1202300180.14.0.366096064937.issue2007@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0802061033k4a52572cra74db713412d03dc@mail.gmail.com>


Bill Janssen added the comment:

Yes, I saw that, but it doesn't really help.  Batteries not included.

It suggests an approach to addressing this problem, though:  see if the
author will contribute the code under an appropriate licence.

I intend to write an instance of FileCookieJar for Safari.

Bill

On Feb 6, 2008 4:16 AM, Christian Heimes <report at bugs.python.org> wrote:

>
> Christian Heimes added the comment:
>
> From the doc string:
> note that BSDDBCookieJar and the MSIE* classes are not
> distributed with the Python standard library, but are available from
> http://wwwsearch.sf.net/
>
> ----------
> nosy: +tiran
> priority:  -> normal
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2007>
> __________________________________
>

Added file: http://bugs.python.org/file9362/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2007>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080206/5048f435/attachment.txt 

From report at bugs.python.org  Wed Feb  6 20:05:38 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:05:38 -0000
Subject: [issue1952] test_select.py converted to unittest
In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za>
Message-ID: <1202324738.65.0.144740594084.issue1952@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

In attachment is the patch including the sys.platform change discussed
above.

Added file: http://bugs.python.org/file9365/test_select.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1952>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:08:02 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:08:02 -0000
Subject: [issue1949] test_ntpath.py converted to unittest
In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za>
Message-ID: <1202324882.77.0.290040639129.issue1949@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

The diff file in attachment was generated by using TortoiseSVN and it
seems to be different than using "svn diff".
The new diff file is in attachment.

Added file: http://bugs.python.org/file9366/test_ntpath.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1949>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:25:18 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:25:18 -0000
Subject: [issue2022] test_al converted to unittest
In-Reply-To: <1202325918.42.0.816019175645.issue2022@psf.upfronthosting.co.za>
Message-ID: <1202325918.42.0.816019175645.issue2022@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment.

----------
files: test_al.diff
messages: 62119
nosy: giampaolo.rodola
severity: normal
status: open
title: test_al converted to unittest
Added file: http://bugs.python.org/file9367/test_al.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2022>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:29:23 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 06 Feb 2008 19:29:23 -0000
Subject: [issue1959] test_contains.py converted to unittest
In-Reply-To: <1201557754.63.0.944783137976.issue1959@psf.upfronthosting.co.za>
Message-ID: <1202326163.1.0.942040076626.issue1959@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Commited in r60622.

Thank you!!

----------
nosy: +facundobatista
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1959>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:33:54 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:33:54 -0000
Subject: [issue2022] test_al converted to unittest
In-Reply-To: <1202325918.42.0.816019175645.issue2022@psf.upfronthosting.co.za>
Message-ID: <1202326434.69.0.136591285645.issue2022@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola':


----------
components: +Tests
type:  -> rfe
versions: +Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2022>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:40:27 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 19:40:27 -0000
Subject: [issue2023] test_cd converted to unittest
In-Reply-To: <1202326827.71.0.0542752440376.issue2023@psf.upfronthosting.co.za>
Message-ID: <1202326827.71.0.0542752440376.issue2023@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. All existent tests are unchanged.

----------
components: Tests
files: test_cd.diff
messages: 62121
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_cd converted to unittest
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9368/test_cd.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2023>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:47:03 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 06 Feb 2008 19:47:03 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1202327223.43.0.0955499902684.issue1916@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

Is this wanted at all ?

After checking
http://www.python.org/dev/summary/2006-06-01_2006-06-15/#inspect-isgenerator
that points to:
http://mail.python.org/pipermail/python-dev/2006-May/065334.html
http://mail.python.org/pipermail/python-dev/2006-June/065508.html

it seems a patch for this function would not be accepted.

----------
nosy: +gpolo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Wed Feb  6 20:54:38 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 06 Feb 2008 19:54:38 -0000
Subject: [issue908316] pdb should hash stdout
Message-ID: <1202327678.84.0.271430440186.issue908316@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

Isn't this fixed on trunk already ? Shouldn't this be marked as closed ?

----------
nosy: +gpolo

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue908316>
____________________________________

From report at bugs.python.org  Wed Feb  6 21:16:06 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 20:16:06 -0000
Subject: [issue2024] test_gl.py converted to unittest
In-Reply-To: <1202328966.17.0.238328227675.issue2024@psf.upfronthosting.co.za>
Message-ID: <1202328966.17.0.238328227675.issue2024@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. All existing tests are unchanged.

----------
components: Tests
files: test_gl.diff
messages: 62124
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_gl.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9369/test_gl.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2024>
__________________________________

From report at bugs.python.org  Wed Feb  6 21:49:19 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 20:49:19 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202330959.67.0.546218356035.issue2006@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I still don't get it.  Maybe you're talking about something like "call a
function at the next select() loop" which in Twisted is equal to:
>>> reactor.callLater(0, something)

By using my patched asyncore you can do the same with:
>>> self.call_later(0, something)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Wed Feb  6 23:13:31 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 06 Feb 2008 22:13:31 -0000
Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary
In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za>
Message-ID: <1202336011.48.0.929116213121.issue1979@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Okay:  I checked in this change in r60630.  The checkin includes comments 
in the code and an extra paragraph describing this behavior in the 
documentation.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1979>
__________________________________

From report at bugs.python.org  Thu Feb  7 00:10:20 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 06 Feb 2008 23:10:20 -0000
Subject: [issue2025] tuples are instances of collections.Sequence but do not
	support count() and index()
In-Reply-To: <1202339420.02.0.567663678477.issue2025@psf.upfronthosting.co.za>
Message-ID: <1202339420.02.0.567663678477.issue2025@psf.upfronthosting.co.za>


New submission from Raymond Hettinger:

Remineder to self to add the two missing methods.

http://mail.python.org/pipermail/python-3000/2008-February/012021.html

----------
assignee: rhettinger
components: Interpreter Core
messages: 62127
nosy: rhettinger
severity: normal
status: open
title: tuples are instances of collections.Sequence but do not support count() and index()
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2025>
__________________________________

From report at bugs.python.org  Thu Feb  7 00:48:16 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 06 Feb 2008 23:48:16 -0000
Subject: [issue2026] test_largefile.py converted to unittest
In-Reply-To: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za>
Message-ID: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. The original tests are unchanged.
Tested under Windows XP and Linux Ubuntu 7.04.

----------
components: Tests
files: test_largefile.diff
messages: 62128
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_largefile.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9370/test_largefile.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2026>
__________________________________

From report at bugs.python.org  Thu Feb  7 02:01:19 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Feb 2008 01:01:19 -0000
Subject: [issue2025] tuples are instances of collections.Sequence but do not
	support count() and index()
In-Reply-To: <1202339420.02.0.567663678477.issue2025@psf.upfronthosting.co.za>
Message-ID: <1202346079.08.0.516264855202.issue2025@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Checked-in.  Revs 60635 and 60636.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2025>
__________________________________

From report at bugs.python.org  Thu Feb  7 02:30:08 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2008 01:30:08 -0000
Subject: [issue1514428] NaN comparison in Decimal broken
Message-ID: <1202347808.05.0.0161460943753.issue1514428@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Fixed for Python 2.6 in r60630.

----------
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1514428>
_____________________________________

From report at bugs.python.org  Thu Feb  7 02:53:36 2008
From: report at bugs.python.org (shore.cloud)
Date: Thu, 07 Feb 2008 01:53:36 -0000
Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in
	<module 'threading'
In-Reply-To: <1202236176.65.0.559352551865.issue1947@psf.upfronthosting.co.za>
Message-ID: <ae7ef6650802061753x5a786e9csec6015197bd21f48@mail.gmail.com>


shore.cloud added the comment:

hi Facundo Batista
thx very much for replying this thread
the affair with me is that all my thread related .py programme end with this
saying '*Exception exceptions.AttributeError '_shutdown' in <module
'threading'*  '

I'm running in winXP,version 2.5
and I've searched the interenet only to found one man once had the same
situation as me
whose reason is maybe version problem,say using modules of ver2.5 on ver2.3,and
the problem went away after updating the version.
but it's not the case with me
2008/2/6, Facundo Batista <report at bugs.python.org>:
>
>
> Facundo Batista added the comment:
>
> This is not a bug report.
>
> I've run your code, didn't see any exception, and works as expected (in
> linux and win2k).
>
> Please, if still happens to you, provide what are you doing to reproduce
> the issue, what do you expect to happen, and the system where you're
> running this.
>
> Thank you!
>
> ----------
> nosy: +facundobatista
> resolution:  -> invalid
> status: open -> closed
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1947>
> __________________________________
>

Added file: http://bugs.python.org/file9371/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1947>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080207/70de50c7/attachment.txt 

From report at bugs.python.org  Thu Feb  7 05:08:08 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 07 Feb 2008 04:08:08 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202330959.67.0.546218356035.issue2006@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0802062008v40b406e0l4b1619243c66b8b8@mail.gmail.com>


Bill Janssen added the comment:

Yes, that's it exactly.  So things without work tasks can still get done.

But timers are the important thing.  With timers you can always implement
work tasks by yourself.

On Feb 6, 2008 12:49 PM, Giampaolo Rodola' <report at bugs.python.org> wrote:

>
> Giampaolo Rodola' added the comment:
>
> I still don't get it.  Maybe you're talking about something like "call a
> function at the next select() loop" which in Twisted is equal to:
> >>> reactor.callLater(0, something)
>
> By using my patched asyncore you can do the same with:
> >>> self.call_later(0, something)
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2006>
> __________________________________
>

Added file: http://bugs.python.org/file9372/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080207/c2e30847/attachment.txt 

From report at bugs.python.org  Thu Feb  7 05:08:36 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 07 Feb 2008 04:08:36 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <4b3e516a0802062008v40b406e0l4b1619243c66b8b8@mail.gmail.com>
Message-ID: <4b3e516a0802062008mf048b73sa23319749b600a83@mail.gmail.com>


Bill Janssen added the comment:

Sorry, I meant to say, "so things without input FDs can make progress".

On Feb 6, 2008 8:08 PM, Bill Janssen <bill.janssen at gmail.com> wrote:

> Yes, that's it exactly.  So things without work tasks can still get done.
>
> But timers are the important thing.  With timers you can always implement
> work tasks by yourself.
>
>
> On Feb 6, 2008 12:49 PM, Giampaolo Rodola' <report at bugs.python.org> wrote:
>
> >
> > Giampaolo Rodola' added the comment:
> >
> > I still don't get it.  Maybe you're talking about something like "call a
> > function at the next select() loop" which in Twisted is equal to:
> > >>> reactor.callLater(0, something)
> >
> > By using my patched asyncore you can do the same with:
> > >>> self.call_later(0, something)
> >
> > __________________________________
> > Tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue2006>
> > __________________________________
> >
>
>

Added file: http://bugs.python.org/file9373/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080207/37c65b42/attachment.txt 

From report at bugs.python.org  Thu Feb  7 05:45:42 2008
From: report at bugs.python.org (Matt Chaput)
Date: Thu, 07 Feb 2008 04:45:42 -0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>


New submission from Matt Chaput:

Add a module to the standard library containing fast (C) implementations 
of common text/language related algorithms, to begin specifically Porter 
(and perhaps other) stemming and Levenshtein (and perhaps other) edit 
distance. Both these algorithms are useful in multiple domains, well 
known and understood, and have sample implementations all over the Web, 
but are compute-intensive and prohibitively expensive when implemented 
in pure Python.

----------
components: Library (Lib)
messages: 62134
nosy: mchaput
severity: normal
status: open
title: Module containing C implementations of common text algorithms
type: rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
__________________________________

From report at bugs.python.org  Thu Feb  7 06:23:10 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Thu, 07 Feb 2008 05:23:10 -0000
Subject: [issue908316] pdb should hash stdout
Message-ID: <1202361790.27.0.185917500915.issue908316@psf.upfronthosting.co.za>


Miki Tebeka added the comment:

Looks closed to me, tried `./t.py t.py`, it worked

Added file: http://bugs.python.org/file9374/t.py

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue908316>
____________________________________

From report at bugs.python.org  Thu Feb  7 07:25:41 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Feb 2008 06:25:41 -0000
Subject: [issue1696444] Adding an index method to tuples
Message-ID: <1202365541.8.0.372085555379.issue1696444@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Py2.6 and Py3.0 now how have tuple.index() and tuple.count().

----------
resolution:  -> out of date
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1696444>
_____________________________________

From report at bugs.python.org  Thu Feb  7 08:47:16 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 07 Feb 2008 07:47:16 -0000
Subject: [issue908316] pdb should hash stdout
Message-ID: <1202370436.28.0.85135013033.issue908316@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


----------
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue908316>
____________________________________

From report at bugs.python.org  Thu Feb  7 08:59:45 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2008 07:59:45 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202371185.44.0.550397382668.issue2006@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

> Yes, that's it exactly.  So things without input FDs can make progress".
> But timers are the important thing.  With timers you can always 
> implement work tasks by yourself.

I have the feeling that you're talking about the same thing.

>>> self.call_later(0, something)

Note that "something" is any callable object ('e.g. lambda: print
"hello"'), not necessarily a fd.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Thu Feb  7 10:43:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 09:43:28 -0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1202377408.6.0.64351785732.issue2027@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I don't think that this should be part of the core standard library.
Did you look at the TextIndexNG project?
http://opensource.zopyx.com/projects/TextIndexNG3/

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
__________________________________

From report at bugs.python.org  Thu Feb  7 10:46:40 2008
From: report at bugs.python.org (Matthias Klose)
Date: Thu, 07 Feb 2008 09:46:40 -0000
Subject: [issue1292] libffi needs an update to support mips64,
	arm and armeabi on linux
In-Reply-To: <1192699386.49.0.555660775493.issue1292@psf.upfronthosting.co.za>
Message-ID: <1202377599.94.0.199190778034.issue1292@psf.upfronthosting.co.za>


Matthias Klose added the comment:

there's a buildbot for mips-linux, none for mips64, so lets close this one.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1292>
__________________________________

From report at bugs.python.org  Thu Feb  7 12:12:33 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 11:12:33 -0000
Subject: [issue1597000] Use \r\n, not \n for HTTP headers
Message-ID: <1202382753.32.0.425488974553.issue1597000@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

cgitb just creates a html document with a traceback, it doesn't send it
over network. I would like to take a look at this, but before it would
be good to know if the author of this bug found some other place that
this issue applies.

----------
nosy: +gpolo

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597000>
_____________________________________

From report at bugs.python.org  Thu Feb  7 12:39:47 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 07 Feb 2008 11:39:47 -0000
Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary
In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za>
Message-ID: <1202384387.22.0.683530743712.issue1979@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Thanks Mark!

Shall this issue be closed?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1979>
__________________________________

From report at bugs.python.org  Thu Feb  7 12:52:50 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 07 Feb 2008 11:52:50 -0000
Subject: [issue1947] Exception exceptions.AttributeError '_shutdown' in
	<module 'threading'
In-Reply-To: <1201455435.45.0.790953321864.issue1947@psf.upfronthosting.co.za>
Message-ID: <1202385170.02.0.724296776514.issue1947@psf.upfronthosting.co.za>


Facundo Batista added the comment:

It seems that it's more a problem related to your environment. It could
be a problem in the installation, execution of the program, or even in
the XP itself.

In any case, you should ask for help in the python list, or in #python
at irc.freenode.org.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1947>
__________________________________

From report at bugs.python.org  Thu Feb  7 13:00:32 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 12:00:32 -0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1202385632.51.0.599386889713.issue1160@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

I tried Frederik's solution against trunk and it works. I compiled
python with ucs2 so it is surely setting SRE_CODE to unsigned long.
Before this change I got the same exception as pointed by Guido Ostkamp.

----------
nosy: +gpolo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
__________________________________

From report at bugs.python.org  Thu Feb  7 13:21:45 2008
From: report at bugs.python.org (=?utf-8?q?Zden=C4=9Bk_Pavlas?=)
Date: Thu, 07 Feb 2008 12:21:45 -0000
Subject: [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>


New submission from Zden?k Pavlas:

Please consider setting the default file mode to O_BINARY.  O_TEXT
breaks many unix programs and Windows has stopped to use CRLF files for
anything of use since the introduction of Win95's registry anyway.

Days when majority of "C" codebase actually DID process text files AND
CRLF files were used are long over and since Python is NOT "C" it should
reflect that.

----------
components: Windows
messages: 62144
nosy: zde
severity: minor
status: open
title: _fmode = O_TEXT is obsolete
type: behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
__________________________________

From report at bugs.python.org  Thu Feb  7 13:24:54 2008
From: report at bugs.python.org (Ben Bass)
Date: Thu, 07 Feb 2008 12:24:54 -0000
Subject: [issue2029] "python -m pydoc -g"  fails
In-Reply-To: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>
Message-ID: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>


New submission from Ben Bass:

To quickly open a PyDoc browser, I want to be able to run the following:

python -m pydoc -g

This works fine on Python2.4, but fails on 2.5(.1), with following
traceback (tested on both WinXP and Solaris 8, same result):

Traceback (most recent call last):
  File "c:\python25\lib\runpy.py", line 95, in run_module
    filename, loader, alter_sys)
  File "c:\python25\lib\runpy.py", line 52, in _run_module_code
    mod_name, mod_fname, mod_loader)
  File "c:\python25\lib\runpy.py", line 32, in _run_code
    exec code in run_globals
  File "c:\python25\lib\pydoc.py", line 2255, in <module>
    if __name__ == '__main__': cli()
  File "c:\python25\lib\pydoc.py", line 2191, in cli
    gui()
  File "c:\python25\lib\pydoc.py", line 2162, in gui
    gui = GUI(root)
  File "c:\python25\lib\pydoc.py", line 2052, in __init__
    import threading
ImportError: No module named threading


When running pydoc.py -g directly (i.e. without the -m) it works fine,
but this requires knowing the specific location of pydoc library file,
so is less helpful.

----------
components: Library (Lib)
messages: 62145
nosy: bpb
severity: normal
status: open
title: "python -m pydoc -g"  fails
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2029>
__________________________________

From report at bugs.python.org  Thu Feb  7 13:38:50 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 07 Feb 2008 12:38:50 -0000
Subject: [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1202387930.13.0.51405170311.issue2028@psf.upfronthosting.co.za>


Facundo Batista added the comment:

O_TEXT is not obsolete, as the behaviour is different even in a win2k.

>>> a = open("ubuntu-6.06.1-server-i386.iso")
>>> len(a.read())
46424
>>> a = open("ubuntu-6.06.1-server-i386.iso", "rb")
>>> len(a.read())
453132288

I agree that the default should be Binary. Note that this would break
too much in Py2, so if happens it will need to be done in Py3.

BTW, I don't know if this was already discussed, approved, rejected, etc.

----------
nosy: +facundobatista
versions: +Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
__________________________________

From report at bugs.python.org  Thu Feb  7 13:52:21 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 07 Feb 2008 12:52:21 -0000
Subject: [issue1401] urllib2 302 POST
In-Reply-To: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za>
Message-ID: <1202388741.12.0.580110280081.issue1401@psf.upfronthosting.co.za>


Facundo Batista added the comment:

So, the general agreement is that:

- After receiven the 302, it's ok to generate a GET request.

- There's a problem with the generated GET request (there should not be
a Content-Length field in the headers)

Right?

If this is ok, I'll fix it. But, what other fields should disappear?
What about Content-Type, for example?

Thank you!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1401>
__________________________________

From report at bugs.python.org  Thu Feb  7 14:01:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 13:01:22 -0000
Subject: [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1202389282.25.0.148565100195.issue2028@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

> Windows has stopped to use CRLF files
No, there are some places where a text file must be CRLF.
To name a few:
- Notepad
- Visual Studio .sln files.

> Days when majority of "C" codebase actually DID process text files 
> AND CRLF files were used are long over and since Python is NOT 
> "C" it should reflect that.

Actually, python 3.0 goes even further from "C": 
- Python mostly deals with text files
- text files will return (unicode) text data, decoded with a specified
encoding (by default: 7bit ascii)
Many unix programs will break anyway: if they want binary data, they
will have to open files in binary mode.
After that, they will run on Windows with no modification.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
__________________________________

From report at bugs.python.org  Thu Feb  7 14:21:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 13:21:05 -0000
Subject: [issue2029] "python -m pydoc -g"  fails
In-Reply-To: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>
Message-ID: <1202390465.47.0.129095663679.issue2029@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

There is a difference between "-m" and starting the module directly:
- when running a module, its directory is inserted in front of sys.path.
- with "-m", the empty string '' is inserted in front of sys.path.

The problem with pydoc.py is that there is specific code that modifies
sys.path, and will remove the standard lib from sys.path!
Look for this comment:
   # Scripts don't get the current directory in their path by default.
We could delete three lines there and avoid to remove
dirname(sys.argv[0]) from the path.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2029>
__________________________________

From report at bugs.python.org  Thu Feb  7 14:56:13 2008
From: report at bugs.python.org (=?utf-8?q?Zden=C4=9Bk_Pavlas?=)
Date: Thu, 07 Feb 2008 13:56:13 -0000
Subject: [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1202392573.48.0.796034225774.issue2028@psf.upfronthosting.co.za>


Zden?k Pavlas added the comment:

> if they want binary data, they will have to open files in binary mode.

There were binary files.  *THEN* dos and mac came with text files.  To
keep the *ORIGINAL* semantics we have to add *NEW* flags to open/fopen.
 Looks we'll run out of O_ bitfields and letters quite soon.  64bit
words and unicode alphabet finally start to make sense... :)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
__________________________________

From report at bugs.python.org  Thu Feb  7 15:12:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 14:12:45 -0000
Subject: [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1202393565.0.0.604260457287.issue2028@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Exactly. First computer files were filled with numbers, then with
English words, then with accented letters now with kanjis.

Imagine that "binary" is a kind of language. And not spoken by many
people anymore ;-)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
__________________________________

From report at bugs.python.org  Thu Feb  7 15:22:43 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Thu, 07 Feb 2008 14:22:43 -0000
Subject: [issue1966] infinite loop in httplib
In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za>
Message-ID: <1202394163.19.0.869083986096.issue1966@psf.upfronthosting.co.za>


Changes by Georgij Kondratjev:


----------
nosy: +orivej

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1966>
__________________________________

From report at bugs.python.org  Thu Feb  7 16:05:51 2008
From: report at bugs.python.org (Richard Mason)
Date: Thu, 07 Feb 2008 15:05:51 -0000
Subject: [issue2038] win32pdh.EnumObjects fails on Windows Server 2003 R2
In-Reply-To: <1202396751.1.0.830265852808.issue2038@psf.upfronthosting.co.za>
Message-ID: <1202396751.1.0.830265852808.issue2038@psf.upfronthosting.co.za>


New submission from Richard Mason:

The following test script works OK on all windows platforms apart from 
Windows Server 2003 R2:

import win32pdh
win32pdh.EnumObjects(None, None, 0, 1)

When I run on Windows Server 2003 R2 get the following dump:

E:\fusiondx\lib>test.py
Traceback (most recent call last):
  File "E:\fusiondx\lib\test.py", line 2, in <module>
    win32pdh.EnumObjects(None, None, 0, 1)
pywintypes.error: (-2147481648, 'EnumObjects for buffer size', 'No 
error message is available')

----------
components: Extension Modules
messages: 62152
nosy: rmason
severity: critical
status: open
title: win32pdh.EnumObjects fails on Windows Server 2003 R2
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2038>
__________________________________

From report at bugs.python.org  Thu Feb  7 16:26:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 15:26:27 -0000
Subject: [issue2038] win32pdh.EnumObjects fails on Windows Server 2003 R2
In-Reply-To: <1202396751.1.0.830265852808.issue2038@psf.upfronthosting.co.za>
Message-ID: <1202397987.85.0.623806001231.issue2038@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

A quick google search on "2147481648" reveals that you are not alone:
http://mail.python.org/pipermail/python-win32/2004-October/002519.html

In addition, this tracker only deals with core python. I close the
issue. Please discuss this problem on the pywin32 web site:
http://starship.python.net/crew/mhammond/win32/

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2038>
__________________________________

From report at bugs.python.org  Thu Feb  7 16:55:55 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 07 Feb 2008 15:55:55 -0000
Subject: [issue1401] urllib2 302 POST
In-Reply-To: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za>
Message-ID: <1202399755.86.0.0385970224501.issue1401@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Content-Type is probably meaningless but harmless as well. I'd say the
priority is in getting rid of headers whose misinterpretation can be
annoying, such as Content-Length.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1401>
__________________________________

From report at bugs.python.org  Thu Feb  7 17:08:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2008 16:08:14 -0000
Subject: [issue1979] Make Decimal comparisons with NaN less arbitrary
In-Reply-To: <1201754782.28.0.976193131321.issue1979@psf.upfronthosting.co.za>
Message-ID: <1202400494.74.0.429589069207.issue1979@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Closing.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1979>
__________________________________

From report at bugs.python.org  Thu Feb  7 17:10:50 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 16:10:50 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1202400650.21.0.696166986672.issue1916@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I know two real usages:

- the nose and py.test packages accept a generator function, as
described here:
http://codespeak.net/py/dist/test.html#generative-tests-yielding-more-tests
http://somethingaboutorange.com/mrl/projects/nose/#test-generators.
functions are collected with the help of the "inspect" module.

- the twisted framework use "inlineCallbacks": a function executes an
asynchronous operation and yields; execution is resumed when the
operation gets its results. "inlineCallbacks" is actually a a decorator.

Both cases make the difference between a generator function and a
regular function, even if it returns a generator. And they don't want to
execute the function to know it...

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Thu Feb  7 17:18:41 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 07 Feb 2008 16:18:41 -0000
Subject: [issue2026] test_largefile.py converted to unittest
In-Reply-To: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za>
Message-ID: <1202401121.44.0.5967785555.issue2026@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Fixed in r60645. Thank you!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2026>
__________________________________

From report at bugs.python.org  Thu Feb  7 18:19:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 07 Feb 2008 17:19:20 -0000
Subject: [issue2039] Pymalloc patch for int and float objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>


New submission from Christian Heimes:

The patch removes the special allocation schema for ints and floats and
replaces it but a standard PyObject_MALLOC schema with a limited free_list.

----------
components: Interpreter Core
files: trunk_intfloat_freelist.patch
keywords: patch
messages: 62158
nosy: tiran
priority: normal
severity: normal
status: open
title: Pymalloc patch for int and float objects
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9379/trunk_intfloat_freelist.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
__________________________________

From report at bugs.python.org  Thu Feb  7 18:38:48 2008
From: report at bugs.python.org (Jag Ginsberg)
Date: Thu, 07 Feb 2008 17:38:48 -0000
Subject: [issue2040] Class instance attributes that are property() should
	appear in __dict__
In-Reply-To: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>
Message-ID: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>


New submission from Jag Ginsberg:

If I have a class:

class Foo(object):
  bar = property(lambda self: 'baz') # ignore the value's trivial nature

and then run:

>>> foo_obj = Foo()
>>> foo_obj.__dict__

... I would expect to see:

{'bar': 'baz'}

... and not:

{}

This would seem consistent with what a property is supposed to
masquerade as. Do you disagree?

-jag

----------
components: Interpreter Core
messages: 62159
nosy: jag
severity: minor
status: open
title: Class instance attributes that are property() should appear in __dict__
type: behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2040>
__________________________________

From report at bugs.python.org  Thu Feb  7 18:45:16 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 07 Feb 2008 17:45:16 -0000
Subject: [issue2040] Class instance attributes that are property() should
	appear in __dict__
In-Reply-To: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>
Message-ID: <1202406316.03.0.506031126373.issue2040@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Descriptors like properties are bound to the class and not to the
instance. The behavior is consistent with class attributes and methods:

>>> class Foo:
...     a = 1
...     bar = property(lambda self: 'baz')
...
>>> dict(Foo.__dict__)
{'a': 1, '__module__': '__main__', 'bar': <property object at
0xb7d2b4b4>, '__doc__': None}
>>> Foo().__dict__
{}

----------
nosy: +tiran
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2040>
__________________________________

From report at bugs.python.org  Thu Feb  7 18:49:45 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 07 Feb 2008 17:49:45 -0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1202406585.53.0.610047931387.issue2027@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I agree with Amaury. Pyhton uses the slogan "batteries included" and not
"fusion reactor included". We can and will never include every library
that may be useful for some users. Python core's development cycles are
too slow for fast moving software. Andreas' TXNG3 contains fine
implementations for stemming and levenstein.

----------
nosy: +tiran
priority:  -> normal
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
__________________________________

From report at bugs.python.org  Thu Feb  7 19:19:21 2008
From: report at bugs.python.org (Stefan Seefeld)
Date: Thu, 07 Feb 2008 18:19:21 -0000
Subject: [issue2041] __getslice__ still called
In-Reply-To: <1202408361.12.0.538007423172.issue2041@psf.upfronthosting.co.za>
Message-ID: <1202408361.12.0.538007423172.issue2041@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

The python documentation states that since python 2.0 __getslice__ is
obsoleted by __getitem__. However, testing with python 2.3 as well as
2.5, I find the following surprising behavior:

class Tuple(tuple):

  def __getitem__(self, i): print '__getitem__', i
  def __getslice__(self, i): print '__getslice__', i

t = Tuple()
t[0] # __getitem__ called with type(i) == int
t[0:2] # __getslice__ called with type(i) == slice
t[0:2:1] # __getitem__ called with type(i) == slice

----------
components: Interpreter Core
messages: 62162
nosy: stefan
severity: major
status: open
title: __getslice__ still called
type: behavior
versions: Python 2.3, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2041>
__________________________________

From report at bugs.python.org  Thu Feb  7 19:25:47 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 18:25:47 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1202408747.4.0.576157961028.issue1916@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

Maybe there should be two new functions then ? isgeneratorfunction and 
isgenerator.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Thu Feb  7 19:37:13 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 07 Feb 2008 18:37:13 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1202409433.05.0.115425813914.issue2006@psf.upfronthosting.co.za>


Bill Janssen added the comment:

Yes, I think we're talking about the same thing, too.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Thu Feb  7 19:44:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2008 18:44:22 -0000
Subject: [issue2041] __getslice__ still called
In-Reply-To: <1202408361.12.0.538007423172.issue2041@psf.upfronthosting.co.za>
Message-ID: <1202409862.94.0.130597810606.issue2041@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I think the docs do a good job of explaining this;  in particular, they 
say, 
in http://docs.python.org/dev/reference/datamodel.html#special-method-
names:

"However, built-in types in CPython currently still implement 
__getslice__()."

and explain that __getslice__ is used only to implement the form a[i:j], 
and 
falls back to __getitem__ if __getslice__ is not implemented.

Getting rid of __getslice__ for builtin types in Python 2.x is probably 
one 
of those things that would break backwards compatibility.  And leaving 
it in 
is pretty harmless.  To avoid surprises, don't implement __getslice__ in 
your 
own classes.  But note that __getslice__ and friends are gone in Python 
3.0.

I'd recommend closing this as invalid, but I'll wait for a second 
opinion.

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2041>
__________________________________

From report at bugs.python.org  Thu Feb  7 19:55:19 2008
From: report at bugs.python.org (Jag Ginsberg)
Date: Thu, 07 Feb 2008 18:55:19 -0000
Subject: [issue2040] Class instance attributes that are property() should
	appear in __dict__
In-Reply-To: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>
Message-ID: <1202410519.17.0.46373653645.issue2040@psf.upfronthosting.co.za>


Jag Ginsberg added the comment:

I appreciate your quick response, and I certainly hope you won't read
this as me being anything but ignorant, but how can a property whose
function definitions include "self" be "about" the class and not the
instance?

I agree that Foo.__dict__ should include the <property object>
reference, but if a property is supposed to be a function that behaves
like an instance attribute (I say "instance" because of the presence of
self in the arguments and not cls), wouldn't it make sense for its value
to be included in foo_obj.__dict__ like every other attribute whose
value is specific to the instance?

I'm sure my misunderstanding is in the intended definitions of __dict__
and of property(). :-/

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2040>
__________________________________

From report at bugs.python.org  Thu Feb  7 19:55:26 2008
From: report at bugs.python.org (Stefan Seefeld)
Date: Thu, 07 Feb 2008 18:55:26 -0000
Subject: [issue2041] __getslice__ still called
In-Reply-To: <1202409862.94.0.130597810606.issue2041@psf.upfronthosting.co.za>
Message-ID: <47AB5412.9020107@sympatico.ca>


Stefan Seefeld added the comment:

Mark,

thanks for the quick follow-up.
OK, i now understand the situation better. The documentation I had read 
originally didn't talk about special-casing built-in objects. (And since 
I want to extend a tuple, I do have to override __getslice__ since I 
want to make sure the returned object still has the derived type.)

Yes, I believe this issue can be closed as invalid.
(Though I believe the docs could be a bit more clear about this.)

Thanks,
		Stefan

-- 

       ...ich hab' noch einen Koffer in Berlin...

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2041>
__________________________________

From report at bugs.python.org  Thu Feb  7 20:01:30 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 19:01:30 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1202410890.96.0.995936512998.issue1916@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

I'm attaching a patch, it adds two new functions and removes some
constants defined in the code that can be retrieved from compiler.consts

Added file: http://bugs.python.org/file9380/inspect.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Thu Feb  7 20:09:57 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 07 Feb 2008 19:09:57 -0000
Subject: [issue2041] __getslice__ still called
In-Reply-To: <1202408361.12.0.538007423172.issue2041@psf.upfronthosting.co.za>
Message-ID: <1202411397.15.0.174678560031.issue2041@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Well, documentation patches are always welcome, I believe :)

If you can point to a particular place in the documentation and suggest 
alternative (or extra) wording that might help, post it here and I'll deal 
with it.

----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2041>
__________________________________

From report at bugs.python.org  Thu Feb  7 20:10:04 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 07 Feb 2008 19:10:04 -0000
Subject: [issue1401] urllib2 302 POST
In-Reply-To: <1194471779.09.0.301126280852.issue1401@psf.upfronthosting.co.za>
Message-ID: <1202411404.87.0.208492904658.issue1401@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Fixed in r60648, in the trunk.

Now the content-length and content-type headers are removed from from
the headers in the redirection.

Thank you all!

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1401>
__________________________________

From report at bugs.python.org  Thu Feb  7 20:23:23 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 19:23:23 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1202412203.51.0.806623347113.issue1916@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

Adding a patch that fixes inspect test and doc.

Added file: http://bugs.python.org/file9381/inspect_doc_and_test.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Thu Feb  7 20:36:24 2008
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 07 Feb 2008 19:36:24 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202412984.19.0.246421894636.issue2018@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

The doccumentation is
here:http://docs.python.org/dev/library/calendar.html#calendar.TextCalendar.formatmonth
(or in Doc/library/calendar.rst in the source).

Anyway the first of those documentation bugs is fixed now in r60649
(trunk) and r60650 (release25-maint).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Thu Feb  7 20:42:24 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 19:42:24 -0000
Subject: [issue1218234] inspect.getsource doesn't update when a module is
	reloaded
Message-ID: <1202413344.97.0.183539173444.issue1218234@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

I'm attaching a patch. Is there some hidden problem that it may cause ?
By the way, this issue is a duplicate of http://bugs.python.org/issue993580

----------
nosy: +gpolo
Added file: http://bugs.python.org/file9382/inspect.py.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1218234>
_____________________________________

From report at bugs.python.org  Thu Feb  7 20:56:18 2008
From: report at bugs.python.org (=?utf-8?q?Walter_D=C3=B6rwald?=)
Date: Thu, 07 Feb 2008 19:56:18 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202414178.49.0.594861008562.issue2018@psf.upfronthosting.co.za>


Walter D?rwald added the comment:

You're supposed to use firstweekday as a property instead of using the
getter method getfirstweekday(). Anyway this is fixed now in r60651
(trunk) and r60652 (release25-maint)

----------
resolution: accepted -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Thu Feb  7 21:00:09 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2008 20:00:09 -0000
Subject: [issue2042] test_audioop.py converted to unittest
In-Reply-To: <1202414409.05.0.332435353831.issue2042@psf.upfronthosting.co.za>
Message-ID: <1202414409.05.0.332435353831.issue2042@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. Original tests are unchanged.

----------
components: Tests
files: test_audioop.diff
messages: 62176
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_audioop.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9383/test_audioop.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2042>
__________________________________

From report at bugs.python.org  Thu Feb  7 21:10:29 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 20:10:29 -0000
Subject: [issue1764286] inspect.getsource does not work with decorated
	functions
Message-ID: <1202415029.4.0.41062011577.issue1764286@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

I am attaching a patch that address this issue.

----------
nosy: +gpolo
Added file: http://bugs.python.org/file9384/inspect.py.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1764286>
_____________________________________

From report at bugs.python.org  Thu Feb  7 21:18:30 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2008 20:18:30 -0000
Subject: [issue2043] test_cl.py converted to unittest
In-Reply-To: <1202415510.1.0.944242978203.issue2043@psf.upfronthosting.co.za>
Message-ID: <1202415510.1.0.944242978203.issue2043@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment.

----------
components: Tests
files: test_cl.diff
messages: 62178
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_cl.py converted to unittest
versions: Python 2.6
Added file: http://bugs.python.org/file9385/test_cl.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2043>
__________________________________

From report at bugs.python.org  Thu Feb  7 21:50:27 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Thu, 07 Feb 2008 20:50:27 -0000
Subject: [issue725149] SRE bugs with capturing groups in negative assertions
Message-ID: <1202417427.56.0.44639584594.issue725149@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

looks to have been fixed.

----------
nosy: +draghuram
resolution:  -> fixed
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue725149>
____________________________________

From report at bugs.python.org  Thu Feb  7 21:51:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 20:51:25 -0000
Subject: [issue2040] Class instance attributes that are property() should
	appear in __dict__
In-Reply-To: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>
Message-ID: <1202417485.2.0.0140858062586.issue2040@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Well, a regular method also takes "self" as its first argument. And it
will not appear in the instance's __dict__.

The __dict__ of an object is intended to *store* its attributes.
A property can be accessed like an attribute (foo_obj.bar), but it is
computed each time, and not stored.

Do you know the dir() function? It returns the names of all known
attributes of a object, including properties and methods.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2040>
__________________________________

From report at bugs.python.org  Thu Feb  7 21:59:34 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Thu, 07 Feb 2008 20:59:34 -0000
Subject: [issue1881] increase parser stack limit
In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za>
Message-ID: <1202417974.19.0.00699696088391.issue1881@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

when I set the the stack size to 128kb on a 64bit linux with ulimit -s
128, the tests still pass (default stack size is 8192 kb).

However the following fails at recursion level 180 with a segfault:
def f(count):
    print count
    f(count+1)
f(0)

If I set the stack size to 96k, the interpreter cannot even start that
script. So this change should be pretty safe to not overwrite stack
boundaries.

Anything else I can do to get this in?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1881>
__________________________________

From report at bugs.python.org  Thu Feb  7 22:06:55 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 07 Feb 2008 21:06:55 -0000
Subject: [issue2044] test_sunaudiodev.py converted to unittest
In-Reply-To: <1202418415.34.0.91216503558.issue2044@psf.upfronthosting.co.za>
Message-ID: <1202418415.34.0.91216503558.issue2044@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment.
I didn't try it since I don't have a SunOS system but it should be ok
(it's very minimalistic).
As far as I can tell it should work also for Python 3.0.

----------
components: Tests
files: test_sunaudiodev.diff
messages: 62182
nosy: facundobatista, giampaolo.rodola
severity: normal
status: open
title: test_sunaudiodev.py converted to unittest
type: rfe
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9386/test_sunaudiodev.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2044>
__________________________________

From report at bugs.python.org  Thu Feb  7 22:27:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 07 Feb 2008 21:27:09 -0000
Subject: [issue2028] _fmode = O_TEXT is obsolete
In-Reply-To: <1202386905.17.0.194031124278.issue2028@psf.upfronthosting.co.za>
Message-ID: <1202419629.28.0.284539778882.issue2028@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I'll close this issue as rejected. As discussed, changing it in 2.x
would be incompatible. To change the default for open in 3.x to return
bytes instead of character string (i.e. open files in binary) would
require convincing Guido van Rossum, which is unlikely to happen.

----------
nosy: +loewis
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2028>
__________________________________

From report at bugs.python.org  Thu Feb  7 23:31:11 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 07 Feb 2008 22:31:11 -0000
Subject: [issue2029] "python -m pydoc -g"  fails
In-Reply-To: <1202387094.14.0.198769715828.issue2029@psf.upfronthosting.co.za>
Message-ID: <1202423471.47.0.465329127817.issue2029@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

I don't see the point of lines below that comment "# Scripts don't get
the current directory in their path by default.". I'm adding a patch
that removes those lines and makes use of pathdirs function instead of
using sys.path in serve function, so you get unique paths and some other
things that pathdirs does. If pathdirs shouldn't be used then it should
be removed as well, because it was not been used anywhere else. It seems
sometime this was changed by mistake.

----------
nosy: +gpolo
Added file: http://bugs.python.org/file9387/pydoc.py.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2029>
__________________________________

From report at bugs.python.org  Thu Feb  7 23:35:32 2008
From: report at bugs.python.org (jason kirtland)
Date: Thu, 07 Feb 2008 22:35:32 -0000
Subject: [issue2045] defaultdict subclasses segfault with a bound method set
	as a default_factory
In-Reply-To: <1202423731.9.0.782285992548.issue2045@psf.upfronthosting.co.za>
Message-ID: <1202423731.9.0.782285992548.issue2045@psf.upfronthosting.co.za>


New submission from jason kirtland:

Python 2.5.1 (r251:54863, May 23 2007, 16:25:53) 
[GCC 4.1.1 20070105 (Red Hat 4.1.1-52)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from collections import defaultdict
>>> class sub(defaultdict):
...     def __init__(self):
...         self.default_factory = self._factory
...     def _factory(self):
...         return []
... 
>>> s = sub()
>>> repr(s)
Segmentation fault

----------
components: Library (Lib)
messages: 62185
nosy: jek
severity: normal
status: open
title: defaultdict subclasses segfault with a bound method set as a default_factory
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2045>
__________________________________

From report at bugs.python.org  Fri Feb  8 00:44:08 2008
From: report at bugs.python.org (Eduardo Padoan)
Date: Thu, 07 Feb 2008 23:44:08 -0000
Subject: [issue2046] patch to fix_import: UserDict -> collections
In-Reply-To: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>
Message-ID: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>


New submission from Eduardo Padoan:

UserDict moved from UserDict module (deleted) to collections on py3k.
This patch adds this case to fix_import.py on 2to3.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: fix_import_udict.diff
messages: 62186
nosy: collinwinter, eopadoan, rhettinger
severity: normal
status: open
title: patch to fix_import: UserDict -> collections
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9388/fix_import_udict.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2046>
__________________________________

From report at bugs.python.org  Fri Feb  8 00:55:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 07 Feb 2008 23:55:33 -0000
Subject: [issue2045] defaultdict subclasses segfault with a bound method set
	as a default_factory
In-Reply-To: <1202423731.9.0.782285992548.issue2045@psf.upfronthosting.co.za>
Message-ID: <1202428533.64.0.647967370904.issue2045@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc:


----------
assignee:  -> amaury.forgeotdarc
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> pending

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2045>
__________________________________

From report at bugs.python.org  Fri Feb  8 01:27:55 2008
From: report at bugs.python.org (Matt Chaput)
Date: Fri, 08 Feb 2008 00:27:55 -0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1202430475.6.0.0835938562836.issue2027@psf.upfronthosting.co.za>


Matt Chaput added the comment:

The Porter stemming and Levenshtein edit-distance algorithms are not
"fast-moving" nor are they fusion reactors... they've been around
forever, and are simple to implement, but are still useful in various
common scenarios. I'd say this is similar to Python including an
implementation of digest functions such as SHA: it's useful enough, and
compute-intensive enough, to warrant a C implementation. Shipping C
extensions is not an option for everyone; it's especially a pain with
Windows.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
__________________________________

From report at bugs.python.org  Fri Feb  8 01:58:05 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Feb 2008 00:58:05 -0000
Subject: [issue2045] defaultdict subclasses segfault with a bound method set
	as a default_factory
In-Reply-To: <1202423731.9.0.782285992548.issue2045@psf.upfronthosting.co.za>
Message-ID: <1202432285.94.0.792296975283.issue2045@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Committed r60663 in trunk. Thanks for the report!
Will backport to the 2.5 branch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2045>
__________________________________

From report at bugs.python.org  Fri Feb  8 02:03:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 08 Feb 2008 01:03:07 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202432586.94.0.930346564219.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

from Guido:

> I have one minor nit on the current rational.py code: all internal
> accesses to the numerator and denominator should use self._numerator
> and self._denominator -- going through the properties makes it *much*
> slower. Remember that Python function/method calls are slow, and never
> optimized away. :-)

This isn't quite as simple as doing s/.numerator/._numerator, since the 
current code makes use of the fact that the int and long types also 
implement .numerator and .denominator.

Can we follow the approach that Decimal takes:  convert subclasses of 
int and long to Rational before operating?  At first sight it seems 
possible that this might actually slow down code that does a lot of 
mixed-mode int/long + Rational arithmetic, but I think this is unlikely.  
I'll implement this unless there are objections.

I'm also wondering what the policy should be on return types:  if a and 
b are instances of a subclass of Rational, should a+b have return type 
Rational, or return type equal to that of a and b?  Current behaviour of 
various builtin types and Decimal suggests that a Rational should be 
returned.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Fri Feb  8 02:06:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 08 Feb 2008 01:06:17 -0000
Subject: [issue2045] defaultdict subclasses segfault with a bound method set
	as a default_factory
In-Reply-To: <1202423731.9.0.782285992548.issue2045@psf.upfronthosting.co.za>
Message-ID: <1202432777.36.0.126630532353.issue2045@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Committed r60664 for the coming 2.5.2.

----------
status: pending -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2045>
__________________________________

From report at bugs.python.org  Fri Feb  8 02:06:59 2008
From: report at bugs.python.org (MATSUI Tetsushi)
Date: Fri, 08 Feb 2008 01:06:59 -0000
Subject: [issue2018] TextCalendar.formatmonth is not influenced by
	setfirstweekday
In-Reply-To: <1202290921.43.0.226786092964.issue2018@psf.upfronthosting.co.za>
Message-ID: <1202432819.6.0.472416219517.issue2018@psf.upfronthosting.co.za>


MATSUI Tetsushi added the comment:

In the message msg62100, I asked about the place of *setfirstweekday()*.
Your answer in the message msg62173 was about *formatmonth()*.
I don't think the fix is complete until some explanations are given for
firstweekday and/or its getter/setter, since they have been mentioned
from your description fixes but have no entries.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2018>
__________________________________

From report at bugs.python.org  Fri Feb  8 02:23:33 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 08 Feb 2008 01:23:33 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1202432586.94.0.930346564219.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802071723m4bf23b3buacd0522b4dd48558@mail.gmail.com>


Guido van Rossum added the comment:

> > I have one minor nit on the current rational.py code: all internal
> > accesses to the numerator and denominator should use self._numerator
> > and self._denominator -- going through the properties makes it *much*
> > slower. Remember that Python function/method calls are slow, and never
> > optimized away. :-)
>
> This isn't quite as simple as doing s/.numerator/._numerator, since the
> current code makes use of the fact that the int and long types also
> implement .numerator and .denominator.

Well, but *self.numerator* certainly doesn't need to worry about self
being an int or long. :-)

> Can we follow the approach that Decimal takes:  convert subclasses of
> int and long to Rational before operating?  At first sight it seems
> possible that this might actually slow down code that does a lot of
> mixed-mode int/long + Rational arithmetic, but I think this is unlikely.
> I'll implement this unless there are objections.

It had never occurred to me to do it otherwise. ;-)

> I'm also wondering what the policy should be on return types:  if a and
> b are instances of a subclass of Rational, should a+b have return type
> Rational, or return type equal to that of a and b?  Current behaviour of
> various builtin types and Decimal suggests that a Rational should be
> returned.

Correct -- the thing is that you can't know the signature of the
subclass's constructor so you can't very well blindly call that.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Fri Feb  8 07:15:38 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Fritzsche?=)
Date: Fri, 08 Feb 2008 06:15:38 -0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>


New submission from Andr? Fritzsche:

shutil.destinsrc(src,dst)

Checks if 'dst' starts with 'src', which can return a wrong result if
'dst' even starts with 'scr' but isn't really a subdirector of it. E.g.
(src=r'C:\data', dst=r'C:\data.old') returned true, although dst isn't a
subdirectory of src.

I tried to fix this creating the absolute paths of 'dst' and 'src'
appended the path seperator, if there wasn't one. Then did the check
again and now the result is correct.

See the diff file I've appended (and hopefully created correctly)

----------
components: Library (Lib)
files: shutil.diff
messages: 62193
nosy: computercrustie
severity: normal
status: open
title: shutil.destinsrc returns wrong result when source path matches beginning of destination path
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file9389/shutil.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Fri Feb  8 11:19:18 2008
From: report at bugs.python.org (Atro Tossavainen)
Date: Fri, 08 Feb 2008 10:19:18 -0000
Subject: [issue2048] Python 2.5.1 woes on IRIX, Solaris
In-Reply-To: <1202465958.71.0.917319505775.issue2048@psf.upfronthosting.co.za>
Message-ID: <1202465958.71.0.917319505775.issue2048@psf.upfronthosting.co.za>


New submission from Atro Tossavainen:

Building and testing on Solaris 8 on SPARC with Sun compilers:
cc: Sun C 5.8 2005/10/13
CC: Sun C++ 5.8 2005/10/13

281 tests OK.
40 tests skipped:
    test_aepack test_al test_applesingle test_bsddb test_bsddb185
    test_bsddb3 test_cd test_cl test_codecmaps_cn test_codecmaps_hk
    test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_ctypes
    test_curses test_gdbm test_gl test_imgfile test_linuxaudiodev
    test_macfs test_macostools test_nis test_normalization
    test_ossaudiodev test_pep277 test_plistlib test_scriptpackages
    test_socket_ssl test_socketserver test_sqlite test_startfile
    test_sunaudiodev test_tcl test_timeout test_unicode_file
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_zipfile64
4 skips unexpected on sunos5:
    test_tcl test_sunaudiodev test_ctypes test_nis

...
test_tcl skipped -- No module named _tkinter
...

I have applied the _ctypes patch in #1516, however.  What gives?

Building and testing on IRIX 6.5.30 with MIPS compilers 7.4.4, the test
suite fails to complete:

test_xml_etree
gmake: *** [test] Segmentation fault

----------
components: Build, Tests
messages: 62194
nosy: atossava
severity: normal
status: open
title: Python 2.5.1 woes on IRIX, Solaris
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2048>
__________________________________

From report at bugs.python.org  Fri Feb  8 12:24:42 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 08 Feb 2008 11:24:42 -0000
Subject: [issue2043] test_cl.py converted to unittest
In-Reply-To: <1202415510.1.0.944242978203.issue2043@psf.upfronthosting.co.za>
Message-ID: <1202469882.95.0.193954557213.issue2043@psf.upfronthosting.co.za>


Changes by Facundo Batista:


----------
keywords: +easy

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2043>
__________________________________

From report at bugs.python.org  Fri Feb  8 13:34:30 2008
From: report at bugs.python.org (Tal Einat)
Date: Fri, 08 Feb 2008 12:34:30 -0000
Subject: [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>


New submission from Tal Einat:

When IDLE is run with a subprocess, add a 'Restart Shell & Run Module'
item to the 'Run' menu in editor windows. Also add Alt-F5 as a hotkey
for this item.

This is what the 'Run Module' (F5) item used to do (when there was a
subprocess). As of this patch 'Run Module' will not restart the shell
under any circumstances.


The advantages of this are that the user has more control (can run a
module in the shell either with or without restarting). It also avoids
surprising users which wouldn't expect 'Run Module' to restart the shell.


Based on changes proposed by Doug on idle-dev:
http://mail.python.org/pipermail/idle-dev/2007-January/002541.html

----------
components: IDLE
files: IDLE_restart_shell_and_run_module.080208.patch
messages: 62195
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - Restart Shell & Run Module
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9390/IDLE_restart_shell_and_run_module.080208.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Fri Feb  8 13:41:42 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 08 Feb 2008 12:41:42 -0000
Subject: [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202474502.67.0.353121535855.issue2049@psf.upfronthosting.co.za>


Changes by Facundo Batista:


----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Fri Feb  8 13:45:47 2008
From: report at bugs.python.org (Tal Einat)
Date: Fri, 08 Feb 2008 12:45:47 -0000
Subject: [issue2050] IDLE - make ScriptBinding event handlers return 'break'
In-Reply-To: <1202474747.18.0.823869647576.issue2050@psf.upfronthosting.co.za>
Message-ID: <1202474747.18.0.823869647576.issue2050@psf.upfronthosting.co.za>


New submission from Tal Einat:

Event handlers in ScriptBinding.py were not returning 'break', although
they should have been.

----------
components: IDLE
files: IDLE_ScriptBinding.080208.patch
messages: 62196
nosy: kbk, taleinat
severity: minor
status: open
title: IDLE - make ScriptBinding event handlers return 'break'
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9391/IDLE_ScriptBinding.080208.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2050>
__________________________________

From report at bugs.python.org  Fri Feb  8 14:07:55 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Fri, 08 Feb 2008 13:07:55 -0000
Subject: [issue2039] Pymalloc patch for int and float objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1202476075.25.0.0277203093537.issue2039@psf.upfronthosting.co.za>


Andrew I MacIntyre added the comment:

As indicated in a python-dev posting, I'm adding my experimental grade
patches removing the freelists from ints and floats.

Subject to testing on other platforms (I've only tested on FreeBSD 6.1
and OS/2), I suggest that the float case should be seriously considered,
as there seems little advantage to the complexity of the freelist, with
better memory utilisation likely to flow from relying on PyMalloc on top
of being faster than the current freelist implementation (for reasons
unknown; the version in tiran's patch performs similar to the
no-freelist patch).

The int freelist is enough ahead in performance (although only 3-5%) to
justify ignoring the better memory utilisation of dropping the freelist.

----------
nosy: +aimacintyre
Added file: http://bugs.python.org/file9392/no-intfloat-freelist.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
__________________________________

From report at bugs.python.org  Fri Feb  8 15:53:46 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Fri, 08 Feb 2008 14:53:46 -0000
Subject: [issue1037516] ftplib PASV error bug
Message-ID: <1202482426.11.0.857521393015.issue1037516@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

> If ftplib gets an error while doing the PASV
> section of the ntransfercmd it dies.

Which kind of error? What do you mean by "dies"?
If the server returns an error response while ftplib is attempting to
open a passive data channel it is expected that an exception is raised.

----------
nosy: +giampaolo.rodola

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1037516>
_____________________________________

From report at bugs.python.org  Fri Feb  8 16:04:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 08 Feb 2008 15:04:22 -0000
Subject: [issue2027] Module containing C implementations of common text
	algorithms
In-Reply-To: <1202359542.04.0.8630524902.issue2027@psf.upfronthosting.co.za>
Message-ID: <1202483062.59.0.0803546510207.issue2027@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Even PHP includes Levenshtein... ;)

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2027>
__________________________________

From report at bugs.python.org  Fri Feb  8 18:08:10 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 08 Feb 2008 17:08:10 -0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1202490490.16.0.21081015575.issue2047@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

Can you write a test to catch this problem? The patch should preferably
be against the latest svn source.

----------
nosy: +draghuram

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Fri Feb  8 18:31:25 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 17:31:25 -0000
Subject: [issue2040] Class instance attributes that are property() should
	appear in __dict__
In-Reply-To: <1202405928.27.0.141283710592.issue2040@psf.upfronthosting.co.za>
Message-ID: <1202491885.77.0.729316425926.issue2040@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Please take the question to the Python general mailing list. I'm sure
several people are able to explain it to you. The bug tracker isn't the
right place.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2040>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:56:35 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:56:35 -0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1202496995.58.0.546849816681.issue2047@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The fix may get into 2.5 but definitely not into 2.4 because it's not a
security fix.

----------
components: +Windows
keywords: +patch
nosy: +tiran
priority:  -> normal
versions: +Python 2.5, Python 2.6 -Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:56:56 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:56:56 -0000
Subject: [issue2050] IDLE - make ScriptBinding event handlers return 'break'
In-Reply-To: <1202474747.18.0.823869647576.issue2050@psf.upfronthosting.co.za>
Message-ID: <1202497016.74.0.212433282715.issue2050@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> kbk
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2050>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:57:12 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:57:12 -0000
Subject: [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202497032.95.0.915688919925.issue2049@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> kbk
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:57:33 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:57:33 -0000
Subject: [issue2043] test_cl.py converted to unittest
In-Reply-To: <1202415510.1.0.944242978203.issue2043@psf.upfronthosting.co.za>
Message-ID: <1202497053.87.0.518322809416.issue2043@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2043>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:57:57 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:57:57 -0000
Subject: [issue2046] patch to fix_import: UserDict -> collections
In-Reply-To: <1202427848.74.0.973500196502.issue2046@psf.upfronthosting.co.za>
Message-ID: <1202497077.28.0.00405181645752.issue2046@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee: collinwinter -> tiran
keywords: +patch
nosy: +tiran
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2046>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:58:12 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:58:12 -0000
Subject: [issue2044] test_sunaudiodev.py converted to unittest
In-Reply-To: <1202418415.34.0.91216503558.issue2044@psf.upfronthosting.co.za>
Message-ID: <1202497092.17.0.272261074341.issue2044@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2044>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:58:24 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:58:24 -0000
Subject: [issue2042] test_audioop.py converted to unittest
In-Reply-To: <1202414409.05.0.332435353831.issue2042@psf.upfronthosting.co.za>
Message-ID: <1202497104.6.0.267702198223.issue2042@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2042>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:58:32 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:58:32 -0000
Subject: [issue2026] test_largefile.py converted to unittest
In-Reply-To: <1202341696.8.0.722908796599.issue2026@psf.upfronthosting.co.za>
Message-ID: <1202497112.37.0.405484648651.issue2026@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2026>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:58:41 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:58:41 -0000
Subject: [issue2024] test_gl.py converted to unittest
In-Reply-To: <1202328966.17.0.238328227675.issue2024@psf.upfronthosting.co.za>
Message-ID: <1202497121.58.0.119162281176.issue2024@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2024>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:58:48 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:58:48 -0000
Subject: [issue2023] test_cd converted to unittest
In-Reply-To: <1202326827.71.0.0542752440376.issue2023@psf.upfronthosting.co.za>
Message-ID: <1202497128.66.0.147657399259.issue2023@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2023>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:58:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:58:55 -0000
Subject: [issue2022] test_al converted to unittest
In-Reply-To: <1202325918.42.0.816019175645.issue2022@psf.upfronthosting.co.za>
Message-ID: <1202497135.47.0.409217914624.issue2022@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2022>
__________________________________

From report at bugs.python.org  Fri Feb  8 19:59:02 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 18:59:02 -0000
Subject: [issue1960] test_gdbm.py converted to unittest
In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za>
Message-ID: <1202497142.24.0.14104491468.issue1960@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1960>
__________________________________

From report at bugs.python.org  Fri Feb  8 20:28:32 2008
From: report at bugs.python.org (stocker81)
Date: Fri, 08 Feb 2008 19:28:32 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>


New submission from stocker81:

Python's interpreter doesn't keep proper file permissions after
importing library. See the fallowing:

mk at laptop ~ $ echo "key='top secret'" > key.py
mk at laptop ~ $ chmod 600 key.py 
mk at laptop ~ $ python
Python 2.4.4 (#1, Jan  8 2008, 21:22:16) 
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import key
>>> 
mk at laptop ~ $ ls -l key.py*
-rw------- 1 mk mk  17 II  8 20:09 key.py
-rw-r--r-- 1 mk mk 120 II  8 20:09 key.pyc
mk at laptop ~ $ 

So, interpreter creates 644 pyo file (visible for all) which contains
secret data from 600 py file.
I think it should keep the original permissions, someone can save a
important data (eg. SQL login/pwd into Django's settings.py) into
library and makes it visible for all by an accident.

----------
components: None
messages: 62203
nosy: stocker81
severity: normal
status: open
title: PYO file permission problem
type: security
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Fri Feb  8 20:59:18 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 19:59:18 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1202500758.13.0.605467816304.issue2051@psf.upfronthosting.co.za>


Christian Heimes added the comment:

You have a good use case for a change of behavior. We might change it
for Python 2.6 and 3.0.

A proper place would be Python/import.c:load_source_module().

----------
components: +Interpreter Core -None
nosy: +tiran
priority:  -> high
versions: +Python 2.6 -Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Fri Feb  8 21:37:32 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 08 Feb 2008 20:37:32 -0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1202503052.56.0.550716230958.issue2047@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

I added couple of test cases. Please see the patch shutil_destinsrc.patch.

Added file: http://bugs.python.org/file9393/shutil_destinsrc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Fri Feb  8 21:38:10 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 08 Feb 2008 20:38:10 -0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1202503090.91.0.104242093348.issue2047@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

Christian, do you mind testing on windows? I tested only on Linux.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Fri Feb  8 21:58:30 2008
From: report at bugs.python.org (stocker81)
Date: Fri, 08 Feb 2008 20:58:30 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1202504310.35.0.346875556519.issue2051@psf.upfronthosting.co.za>


stocker81 added the comment:

BTW, I see you've removed this issue from bugs list printed at
http://bugs.python.org/ but everyone (including unlogged visitors) can
access it still via http://bugs.python.org/issue2051 ...

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Fri Feb  8 22:21:54 2008
From: report at bugs.python.org (josephoenix)
Date: Fri, 08 Feb 2008 21:21:54 -0000
Subject: [issue2052] Lack of difflib.HtmlDiff unicode support
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>


New submission from josephoenix:

When passed unicode strings, difflib.HtmlDiff.make_file and make_table 
fail with a UnicodeEncodeError. Also, the html outputted by make_file 
seems to be hardcoded to use charset=ISO-8859-1 (line 1584 of difflib.py)

----------
components: Library (Lib)
messages: 62208
nosy: josephoenix
severity: normal
status: open
title: Lack of difflib.HtmlDiff unicode support
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
__________________________________

From report at bugs.python.org  Fri Feb  8 22:34:09 2008
From: report at bugs.python.org (josephoenix)
Date: Fri, 08 Feb 2008 21:34:09 -0000
Subject: [issue2052] Lack of difflib.HtmlDiff unicode support
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1202506449.45.0.954915248103.issue2052@psf.upfronthosting.co.za>


josephoenix added the comment:

Oops, please close this. Apparently was fixed in 2.5.1, and I'm just 
behind.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
__________________________________

From report at bugs.python.org  Fri Feb  8 22:50:29 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 08 Feb 2008 21:50:29 -0000
Subject: [issue549764] Uninstall target in makefile
Message-ID: <1202507429.11.0.895714641986.issue549764@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

no activity and no patch.

----------
nosy: +draghuram
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue549764>
____________________________________

From report at bugs.python.org  Fri Feb  8 22:51:40 2008
From: report at bugs.python.org (josephoenix)
Date: Fri, 08 Feb 2008 21:51:40 -0000
Subject: [issue2052] Lack of difflib.HtmlDiff unicode support
In-Reply-To: <1202505714.47.0.79762903943.issue2052@psf.upfronthosting.co.za>
Message-ID: <1202507500.56.0.13114848686.issue2052@psf.upfronthosting.co.za>


josephoenix added the comment:

After installing 2.5.1, the UnicodeEncodeError is gone, but the charset is 
still hardcoded in difflib._file_template. So, I guess this is still a 
separate bug.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2052>
__________________________________

From report at bugs.python.org  Fri Feb  8 22:54:38 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 08 Feb 2008 21:54:38 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202504310.35.0.346875556519.issue2051@psf.upfronthosting.co.za>
Message-ID: <47ACCF91.7030507@cheimes.de>


Christian Heimes added the comment:

stocker81 wrote:
> BTW, I see you've removed this issue from bugs list printed at
> http://bugs.python.org/ but everyone (including unlogged visitors) can
> access it still via http://bugs.python.org/issue2051 ...

I haven't removed it from the listing. Look under priority "high" a few
pages up.

Christian

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Sat Feb  9 00:04:55 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 08 Feb 2008 23:04:55 -0000
Subject: [issue2048] Python 2.5.1 woes on IRIX, Solaris
In-Reply-To: <1202465958.71.0.917319505775.issue2048@psf.upfronthosting.co.za>
Message-ID: <1202511895.38.0.527267036862.issue2048@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Please don't mix several unrelated issues in a single report, else it is
difficult to keep track which aspects have been resolved and which need
further attention. This is particularly true for a report of breakage on
a minority platform, which could easily remain unresolved for years.

As for Solaris: What is the specific problem that you are reporting?
I.e. what behavior did you expect instead?

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2048>
__________________________________

From report at bugs.python.org  Sat Feb  9 01:10:21 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 09 Feb 2008 00:10:21 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>


New submission from Tal Einat:

In many places in the code, tkMessageBox dialogs were being used
directly, with the master (parent) widget being set explicitly to the
EditorWindow's text widget. Only in some cases was the focus being set
to the text widget afterwards, although in most this is the Right Thing
To Do.

This patch adds a decorator which wraps a tkMessage box (or similar)
function to use the EditorWindow's text widget as a parent by default
and set focus back to it afterwards. This is used to wrap the showerror
and ask* methods. It also changes the code to use these methods wherever
appropriate.

All in all, the change in functionality is that the dialogs' parent
widget will always be the text widget, and that focus will always be
returned to it. This makes the interface more consistent. As a bonus, a
lot of repetitive cruft is removed from the code, and writing extensions
is made another bit simpler.

----------
components: IDLE
files: IDLE_standardize_dialogs.080208.patch
messages: 62214
nosy: kbk, taleinat
severity: normal
status: open
title: IDLE - standardize dialogs
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9394/IDLE_standardize_dialogs.080208.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Sat Feb  9 01:53:36 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 09 Feb 2008 00:53:36 -0000
Subject: [issue1794] Hot keys must work in any keyboard layout
In-Reply-To: <1200070698.92.0.206138884505.issue1794@psf.upfronthosting.co.za>
Message-ID: <1202518416.31.0.625181147731.issue1794@psf.upfronthosting.co.za>


Tal Einat added the comment:

(sorry to be joining in late, but I just happened upon this...)

Nashev, if you configured your IDLE's keys to fit a Russian keyboard
layout, then you could post your config-keys.cfg file (from your .idlerc
directory) on the internet for others to enjoy. (this is the file where
user-configured key bindings are saved)

IMHO, specifically in the case of IDLE, binding to scan codes instead of
characters would be harmful, since it would be harder for users not
familiar with scan codes to understand and tweak.

----------
nosy: +taleinat

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1794>
__________________________________

From report at bugs.python.org  Sat Feb  9 02:54:43 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 09 Feb 2008 01:54:43 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202522083.2.0.485686646646.issue2053@psf.upfronthosting.co.za>


Tal Einat added the comment:

Bah, the initial version contained a silly bug in
EditorWindow.goto_line_event. Please remove it, and use this version
instead.

Added file: http://bugs.python.org/file9395/IDLE_standardize_dialogs.080209.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Sat Feb  9 03:16:07 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 09 Feb 2008 02:16:07 -0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>


New submission from Gregory P. Smith:

ftplib does not support ftp over SSL / TLS as described in RFC 4217. 
This would be a nice thing for someone wanting to contribute something
to add.

----------
components: Library (Lib)
messages: 62217
nosy: gregory.p.smith
severity: normal
status: open
title: add ftp-tls support to ftplib - RFC 4217
type: rfe
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
__________________________________

From report at bugs.python.org  Sat Feb  9 03:17:43 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 09 Feb 2008 02:17:43 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202523463.29.0.793670188957.issue2053@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> kbk
keywords: +patch
priority:  -> normal
type:  -> rfe
versions:  -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Sat Feb  9 03:17:49 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 09 Feb 2008 02:17:49 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202523469.01.0.292956217466.issue2053@psf.upfronthosting.co.za>


Changes by Christian Heimes:


Removed file: http://bugs.python.org/file9394/IDLE_standardize_dialogs.080208.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Sat Feb  9 04:57:17 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 09 Feb 2008 03:57:17 -0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1202529437.24.0.355331177775.issue2054@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +easy
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
__________________________________

From report at bugs.python.org  Sat Feb  9 06:46:54 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 09 Feb 2008 05:46:54 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202536014.59.0.571008898672.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I figured I'd time the difference before we change the code:

$ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)'
'r.numerator'
1000000 loops, best of 3: 0.696 usec per loop
$ ./python.exe -m timeit -s 'import rational; r=rational.Rational(3, 1)'
'r._numerator'
10000000 loops, best of 3: 0.155 usec per loop
$ ./python.exe -m timeit -s '(3).numerator'
10000000 loops, best of 3: 0.0324 usec per loop
$ ./python.exe -m timeit -s '(3L).numerator'
10000000 loops, best of 3: 0.0356 usec per loop
$ ./python.exe -m timeit -s 'from rational import Rational' 'Rational(3,
1)'  
10000 loops, best of 3: 80.4 usec per loop
$ ./python.exe -m timeit -s 'from rational import Rational;
r=Rational(3, 1)' 'isinstance(r, Rational)'
100000 loops, best of 3: 10.6 usec per loop

So every time we change .numerator to ._numerator we save half a
microsecond. If we construct a new Rational from the result, that's
totally drowned out by the Rational() call. Even checking whether we're
looking at a Rational costs 20 times as much as the difference, although
that can probably be optimized. I think this means that we shouldn't
bother changing the arithmetic methods since it makes the code more
complicated, but changing unary methods, especially ones that don't
return Rationals, can't hurt.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  9 12:20:36 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 09 Feb 2008 11:20:36 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202556036.32.0.066929639155.issue2053@psf.upfronthosting.co.za>


Tal Einat added the comment:

Going through the code more thoroughly, found additional places where
the standardized dialogs should be used. Also fixed remaining places
where these dialogs are used but the parent widget was still being
explicitly set to be the text widget, which is now the default.

(should be easy to apply both patches in any order without conflicts)

Added file: http://bugs.python.org/file9396/IDLE_standardize_dialogs.080209_2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Sat Feb  9 13:05:13 2008
From: report at bugs.python.org (stocker81)
Date: Sat, 09 Feb 2008 12:05:13 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1202558713.4.0.348038765207.issue2051@psf.upfronthosting.co.za>


stocker81 added the comment:

Christian Heimes <report at bugs.python.org> wrote: 
> I haven't removed it from the listing. Look under priority "high" a few
> pages up.
> 

I'm sorry, my mistake.

Regards,
Marcin

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Sat Feb  9 14:18:20 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Feb 2008 13:18:20 -0000
Subject: [issue2012] Add migration step for DictMixin ->
	collections.MutableMapping
In-Reply-To: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>
Message-ID: <1202563100.26.0.0188199047994.issue2012@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Perhaps the best we can do is a warning from the DictMixin constructor
in 2.6 when the -3 flag is specified?

----------
nosy: +ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2012>
__________________________________

From report at bugs.python.org  Sat Feb  9 14:21:46 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Feb 2008 13:21:46 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202563306.21.0.909880138976.issue2021@psf.upfronthosting.co.za>


Changes by Nick Coghlan:


----------
assignee:  -> ncoghlan
nosy: +ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Sat Feb  9 15:52:41 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 09 Feb 2008 14:52:41 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202568761.08.0.906645485996.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Guido:

> Correct -- the thing is that you can't know the signature of the
> subclass's constructor so you can't very well blindly call that.

Jeffrey, is it okay for me to change the three class methods 
(from_float, from_decimal, from_continued_fraction) to static methods, 
and call Rational instead of cls as the constructor?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  9 16:32:02 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Feb 2008 15:32:02 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202571122.52.0.695871006547.issue2021@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've changed the issue type from rfe to behaviour. NamedTemporaryFile
actually provides __enter__ and __exit__ methods in 2.5, they just don't
work (it tries to use the methods from the underlying file object
directly which turns out to be a doomed exercise for a couple of
different reasons).

Fixed on the trunk in r60695. Leaving issue as pending until the
NamedTemporaryFile fix is backported to 2.5 (or we decide not to
backport it).

P.S. Alexander's patch worked as written, but in figuring out *why* it
worked I ended up moving things around a bit (main change was to only
override __exit__ when it was actually necessary to do so) and adding
some more test cases (e.g. to also cover 2.6's new SpooledTemporaryFile).

----------
resolution:  -> fixed
status: open -> pending
type: rfe -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Sat Feb  9 16:44:19 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Feb 2008 15:44:19 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>
Message-ID: <1202571859.56.0.617326943007.issue1706@psf.upfronthosting.co.za>


Changes by Nick Coghlan:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 16:51:49 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Feb 2008 15:51:49 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>
Message-ID: <1202572309.46.0.0763220756464.issue1706@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I thought WINVER defaulted to something like 0x0400 (i.e. you can't use
things specifically defined for even Win2k without setting it, let alone
things first defined for XP).

I know I had to force it to 0x0500 recently for a non-Python project to
get access to the function that permits a non-blocking attempt to
acquire a critical section. That project is stuck using VC6 though -
current MS compilers may default it to something more recent.

----------
nosy: +ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 17:31:35 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Sat, 09 Feb 2008 16:31:35 -0000
Subject: [issue2055] test_fcntl.py converted to unittest
In-Reply-To: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za>
Message-ID: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

In attachment. All existing tests are unchanged.

----------
components: Tests
files: test_fcntl.diff
messages: 62225
nosy: facundobatista, giampaolo.rodola, tiran
severity: normal
status: open
title: test_fcntl.py converted to unittest
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9397/test_fcntl.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2055>
__________________________________

From report at bugs.python.org  Sat Feb  9 17:36:11 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Feb 2008 16:36:11 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>
Message-ID: <1202574971.0.0.304181589338.issue1706@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I just checked the current PC/pyconfig.h: with the current settings in
that file, the core is already limited to using NT4 compatible Win32 API
calls. Unless the specific source file takes steps to override it (i.e.
setting WINVER before including python.h), no Win2k or XP API calls
should be permitted outside the 64-bit builds (as those only became
possible with the advent of 64-bit support in XP, they set WINVER to
0x0501).

The reason this didn't avoid the Tcl/Tk problem is because the actual
setting of WINVER and _WIN32_WINNT is guarded by the Py_BUILD_CORE
preprocessor definition - which isn't set for separately built extension
modules like _tkinter.

Would setting these by default for extension modules (i.e. removing the
Py_BUILD_CORE guard) really be such a bad thing? The individual #ifdef
guards would still be there to allow extension module authors to
override it if they know what they're doing, but the default behaviour
would be to require that extension modules be compatible with every
version of Windows that that particular version of Python is compatible
with.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 17:37:30 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 09 Feb 2008 16:37:30 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1202536014.59.0.571008898672.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802090837r2ea9530audb194c85a2dabcd8@mail.gmail.com>


Guido van Rossum added the comment:

Jeffrey:

Yay for measurements!

I was going to say that __add__ is inefficient because it makes so
many function calls, but it turns out that, as you say, the cost of
constructing a new Rational instance drowns everything else. On my
2.8GHz iMac, Rational(2,3) costs ~80 usec. This goes down to 50 usec
if I make it inherit from object -- the ABC machinery costs 30 usecs!
If I then also comment out all the typechecking of numerator and
denominator and go straight into the gcd(), the constructor costs go
down to 6 (six!) usecs. Beyond that it's slim pickings; replacing
super() with object or inlining gcd wins perhaps half an usec. But
once the constructor is down to 5-6 usec, the half usec for going
through the constructor (times 6 for 6 constructor calls in _add()!)
might be a significant gain to also try and inline the common case of
the binary operators.

In the mean time I have two recommendations if you want to make the
constructor faster without losing functionality: (a) remove the direct
inheritance from RationalAbc (using virtual inheritance instead); (b)
special-case the snot out of the common path in the constructor
(called with two ints).

An alternative might be to have a private class or static method to
construct a  Rational from two ints that is used internally; it could
use object.__new__ instead of super() so as to save the ABC overhead.
But I'm not sure if this will always work.

Unrelated issue: I just realized for the first time that we have two
classes named 'Rational': the ABC and the concrete implementation.
That's going to be awfully confusing. Perhaps it's not too late to
rename rational.py/Rational to fractions.py/Fraction?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  9 17:44:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Feb 2008 16:44:10 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>
Message-ID: <1202575450.89.0.333063744999.issue1706@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The defaulting of WINVER is indeed a compiler things; the problems
started when we moved to VS 2008 (so VC6 would certainly have a
different default).

Setting WINVER for extension modules wouldn't have helped with the Tcl
problem: Tcl/Tk itself gets compiled independent of Python -
Py_BUILD_CORE had no effect here. It *does* have effect on _tkinter,
since _tkinter is part of Py_BUILD_CORE.

Setting WINVER for all extension modules would be bad style. Some
modules may fail to compile - it's up to the module author to decide
what API level to build against.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 18:09:58 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 09 Feb 2008 17:09:58 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>
Message-ID: <1202576998.8.0.75392686274.issue1706@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Given that whether or not Py_BUILD_CORE is defined flips the direction
of the DLL exports/import for the main python DLL, I don't see how it
could be defined for the separately compiled extension modules like
_tkinter, _sqlite3, _ctypes, _socket, _ssl, etc.

As far as I can tell (not having a VS2008 installation set up), that
means the build process for those other DLLs is currently going to be
using whatever setting for WINVER and _WIN32_WINNT the compiler decides
to provide.

Perhaps it would be worth having an additional Py_SET_WINVER definition
to make it easy for an extension module to request that Python set those
two values? And then set that for the modules that are part of the
normal Windows build?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 18:27:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Feb 2008 17:27:54 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1202576998.8.0.75392686274.issue1706@psf.upfronthosting.co.za>
Message-ID: <47ADE297.9060800@v.loewis.de>


Martin v. L?wis added the comment:

> Given that whether or not Py_BUILD_CORE is defined flips the direction
> of the DLL exports/import for the main python DLL, I don't see how it
> could be defined for the separately compiled extension modules like
> _tkinter, _sqlite3, _ctypes, _socket, _ssl, etc.

You are right, it's not.

As you found, the original issue reported here could be closed:
WINVER *is* already defined in pyconfig.h. I'm still -1 for defining
it generally. So to define WINVER for the extension modules that
are part of the core, it would be best to define it in pyd.vsprops,
and pyd_d.vsprops, not in a header file.

Regards,
Martin

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 19:17:45 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 09 Feb 2008 18:17:45 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <47ADE297.9060800@v.loewis.de>
Message-ID: <47ADEE37.30203@cheimes.de>


Christian Heimes added the comment:

Martin v. L?wis wrote:
> As you found, the original issue reported here could be closed:
> WINVER *is* already defined in pyconfig.h. I'm still -1 for defining
> it generally. So to define WINVER for the extension modules that
> are part of the core, it would be best to define it in pyd.vsprops,
> and pyd_d.vsprops, not in a header file.

I require WINVER set to Win2k for patch #1763
(os.path.get_shellfolders()). The necessary API methods aren't declared
for the standard WINVER.

What do you think about a new macro Py_BUILD_CORE_MODULE for the pyd
property file?

#if defined(Py_BUILD_CORE) || defined(Py_BUILD_CORE_MODULE)
#define NTDDI_VERSION NTDDI_WIN2KSP4
#define WINVER 0x0500
#define _WIN32_WINNT WINVER
#endif

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 19:21:13 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 09 Feb 2008 18:21:13 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1202572309.46.0.0763220756464.issue1706@psf.upfronthosting.co.za>
Message-ID: <47ADEF12.60405@cheimes.de>


Christian Heimes added the comment:

Nick Coghlan wrote:
> I know I had to force it to 0x0500 recently for a non-Python project to
> get access to the function that permits a non-blocking attempt to
> acquire a critical section. That project is stuck using VC6 though -
> current MS compilers may default it to something more recent.

I assume they don't. I wasn't able to access a Win2k+ API method with
VS2008.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 19:37:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 09 Feb 2008 18:37:27 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>
Message-ID: <1202582247.04.0.684434190062.issue1706@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Ah, so you propose raise WINVER, compared to what it is currently; I now
eventually understand this issue.

Raising it to 0x0500 is fine with me. Please add a note to PEP 11 that
NT 4 and older won't be supported anymore from 2.6 on. NT4 extended
support ended on 31.12.2004, so we probably don't need a phase with
advance warnings.

+1 on Py_BUILD_CORE_MODULE.

----------
assignee: loewis -> tiran
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 21:25:48 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 09 Feb 2008 20:25:48 -0000
Subject: [issue2012] Add migration step for DictMixin ->
	collections.MutableMapping
In-Reply-To: <1202175151.59.0.0678613282425.issue2012@psf.upfronthosting.co.za>
Message-ID: <1202588748.19.0.48648906311.issue2012@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

We should hold off on this one for a bit until I can get feedback on 
whether UserDict, UserString, and UserList should all be in the same 
place (in the own modules or rolled into collections).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2012>
__________________________________

From report at bugs.python.org  Sat Feb  9 21:42:39 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 09 Feb 2008 20:42:39 -0000
Subject: [issue1706] Force WINVER 0x0500 (Windows 2000)
In-Reply-To: <1198848122.63.0.86389332394.issue1706@psf.upfronthosting.co.za>
Message-ID: <1202589759.66.0.513609545651.issue1706@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Applied in r60695 (trunk).

I've updated the PEP, too.

----------
resolution: accepted -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706>
__________________________________

From report at bugs.python.org  Sat Feb  9 21:59:57 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 09 Feb 2008 20:59:57 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202590797.91.0.632605848191.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Mark: Coming from C++, I don't have any intuition on static vs. class
methods. It might be strange to write MyRationalSubclass.from_float()
and get a Rational back, but it might also be strange to write a
subclass with a different constructor and get an error. So go ahead.

Guido: It would be a shame to decide that classes shouldn't inherit from
ABCs for performance reasons. Issue 1762 tracks the problem, but I
haven't paid much attention to it. Let's see if we can fix that before
using virtual inheritance for Rational. Special-casing ints in the
constructor sounds like a good idea, and we can cache the results of
.numerator and .denominator in _add, etc, without having to change the
overall logic, which should save 2?s (leaving 1 on the table).

It could be useful to declare a private constructor that expects ints
that are already in lowest terms, sort of like
decimal._dec_from_triple(). __add__ couldn't use it directly, but
__abs__ could.

I don't think it's too late to rename one of the classes. I'm using
"RationalAbc" inside of rational.py to refer to numbers.Rational, which
is one reason I was positive on adding a suffix to the ABCs, but
renaming this class is fine with me too.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sat Feb  9 22:43:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 09 Feb 2008 21:43:02 -0000
Subject: [issue2055] test_fcntl.py converted to unittest
In-Reply-To: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za>
Message-ID: <1202593382.45.0.167558654157.issue2055@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I converted this for GHOP:
http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=292&can=1&q=completed&colspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summary&start=100

----------
nosy: +gutworth

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2055>
__________________________________

From report at bugs.python.org  Sun Feb 10 00:02:28 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 09 Feb 2008 23:02:28 -0000
Subject: [issue1762] Inheriting from ABC slows Decimal down.
In-Reply-To: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
Message-ID: <1202598148.62.0.43095829707.issue1762@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I measured various implementations of __instancecheck__ using
`./python.exe -m timeit -s 'from rational import Rational; r =
Rational(3, 2)' '...'` on my 2.33 GHz MacBook, with ... replaced by
either isinstance(r, Rational) or isinstance(3, Rational) to measure
both the positive and negative cases. The big win comes from avoiding
the genexp and the set. Then we win smaller amounts by being more
careful about avoiding extra calls to __subclasscheck__ and by inlining
the cache checks.

# Current code
    return any(cls.__subclasscheck__(c)
               for c in set([instance.__class__, type(instance)]))
isinstance(3, Rational): 4.65 usec
isinstance(r, Rational): 7.47 usec

# The best we can do simply in Python
    return cls.__subclasscheck__(instance.__class__)
isinstance(3, Rational): 2.08 usec
isinstance(r, Rational): 1.72 usec

# Preserve behavior, simply
    return (cls.__subclasscheck__(instance.__class__) or
            cls.__subclasscheck__(type(instance)))
isinstance(3, Rational): 3.03 usec
isinstance(r, Rational): 1.8 usec

# Preserve behavior, complexly
    ic = instance.__class__
    if cls.__subclasscheck__(ic):
        return True
    t = type(instance)
    return t is not ic and cls.__subclasscheck__(t)
isinstance(3, Rational): 2.38 usec
isinstance(r, Rational): 1.86 usec

# Inlined for new-style classes
    subclass = instance.__class__
    if subclass in cls._abc_cache:
        return True
    type_ = type(instance)
    if type_ is subclass:
        if (cls._abc_negative_cache_version ==
            ABCMeta._abc_invalidation_counter and
            subclass in cls._abc_negative_cache):
            return False
        return cls.__subclasscheck__(subclass)
    return (cls.__subclasscheck__(subclass) or
            cls.__subclasscheck__(type_))
isinstance(3, Rational): 2.26 usec
isinstance(r, Rational): 1.49 usec

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________

From report at bugs.python.org  Sun Feb 10 00:05:20 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 09 Feb 2008 23:05:20 -0000
Subject: [issue1700463] VC6 build patch for trunk
Message-ID: <1202598320.18.0.479293369239.issue1700463@psf.upfronthosting.co.za>


Hirokazu Yamamoto added the comment:

Please don't apply this patch now.
VC6 build fails from rev.60696

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1700463>
_____________________________________

From report at bugs.python.org  Sun Feb 10 01:18:22 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 10 Feb 2008 00:18:22 -0000
Subject: [issue1762] Inheriting from ABC slows Decimal down.
In-Reply-To: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
Message-ID: <1202602702.97.0.748949857787.issue1762@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Whoa!  I thought we had arrived at a decision to leave decimal alone.  
Please do not infect this module with numbers.py.

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________

From report at bugs.python.org  Sun Feb 10 03:05:46 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Sun, 10 Feb 2008 02:05:46 -0000
Subject: [issue2056] install command rejects --compiler option
In-Reply-To: <1202609145.39.0.17652822204.issue2056@psf.upfronthosting.co.za>
Message-ID: <1202609145.39.0.17652822204.issue2056@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom:

The install command returns the following error when the --compiler
option is provided on the command line:

>python setup.py install --compiler=mingw32
usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: option --compiler not recognized

This is problematic on Windows when MinGW is being used in place of
Visual C. A package can be built with --compiler=mingw32, but if no
compiler is specified for install the following error occurs:

>python setup.py install
running install
running build
running build_py
running build_ext
error: Python was built with Visual Studio 2003;
extensions must be built with a compiler than can generate compatible
binaries.
Visual Studio 2003 was not found on this system. If you have Cygwin
installed,
you can try compiling with MingW32, by passing "-c mingw32" to setup.py.


The work-around is to specify compiler=mingw32 in a setup.cfg file under
a [build] or [build_ext] heading. But this would be inconvenient for
someone who has both Visual C and MinGW and wants to choose.

----------
components: Distutils
messages: 62241
nosy: kermode
severity: normal
status: open
title: install command rejects --compiler option
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2056>
__________________________________

From report at bugs.python.org  Sun Feb 10 03:12:43 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 10 Feb 2008 02:12:43 -0000
Subject: [issue1763] Winpath module - easy access to Windows directories like
	My Documents
In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za>
Message-ID: <1202609563.17.0.938695272668.issue1763@psf.upfronthosting.co.za>


Hirokazu Yamamoto added the comment:

Sorry for interruption. I'm a little doubtful this is really needed.
We can get "My Documents" path by following 5 lines of code.

import ctypes

dll = ctypes.windll.shell32
buf = ctypes.create_string_buffer(300)
dll.SHGetSpecialFolderPathA(None, buf, 0x0005, False)
print buf.value

And if this patch goes in, I'm using clipboard in my several python
scripts, is it also possible to add clipboard support?
(I implemented ocean/clipboard.py under PYTHONPATH and now using it
personally)

# And, well, r60696 blocks me from building python on VC6, if this change
# (WINVER = 0x500) is required for this issue only, I'm happy if this
# would be reverted but... I cannot claim it loudly. I'm using win2000,
# and latest free compiler doesn't support it :-(

----------
nosy: +ocean-city

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1763>
__________________________________

From report at bugs.python.org  Sun Feb 10 05:51:44 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 10 Feb 2008 04:51:44 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202619104.93.0.171767486571.issue2016@psf.upfronthosting.co.za>


Changes by Gregory P. Smith:


----------
nosy: +gregory.p.smith

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Sun Feb 10 07:48:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Feb 2008 06:48:27 -0000
Subject: [issue2056] install command rejects --compiler option
In-Reply-To: <1202609145.39.0.17652822204.issue2056@psf.upfronthosting.co.za>
Message-ID: <1202626107.94.0.277608071968.issue2056@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Could you try whether

setup.py build --compiler=mingw32 install

works?

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2056>
__________________________________

From report at bugs.python.org  Sun Feb 10 08:32:52 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Sun, 10 Feb 2008 07:32:52 -0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

difflib alone and bundled Tools\Scripts\diff.py utility are both very
useful, esp. on windows platforms where standard unix diffutils are
absent. However, python difflib still doesn't have a patch counterpart
to apply at least unified diff format.

----------
components: Demos and Tools
messages: 62244
nosy: techtonik
severity: normal
status: open
title: difflib: add patch capability
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
__________________________________

From report at bugs.python.org  Sun Feb 10 08:37:03 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Sun, 10 Feb 2008 07:37:03 -0000
Subject: [issue2056] install command rejects --compiler option
In-Reply-To: <1202609145.39.0.17652822204.issue2056@psf.upfronthosting.co.za>
Message-ID: <1202629023.4.0.464702013491.issue2056@psf.upfronthosting.co.za>


Lenard Lindstrom added the comment:

Yes, "setup.py build --compiler=mingw32 install" works. It is good
enough for me.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2056>
__________________________________

From report at bugs.python.org  Sun Feb 10 09:12:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Feb 2008 08:12:00 -0000
Subject: [issue2056] install command rejects --compiler option
In-Reply-To: <1202609145.39.0.17652822204.issue2056@psf.upfronthosting.co.za>
Message-ID: <1202631120.76.0.941849336858.issue2056@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2056>
__________________________________

From report at bugs.python.org  Sun Feb 10 10:26:10 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 10 Feb 2008 09:26:10 -0000
Subject: [issue1762] Inheriting from ABCs makes classes slower.
In-Reply-To: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
Message-ID: <1202635570.92.0.926474539906.issue1762@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Right. Decimal was just the place I noticed the problem first. Now it
affects Rational more, but it's really a problem with ABCs in general,
not specific concrete classes.

----------
title: Inheriting from ABC slows Decimal down. -> Inheriting from ABCs makes classes slower.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________

From report at bugs.python.org  Sun Feb 10 10:48:33 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 10 Feb 2008 09:48:33 -0000
Subject: [issue1736] Three bugs of FCICreate (PC/_msi.c)
In-Reply-To: <1199458428.92.0.688794479817.issue1736@psf.upfronthosting.co.za>
Message-ID: <1202636913.56.0.157262245589.issue1736@psf.upfronthosting.co.za>


Hirokazu Yamamoto added the comment:

Refactored a little. More clean diff.

Added file: http://bugs.python.org/file9398/_msi.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736>
__________________________________

From report at bugs.python.org  Sun Feb 10 12:44:03 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Sun, 10 Feb 2008 11:44:03 -0000
Subject: [issue2058] reduce tarfile memory footprint
In-Reply-To: <1202643843.0.0.134352659823.issue2058@psf.upfronthosting.co.za>
Message-ID: <1202643843.0.0.134352659823.issue2058@psf.upfronthosting.co.za>


New submission from Lars Gust?bel:

tarfile.py wastes lots of memory resources. The memory consumption does
not depend on the size of an archive but on the numbers of members in it.
The attached patch reduces memory usage by about 60% and consists of two
independent strategies (each with about 30% reduction):

1. Add __slots__ to the TarInfo class. This was proposed in issue1540385
a while ago but rejected due to backward-compatibility issues.

2. Remove the undocumented buf attribute of the TarInfo class. buf
stores the original 512-byte header block read from the archive. This
was introduced in r45954 and is rather useless except for GNUTYPE_SPARSE
processing. This might as well be a candidate for backporting to 2.6.

----------
assignee: lars.gustaebel
components: Library (Lib)
files: tarfile-memory.diff
keywords: patch
messages: 62248
nosy: lars.gustaebel
priority: normal
severity: normal
status: open
title: reduce tarfile memory footprint
type: resource usage
versions: Python 3.0
Added file: http://bugs.python.org/file9399/tarfile-memory.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2058>
__________________________________

From report at bugs.python.org  Sun Feb 10 16:36:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2008 15:36:44 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202657804.49.0.713422264312.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

staticmethod substituted for classmethod in r60712.

I'm not sure I like the idea of names Rational and Fraction;  the two 
classes numbers.Rational and rational.Rational are quite different beasts, 
and using two almost-synonyms for their names seems like a bad idea.
Is there some more descriptive name for numbers.Rational that might give a 
hint of its ABC-ness?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 16:55:40 2008
From: report at bugs.python.org (Ilya Sandler)
Date: Sun, 10 Feb 2008 15:55:40 -0000
Subject: [issue2059] OptionMenu class is defined both in Tkinter and Tix
In-Reply-To: <1202658940.12.0.289973757596.issue2059@psf.upfronthosting.co.za>
Message-ID: <1202658940.12.0.289973757596.issue2059@psf.upfronthosting.co.za>


New submission from Ilya Sandler:

Given that Tix imports all names from Tkinter this is likely to result
in confusion.

E.g.

>>> from Tix import *
>>> print Button
Tkinter.Button
>>> print OptionMenu
Tix.OptionMenu

To get to Tkinter's OptionMenu, one needs to do something like

import Tkinter
Tkinter.OptionMenu

----------
components: Library (Lib)
messages: 62250
nosy: isandler
severity: normal
status: open
title: OptionMenu class is defined both in Tkinter and Tix
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2059>
__________________________________

From report at bugs.python.org  Sun Feb 10 16:55:48 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2008 15:55:48 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202658948.84.0.506524381365.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

We still need to sort out the trim/approximate/convergents decisions.

Currently, we have:

  from_continued_fraction
  to_continued_fraction
  approximate (what we've been calling trim: limit the denominator)

At this point I'm not sure how much I care about what is or is not 
included, but here are a few thoughts:

(1) if to_continued_fraction is kept it should be a generator instead of 
returning a list.
(2) from_continued_fraction would be better replaced by convergents, 
since a user is just as (more?) likely to be interested in the whole 
sequence of convergents than just the final convergent.  If 
from_continued_fraction is kept in addition to convergents then it 
should work forwards instead of backwards, so that it doesn't need to 
use reversed (and hence works on the output of to_continued_fraction).
(3) approximate needs finishing up and possibly renaming to trim.

Can we remove {from,to}_continued_fraction and just leave trim?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 17:19:20 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Feb 2008 16:19:20 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1202657804.49.0.713422264312.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802100819n1ab4dda7n31d0062d65ad455@mail.gmail.com>


Guido van Rossum added the comment:

> I'm not sure I like the idea of names Rational and Fraction;  the two
> classes numbers.Rational and rational.Rational are quite different beasts,
> and using two almost-synonyms for their names seems like a bad idea.
> Is there some more descriptive name for numbers.Rational that might give a
> hint of its ABC-ness?

I'd rather not change the Rational ABC's name -- it is the
mathematically accepted term (Complex, Real, Rational, Integer, and
then natural numbers I believe). I'd rather not add a suffix or prefix
like A or Abc to the ABCs either. To be honest, we have a rather
hodge-podge of mappings from numeric ABCs to concrete implementations:
Complex/complex, Real/float, Rational/?, Integer/int. I think that,
given that fraction is the *common* name for rationals (see
wikipedia), it fits relatively well. We can introduce fractions
without ever mentioning the ABCs and users will immediately know what
they mean even if they haven't got more than grade school math.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 17:53:09 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2008 16:53:09 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202662389.4.0.989245132651.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Fair enough.  Should it be fractions.Fraction or fraction.Fraction?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 18:04:52 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Feb 2008 17:04:52 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1202662389.4.0.989245132651.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802100904w1e928addvcaabdba658c6789e@mail.gmail.com>


Guido van Rossum added the comment:

> Fair enough.  Should it be fractions.Fraction or fraction.Fraction?

I think "from fractions import Fraction" is linguistically more
correct -- the concept is always mentioned in plural, but a fractional
number is of course singular.  We also have "numbers".

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 19:25:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 10 Feb 2008 18:25:02 -0000
Subject: [issue2059] OptionMenu class is defined both in Tkinter and Tix
In-Reply-To: <1202658940.12.0.289973757596.issue2059@psf.upfronthosting.co.za>
Message-ID: <1202667902.41.0.366052125756.issue2059@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

What is the issue that you are reporting here? There is nothing wrong
with two classes having the same name, AFAICT. That's what modules are for.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2059>
__________________________________

From report at bugs.python.org  Sun Feb 10 21:05:24 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2008 20:05:24 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202673924.77.0.104094510892.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Any reason not to make the name change?  Is further discussion/time 
required, or can we go ahead and rename Rational to Fraction and 
rational.py to fractions.py?  It seems like everybody's happy with the 
idea.

I note that the name change affects Lib/test/test_builtin.py as well as 
Doc/whatsnew/2.6.rst.  Any other non-obvious places that I've missed?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 21:20:40 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 10 Feb 2008 20:20:40 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.
In-Reply-To: <1202673924.77.0.104094510892.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802101220v345c3002k1fa826d79162ae38@mail.gmail.com>


Guido van Rossum added the comment:

Go for it!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 22:31:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 10 Feb 2008 21:31:05 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202679065.31.0.0192705001496.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Name change in r60721.

----------
title: Move Demo/classes/Rat.py to Lib/rational.py and fix it up. -> Move Demo/classes/Rat.py to Lib/fractions.py and fix it up.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Sun Feb 10 22:41:48 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 10 Feb 2008 21:41:48 -0000
Subject: [issue1581906] test_sqlite fails on OSX G5 arch if test_ctypes is run
Message-ID: <1202679708.85.0.920717351855.issue1581906@psf.upfronthosting.co.za>


Skip Montanaro added the comment:

I'm reopening this.  I am seeing the same behavior now on my
MacBook Pro running Mac OS X 10.5.1.  Looking at the crash report
in my ~/Library/Logs/CrashReporter directory I see both /usr/lib
and /opt/local/lib versions of libsqlite3:

 0x1188000 -  0x11defef +libsqlite3.0.dylib ??? (???)
/opt/local/lib/libsqlite3.0.dylib
0x911f6000 - 0x9127dff7  libsqlite3.0.dylib ??? (???)
<273efcb717e89c21207c851d7d33fda4> /usr/lib/libsqlite3.0.dylib

I was able to work around this by disabling the MacPorts version of
sqlite3.  Others might not be so lucky.  I don't see any references
to sqlite in the ctypes test code.  Must be an indirect reference.

Skip

----------
resolution: fixed -> 
status: closed -> open

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1581906>
_____________________________________

From report at bugs.python.org  Sun Feb 10 23:15:30 2008
From: report at bugs.python.org (Eduardo Padoan)
Date: Sun, 10 Feb 2008 22:15:30 -0000
Subject: [issue2060] python2.6 -3 gives "warning: callable() not supported in
	3.x" on startup
In-Reply-To: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>
Message-ID: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>


New submission from Eduardo Padoan:

Running python2.6 with the -3 option, you get 6 warnings about callable():

edcrypt at DEADBEEF:~/dev/svn/python2.6$ python2.6 -3
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
warning: callable() not supported in 3.x
Python 2.6a0 (trunk:60717, Feb 10 2008, 19:53:48) 
[GCC 4.2.3 (Ubuntu 4.2.3-1ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>>

----------
components: Interpreter Core
messages: 62260
nosy: eopadoan
severity: minor
status: open
title: python2.6 -3 gives "warning: callable() not supported in 3.x" on startup
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2060>
__________________________________

From report at bugs.python.org  Sun Feb 10 23:29:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 10 Feb 2008 22:29:10 -0000
Subject: [issue2060] python2.6 -3 gives "warning: callable() not supported in
	3.x" on startup
In-Reply-To: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>
Message-ID: <1202682550.4.0.922547802103.issue2060@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

On my Mac, I also get about 30 warnings about dict.has_key. By the way,
what are you supposed you use in py3k instead of callable?

----------
nosy: +gutworth

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2060>
__________________________________

From report at bugs.python.org  Sun Feb 10 23:34:31 2008
From: report at bugs.python.org (Eduardo Padoan)
Date: Sun, 10 Feb 2008 22:34:31 -0000
Subject: [issue2060] python2.6 -3 gives "warning: callable() not supported in
	3.x" on startup
In-Reply-To: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>
Message-ID: <1202682871.84.0.425133149376.issue2060@psf.upfronthosting.co.za>


Eduardo Padoan added the comment:

> By the way, what are you supposed you use in py3k instead of callable?

Either "try: foo(); except TypeError: ...", or "if hasattr(foo,
'__call__'): foo()".

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2060>
__________________________________

From report at bugs.python.org  Sun Feb 10 23:46:06 2008
From: report at bugs.python.org (Tal Einat)
Date: Sun, 10 Feb 2008 22:46:06 -0000
Subject: [issue2061] IDLE - autocompletion to support alternate patch
	separators
In-Reply-To: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>
Message-ID: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>


New submission from Tal Einat:

This patch makes the auto-completion of file names support possible
alternate separator characters (e.g. '/' in windows).

----------
components: IDLE
files: IDLE_AutoComplete_path_separators.080211.patch
messages: 62263
nosy: kbk, taleinat
severity: minor
status: open
title: IDLE - autocompletion to support alternate patch separators
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9400/IDLE_AutoComplete_path_separators.080211.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2061>
__________________________________

From report at bugs.python.org  Sun Feb 10 23:57:19 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 10 Feb 2008 22:57:19 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202684239.02.0.936572888364.issue2021@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Nick's comment made me think why NamedTemporaryFile can't simply 
subclass file and get properly working context manager's methods for 
free.

It turned out that although file is subclassable, in its present form, 
it does not allow NamedTemporaryFile implementation for the following 
reasons:

1. os.fdopen cannot create a subclass of file.

2. file.__exit__ does not call subclass' close method.

The attached patch fixes both issues and reimplements NamedTemporaryFile.

I understand that adding new functionality to file objects should be 
brought up on python-dev, but I would like to hear comments from the 
"nosy list" first.

The patch is proof-of-concept quality at the moment and may not work 
non-posix platforms.

Added file: http://bugs.python.org/file9401/subclass-file.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Mon Feb 11 00:36:54 2008
From: report at bugs.python.org (Tal Einat)
Date: Sun, 10 Feb 2008 23:36:54 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>


New submission from Tal Einat:

Improve the code in AutoCompleteWindow._complete_string to be more
efficient.

(this is to be followed up by a more extensive patch, which builds on
this change to support case-insensitive completion)

----------
components: IDLE
files: IDLE_AutoComplete_complete_string_optimization.080211.patch
messages: 62265
nosy: kbk, taleinat
severity: minor
status: open
title: IDLE - autocompletion logic optimization
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9402/IDLE_AutoComplete_complete_string_optimization.080211.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Mon Feb 11 01:04:14 2008
From: report at bugs.python.org (Tal Einat)
Date: Mon, 11 Feb 2008 00:04:14 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202688254.37.0.860951224326.issue2062@psf.upfronthosting.co.za>


Tal Einat added the comment:

Found two more instances in the code where a similar improvement can be
made. This (second) version of the patch is more consistent, please use
it instead of the initial version.

Added file: http://bugs.python.org/file9403/IDLE_AutoComplete_complete_string_optimization.080211.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Mon Feb 11 01:40:20 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 11 Feb 2008 00:40:20 -0000
Subject: [issue2015] Possible optimisations in kwargs handling
In-Reply-To: <1202258715.2.0.486542039944.issue2015@psf.upfronthosting.co.za>
Message-ID: <1202690420.61.0.808725841761.issue2015@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Amaury, you may take a look at the patch in issue #1819.
Also, dict lookups have a big overhead compared to raw pointer compares,
I'm not sure naively converting all kwargs handling to dict lookups
would make things faster.

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2015>
__________________________________

From report at bugs.python.org  Mon Feb 11 03:28:28 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 02:28:28 -0000
Subject: [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202696908.42.0.255608188603.issue2049@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

I don't want to complicate the IDLE interface and confuse the users 
with an additional decision (or a chording keypress for the normal 
state) for this very special case (messing up a connection to a 
robot).  One of the main features of using the IDLE subprocess is a 
clean restart and reload of all code being run.

An alternate approach would be to have a config-main item which if 
set (and not settable in the Options Dialog!) would skip the Shell 
restart when running code with F5.  The user could then hit Ctrl-F6
when he did want a restart.

----------
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Mon Feb 11 03:35:52 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 02:35:52 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202697352.98.0.0292558351873.issue2062@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser:


Removed file: http://bugs.python.org/file9402/IDLE_AutoComplete_complete_string_optimization.080211.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Mon Feb 11 03:39:16 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 02:39:16 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202697556.93.0.446030633674.issue2062@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

I would greatly appreciate it if you would slow down and test your 
patches and use them for an extended period of time (preferably with 
some other people trying them) before submitting them.  It's quite 
aggravating to start working on one, and even have it checked in, only 
to have to start over again.  It doubles the work and makes me 
unwilling to address your patches.  How much time have you given the 
second version?

----------
assignee:  -> kbk

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Mon Feb 11 03:42:31 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 02:42:31 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202697751.16.0.843594768411.issue2053@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

I would greatly appreciate it if you would slow down and test your 
patches and use them for an extended period of time (preferably with 
some other people trying them) before submitting them.  It's quite 
aggravating to start working on one, and even have it checked in, only 
to have to start over again.  It doubles the work and makes me 
unwilling to address your patches.  How much time have you given the 
second version?  Deleting both patches, please provide a combination 
patch 
after you've tested it and thought about it for a few days.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Mon Feb 11 03:42:39 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 02:42:39 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202697759.91.0.122592748128.issue2053@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser:


Removed file: http://bugs.python.org/file9395/IDLE_standardize_dialogs.080209.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Mon Feb 11 03:42:44 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 02:42:44 -0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1202697764.24.0.471721231284.issue2053@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser:


Removed file: http://bugs.python.org/file9396/IDLE_standardize_dialogs.080209_2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Mon Feb 11 04:18:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 11 Feb 2008 03:18:05 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202699885.25.0.215346360883.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I just checked in another very minor change in r60723.  The repr of a 
Fraction now looks like Fraction(1, 2) instead of Fraction(1,2).  Let me 
know if this change is more controversial than I think it is.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Mon Feb 11 06:50:43 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Fritzsche?=)
Date: Mon, 11 Feb 2008 05:50:43 -0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202451338.42.0.378471584702.issue2047@psf.upfronthosting.co.za>
Message-ID: <1202709042.96.0.85918319871.issue2047@psf.upfronthosting.co.za>


Andr? Fritzsche added the comment:

Raghuram, you've been too fast ;-)

Your test matches the problem. I don't know if it happens on Linux, but
on my Win32 Installation the test 'test_destinsrc_2' fails with an 
AssertionError 'destinsrc() wrongly concluded that dst
(@test\srcdir.new) is in src (@test\srcdir)'.

Using the submitted patch everything comes out with 'Ok'.

I've appended the failing test output.

Added file: http://bugs.python.org/file9404/test_shutil_orig.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Mon Feb 11 06:56:48 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 05:56:48 -0000
Subject: [issue2039] Pymalloc patch for int and float objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1202709408.49.0.747470620038.issue2039@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The new patch adds a small free list with 80 elements each using a LIFO
implemented as an array of fixed size.

Added file: http://bugs.python.org/file9405/freelist2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
__________________________________

From report at bugs.python.org  Mon Feb 11 08:41:37 2008
From: report at bugs.python.org (Kuang-che Wu)
Date: Mon, 11 Feb 2008 07:41:37 -0000
Subject: [issue2063] os.times() utime and stime exchanged on windows
In-Reply-To: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>
Message-ID: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>


New submission from Kuang-che Wu:

According to document, os.times()[0] is process user time, [1] is system
time. However this two value was implemented exchanged on windows.

Python all versions have this issue. Attached patch is for trunk.

----------
components: Extension Modules, Windows
files: diff-win-os-times.txt
messages: 62274
nosy: kcwu
severity: normal
status: open
title: os.times() utime and stime exchanged on windows
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9406/diff-win-os-times.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2063>
__________________________________

From report at bugs.python.org  Mon Feb 11 10:31:36 2008
From: report at bugs.python.org (Kuang-che Wu)
Date: Mon, 11 Feb 2008 09:31:36 -0000
Subject: [issue1751245] Popen pipe file descriptor leak on OSError in init
Message-ID: <1202722296.79.0.740760494249.issue1751245@psf.upfronthosting.co.za>


Changes by Kuang-che Wu:


Added file: http://bugs.python.org/file9407/diff-issue1751245.txt

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751245>
_____________________________________

From report at bugs.python.org  Mon Feb 11 10:39:52 2008
From: report at bugs.python.org (Heather)
Date: Mon, 11 Feb 2008 09:39:52 -0000
Subject: [issue2064] List of Dicts problem
In-Reply-To: <1202722792.28.0.719517232523.issue2064@psf.upfronthosting.co.za>
Message-ID: <1202722792.28.0.719517232523.issue2064@psf.upfronthosting.co.za>


New submission from Heather:

I have tried both Python 2.4.4 and 2.5.1 and for both, I get the
following results when running the following code:
IDLE 1.2.1      
>>> class Style:
       stylename=''
       value=''

>>> class Widget:
       styles = {}
       def setStyle(self, stylename, value):
               style = Style()
               style.stylename = stylename
               style.value = value
               self.styles[stylename]=style

>>> class Container:
       widgets = []
       def addWidget(self, stylename, value):
               widget = Widget()
               widget.setStyle(stylename,value)
               self.widgets.append(widget)

>>> container = Container()
>>> container.addWidget('backgroundColor','red')
>>> container.widgets[0].styles['backgroundColor'].value
'red'
>>> container.addWidget('backgroundColor','blue')
>>> container.widgets[0].styles['backgroundColor'].value
'blue'
>>> container.widgets[1].styles['backgroundColor'].value
'blue'
>>> 
If I am doing something wrong here, please let me know. But it seems to
me to be an error that List.append() will overwrite existing entries
when using the code above - - 
Thank you,

-Heather

----------
components: None
messages: 62275
nosy: sunaluak
severity: major
status: open
title: List of Dicts problem
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2064>
__________________________________

From report at bugs.python.org  Mon Feb 11 11:50:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 11 Feb 2008 10:50:39 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

Since r60696, WINVER is forced to _WIN32_WINNT_WIN2K. This has two problems:
- Vs8 (and before) does not define _WIN32_WINNT_WIN2K. It should be
replaced with 0x500.
- When WINVER is set to 0x500, vc6 gives a long warning because at the
time, windows nt 5.0 was only at beta stage. Moreover, there are other
clashes between winsock.h and winsock2.h, that show up when WINVER is 0x500.

To correct this, I propose:
- To replace _WIN32_WINNT_WIN2K and similar constants by their values.
- That 0x500 is not the required value, but the *maximum* value
necessary when targeting win2k. VC6 can set it to 0x400.

I'll try a patch later tonight.

----------
components: Windows
messages: 62276
nosy: amaury.forgeotdarc
severity: normal
status: open
title: trunk version does not compile with vs8 and vc6
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Mon Feb 11 11:52:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 11 Feb 2008 10:52:37 -0000
Subject: [issue1763] Winpath module - easy access to Windows directories like
	My Documents
In-Reply-To: <1199812378.67.0.278096816271.issue1763@psf.upfronthosting.co.za>
Message-ID: <1202727157.67.0.785243917687.issue1763@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

> I'm using win2000, and latest free compiler doesn't support it :-(
I hope it does. r60696 is only about supporting win2000 when compiled
with vs9.

Building with vc6 should be corrected. I filed issue2065.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1763>
__________________________________

From report at bugs.python.org  Mon Feb 11 11:56:31 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 10:56:31 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202727391.93.0.568628518545.issue2065@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
nosy: +tiran
priority:  -> high
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Mon Feb 11 11:59:00 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Feb 2008 10:59:00 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202727540.27.0.922416998124.issue2021@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The wrapper approach has the virtue of providing easy access to the
underlying file object and its methods. That actually gets a bit more
difficult when you switch to a subclassing approach (you need to either
explicitly qualify the methods or play around with super()).

The wrapper approach also has the virtue of being a valid candidate for
backport to 2.5.2, while that is most definitely *not* the case for
making file fully subclassable. If you would like to pursue that idea
further, I suggest opening a separate issue for it.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Mon Feb 11 11:59:43 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 10:59:43 -0000
Subject: [issue2064] List of Dicts problem
In-Reply-To: <1202722792.28.0.719517232523.issue2064@psf.upfronthosting.co.za>
Message-ID: <1202727583.48.0.939036400834.issue2064@psf.upfronthosting.co.za>


Christian Heimes added the comment:

It's a classic problem for new Python developers. You have declared a
mutable object at class level. styles and widgets are the same object
for all instances of Widget and Container. You have to create them
inside the initializer.

Try

class Widget:
    def __init__(self):
        self.styles = {}

Next time please use the mailing list instead of the bug tracker to get
help.

----------
nosy: +tiran
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2064>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:00:10 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 11:00:10 -0000
Subject: [issue2063] os.times() utime and stime exchanged on windows
In-Reply-To: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>
Message-ID: <1202727610.05.0.46459495241.issue2063@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> tiran
keywords: +patch
nosy: +tiran
priority:  -> high

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2063>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:00:42 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 11:00:42 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202727642.78.0.656565528948.issue2062@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:01:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 11:01:08 -0000
Subject: [issue2061] IDLE - autocompletion to support alternate patch
	separators
In-Reply-To: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>
Message-ID: <1202727668.76.0.483451470693.issue2061@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> kbk
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2061>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:02:48 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 11:02:48 -0000
Subject: [issue2055] test_fcntl.py converted to unittest
In-Reply-To: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za>
Message-ID: <1202727768.72.0.71947545084.issue2055@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2055>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:03:22 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 11:03:22 -0000
Subject: [issue2060] python2.6 -3 gives "warning: callable() not supported in
	3.x" on startup
In-Reply-To: <1202681730.06.0.258652347172.issue2060@psf.upfronthosting.co.za>
Message-ID: <1202727802.96.0.874927741997.issue2060@psf.upfronthosting.co.za>


Christian Heimes added the comment:

IMO the warning can be removed. The 2to3 tool can easily migrate any
callable(spam) to hasattr(spam, '__call__').

----------
nosy: +tiran
priority:  -> normal
type:  -> rfe

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2060>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:03:36 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 11 Feb 2008 11:03:36 -0000
Subject: [issue2057] difflib: add patch capability
In-Reply-To: <1202628772.22.0.236434867196.issue2057@psf.upfronthosting.co.za>
Message-ID: <1202727816.81.0.185242863167.issue2057@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
priority:  -> low

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2057>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:07:21 2008
From: report at bugs.python.org (Tal Einat)
Date: Mon, 11 Feb 2008 11:07:21 -0000
Subject: [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202728041.48.0.179927416754.issue2049@psf.upfronthosting.co.za>


Tal Einat added the comment:

I agree that the interface should be kept as simple as possible, but
this is a meaningful and important addition, which will help clarify to
the users how to work with the subprocess. The point of this change is
avoid surprising the user, while also making the interface more
straightforward and consistent.


The major usage issues that this patch addresses, as I see them, are:

1. New users are surprised and aggravated when they first use 'Run
Module', because they weren't expecting the shell to be restarted,
causing them to lose a lot of work done before the restart. This also
happens to experienced users sometimes (accidents happen) and can be
very frustrating. I don't think the 'normal state' should be to restart
the shell, rather this should always be explicitly requested by the user.

2. When working with a subprocess, there is no (simple) way to just run
the module in the shell without restarting it.

3. Inconsistency in the functionality of 'Run Module' depending on
whether you have a subprocess.


The problem with the configuration option approach is that if you
configure 'Run Module' to not restart, then restarting requires:
switching to the Shell window, restarting, switching back to the editor
window, and running the module: 4 actions instead of one.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:58:54 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Mon, 11 Feb 2008 11:58:54 -0000
Subject: [issue2066] Adding new CNS11643 support, a *huge* charset,
	in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>


New submission from Hye-Shik Chang:

This patch adds CNS11643 support into Python unicode codecs.
CNS11643 is a huge character which is used in EUC-TW and ISO-2022-CN.
CJKCodecs have had the CNS11643 support for 4 years at least,
but I dropped it because of its huge size in integrating into Python.
EUC-TW and ISO-2022-CN aren't being used widely while they are
still regarded as part of major encodings yet.

In my patch, disabling the CNS11643 charset support is possible by
adding -DNO_CNS11643 in CFLAGS for light platforms. Mapping source
code size of the charset is 900K and it adds about 350K into
_codecs_tw.so (in POSIX) or python26.dll (in Win32).

What do you think about adding this code?

----------
components: Unicode
files: cns11643-r1.diff.gz
messages: 62282
nosy: hyeshik.chang
priority: low
severity: normal
status: open
title: Adding new CNS11643 support, a *huge* charset, in cjkcodecs
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9408/cns11643-r1.diff.gz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Mon Feb 11 12:59:25 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Mon, 11 Feb 2008 11:59:25 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202731165.89.0.123741388019.issue2066@psf.upfronthosting.co.za>


Changes by Hye-Shik Chang:


----------
title: Adding new CNS11643 support, a *huge* charset, in cjkcodecs -> Adding new CNS11643, a *huge* charset, support in cjkcodecs

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Mon Feb 11 13:15:18 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 11 Feb 2008 12:15:18 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202732118.02.0.475165314739.issue2066@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

How often would this character set be needed ?

In any case, using a (pre)compiler switch is not a good idea. Please add
support to enable/disable the support via a configure switch.

----------
nosy: +lemburg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Mon Feb 11 13:15:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 11 Feb 2008 12:15:54 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202732154.29.0.0401242713226.issue2066@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

In this case let's put the cjkcodecs modules in their own
DLL(s) on win32.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Mon Feb 11 13:56:58 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 11 Feb 2008 12:56:58 -0000
Subject: [issue2021] Turn NamedTemporaryFile into a context manager
In-Reply-To: <1202314464.32.0.648730265908.issue2021@psf.upfronthosting.co.za>
Message-ID: <1202734618.56.0.964458538053.issue2021@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Backported to 2.5 in r60728

P.S. To elaborate a bit more on why converting NamedTemporaryFile to
subclass file would be a much bigger deal than it is to just fix its
__enter__ and __exit__ methods:
- converts from old-style to new-style class
- imposes the constraints of a C base class on any subclasses
- file attribute is currently part of the public API
- need to retain wrapper approach in tempfile anyway for related type
SpooledTemporaryFile in 2.6 (as that may contain a real file or a string
IO object at different points in its lifecycle)
- no compelling use case for the change (the wrapper approach works,
what real advantage do we gain from subclassing file instead?)
- wrapper approach is much easier to reconcile with Python 3.0's io module

----------
status: pending -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2021>
__________________________________

From report at bugs.python.org  Mon Feb 11 14:14:22 2008
From: report at bugs.python.org (Tal Einat)
Date: Mon, 11 Feb 2008 13:14:22 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202735662.13.0.885288223924.issue2062@psf.upfronthosting.co.za>


Tal Einat added the comment:

Well, I admit, I haven't tested this enough. Specifically, there is a
bug in this patch (both versions); please delete it.


I accept your criticism of my latest patches, they truly are of inferior
quality. I deeply apologize for having taken up more of your time than I
should have.


Allow me to explain my situation:

I work with a highly modified version of IDLE to which I have added many
features, and which is also used daily by ~10 friends and colleagues.
Many of these patches are my attempt to contribute the more mature and
successful changes/features back to CPython. However, the completion
code differs greatly from the CPython version, making porting changes a
large effort, requiring me to re-implement many things, as well as go
once more through the process of testing and debugging.

This is really a great deal of work and I have been eager to contribute
some of the better features. While I have tried to be methodical,
thorough and test everything, I seem to still have been too hasty. I
must tell you that I spent many hours preparing the last few patches,
but I realize that doing half a job is worse than not doing it at all.

In the future I will test every change much more thoroughly before
posting it as a patch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Mon Feb 11 14:28:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 11 Feb 2008 13:28:15 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202736495.04.0.451207832622.issue2065@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Attached a patch to compile trunk with vc6 and vs8.
Most tests pass with these two compilers.

Tests needed for vs7 and vs9!

Added file: http://bugs.python.org/file9409/issue2065.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Mon Feb 11 15:23:58 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 11 Feb 2008 14:23:58 -0000
Subject: [issue2047] shutil.destinsrc returns wrong result when source path
	matches beginning of destination path
In-Reply-To: <1202709042.96.0.85918319871.issue2047@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0802110623v20c1d27cs5e687309fd12bfa3@mail.gmail.com>


Raghuram Devarakonda added the comment:

> Raghuram, you've been too fast ;-)

Sorry about that :-) and thanks for validating the test cases.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Mon Feb 11 16:11:55 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 11 Feb 2008 15:11:55 -0000
Subject: [issue2067] file.__exit__ does not call subclass' close method
In-Reply-To: <1202742715.17.0.365952775258.issue2067@psf.upfronthosting.co.za>
Message-ID: <1202742715.17.0.365952775258.issue2067@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Attached patch makes file.__exit__ call subclass' close method.

----------
components: Interpreter Core
files: file_exit.diff
messages: 62289
nosy: belopolsky
severity: normal
status: open
title: file.__exit__ does not call subclass' close method
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9410/file_exit.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2067>
__________________________________

From report at bugs.python.org  Mon Feb 11 16:25:54 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 11 Feb 2008 15:25:54 -0000
Subject: [issue1745035] DoS smtpd vulnerability
Message-ID: <1202743554.33.0.0267052068852.issue1745035@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola':


----------
versions: +Python 2.6, Python 3.0

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1745035>
_____________________________________

From report at bugs.python.org  Mon Feb 11 19:14:52 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 11 Feb 2008 18:14:52 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202753692.83.0.0379831916314.issue2016@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

I have a proposed minimal fix, but I wonder if this would break existing
code (apart from the exploit given here).  Martin?  (I think the
discussion between Alexander and Amaury can be ignored for the purpose
of reviewing the fix; only the exploit matters.)

----------
assignee:  -> loewis
nosy: +gvanrossum, loewis
Added file: http://bugs.python.org/file9411/fix2016.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Mon Feb 11 20:09:29 2008
From: report at bugs.python.org (Stefan Schwarzburg)
Date: Mon, 11 Feb 2008 19:09:29 -0000
Subject: [issue2072] SimpleXMLRPCServer documentation about rpc_paths might be
	wrong
In-Reply-To: <1202756969.25.0.603492596378.issue2072@psf.upfronthosting.co.za>
Message-ID: <1202756969.25.0.603492596378.issue2072@psf.upfronthosting.co.za>


New submission from Stefan Schwarzburg:

In the documentation for SimpleXMLRPCServer
(http://docs.python.org/lib/simple-xmlrpc-servers.html)it is said, that
the SimpleXMLRPCServer object has an attribute "rpc_paths" that could be
set to  valid path portions.
This would mean that changing the example code on the same page by
adding a line like:
[...] 
server = SimpleXMLRPCServer(("localhost", 8000))
server.rpc_paths = ('/test')
[...]
would result in a call to 'http://localhost:8000/test' be processed
correctly. But this is not the case.
The server object has no attribute 'rpc_paths' nor does creating an
attribute like this change anything.

What however works is a line like this:
[...]
server.RequestHandlerClass.rpc_paths = ('/test')
[...]

The reason for this is that the test 'is_rpc_path_valid' is a method of
the class SimpleXMLRPCRequestHandler which tests if the path is in  the
class attribute 'rpc_paths' of SimpleXMLRPCRequestHandler. This class is
saved as RequestHandlerClass in SimpleXMLRPCServer. 

So the behavior of the code is understandable but is not described by
the documentation.

----------
components: Documentation
files: SimpleXMLRPCServerTEST.tgz
messages: 62291
nosy: schwarz
severity: normal
status: open
title: SimpleXMLRPCServer documentation about  rpc_paths might be wrong
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9412/SimpleXMLRPCServerTEST.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2072>
__________________________________

From report at bugs.python.org  Mon Feb 11 20:20:15 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 11 Feb 2008 19:20:15 -0000
Subject: [issue456086] virtual IO for embedding Py in server
Message-ID: <1202757615.63.0.123275618319.issue456086@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

I am closing it as there is no activity for long time. Please reopen if
required.

----------
nosy: +draghuram
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue456086>
____________________________________

From report at bugs.python.org  Mon Feb 11 23:13:40 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 22:13:40 -0000
Subject: [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202768020.78.0.373537970137.issue2049@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

I disagree.  It's a major feature of the revised IDLE that code is 
run 
in a fresh environment every time.  New users will only be 
'surprised' 
once, if at all.  They will learn to put the creation of the 
objects, 
etc. that they want to retain into the top level module they are 
running.  Getting into a discussion of whether to start fresh or 
not, 
and why, adds more confusion than it eliminates, particularly for 
beginners. Also, should this be implemented, if someone were to 
accidentally make the wrong choice they are going to be *really* 
aggravated!

I would accept a patch for a hidden switch to enable this behavior 
for the unique application in question.  Maybe even better, a patch 
for a normally disabled extension to add the functionality and menu 
entries.

Running w/o the subprocess is for 'experts'.  It was rather 
surprising we were able to continue to do it.

----------
severity: normal -> minor

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Mon Feb 11 23:17:32 2008
From: report at bugs.python.org (Mike Coleman)
Date: Mon, 11 Feb 2008 22:17:32 -0000
Subject: [issue2073] asynchat push always sends 512 bytes (ignoring
	ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>


New submission from Mike Coleman:

In asynchat, 'push' doesn't specify 'buffer_size', so the default of 512
is used.  This is bogus and causes poor performance--it should use the
value of 'ac_out_buffer_size' instead.

----------
components: Library (Lib)
messages: 62294
nosy: mkc
severity: normal
status: open
title: asynchat push always sends 512 bytes (ignoring ac_out_buffer_size)
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
__________________________________

From report at bugs.python.org  Mon Feb 11 23:57:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 11 Feb 2008 22:57:35 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202770655.65.0.321740319811.issue2066@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I would like to see whether a compression mechanism of the tables could
be found. If all else fails, compressing with raw zlib might improve
things, but before that, I think other compression techniques should be
studied.

I'm still -1 on ad-hoc exclusion of extension modules from pythonxy.dll.
If this module is to be excluded, a general policy should be established
that determines what modules get compiled separately, and an automation
mechanism should be established that automates generation of appropriate
build infrastructure for modules built separately under this policy.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Mon Feb 11 23:58:21 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 22:58:21 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202735662.13.0.885288223924.issue2062@psf.upfronthosting.co.za>
	(Tal Einat's message of "Mon, 11 Feb 2008 13:14:22 -0000")
Message-ID: <87tzkfm77f.fsf@hydra.hampton.thirdcreek.com>


Kurt B. Kaiser added the comment:

I agree that testing GUI apps is problematic, especially if you are
working with an intermediate version which isn't being used heavily.
Besides code review, you essentially have to run at least a subset of an
user-conducted acceptance test which tries to explore the corner cases
and generally monkey test the app.  It seems the best way beyond that is
to use the new version of IDLE to develop code for awhile; that usually
exposes at least the superficial problems.  I don't have an issues with
correcting minor bugs, but I expect the corrective patch to be small.
We have one going on CallTips which has become problematic for several
reasons, and I'll comment on it at msg59009.

Unless a person wants to fork, he has to make a deliberate effort to
stay close to the main line of development.  That can mean forgoing
things that would be 'nice to have' or non-essential refactorings. It's
a problem with distributed VCS that divergence is encouraged.  I think
you see the problem!

Are the differences in your autocomplete code significant functional
differences, or can we bring our versions into alignment at some point?
Please take into account the comments I'm going to make at msg59009
regarding 2.6/3.0 compatibility.

I really do appreciate your interest in IDLE and the work you are doing
to make it better.  I think you understand my interest in keeping it
minimal and intuitive.  It doesn't have to be like all the rest and
continually accrete features which are of limited use to the target
audience, especially at the cost of reliability and performance.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Tue Feb 12 00:03:04 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 11 Feb 2008 23:03:04 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202735662.13.0.885288223924.issue2062@psf.upfronthosting.co.za>
	(Tal Einat's message of "Mon, 11 Feb 2008 13:14:22 -0000")
Message-ID: <87prv3m6zg.fsf@hydra.hampton.thirdcreek.com>


Kurt B. Kaiser added the comment:

That should be 'Issue1350'!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Tue Feb 12 00:08:17 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 11 Feb 2008 23:08:17 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202771297.94.0.0465517324683.issue2066@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

BTW, which version of CNS11643 does that implement? AFAICT, there is CNS
11643-1986 and CNS 11643-1992. Where did you get the Unicode mapping from?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Tue Feb 12 00:19:16 2008
From: report at bugs.python.org (Tal Einat)
Date: Mon, 11 Feb 2008 23:19:16 -0000
Subject: [issue2049] IDLE - Restart Shell & Run Module
In-Reply-To: <1202474070.06.0.68722243132.issue2049@psf.upfronthosting.co.za>
Message-ID: <1202771956.2.0.448817501131.issue2049@psf.upfronthosting.co.za>


Tal Einat added the comment:

First of all, installing Python on Windows creates a 'Edit with IDLE'
context-menu item whenever you right-click a .py file, which opens IDLE
without a subprocess. The reason for this is that there is still a
problem regarding having several instances of IDLE, each with a
subprocess, open in parallel on Windows. The result is that many users
on Windows are often running IDLE without a subprocess; we can't treat
it as an 'expert' mode.

IMHO if you really feel strongly about this, then the Windows issue must
be resolved, and the 'Edit with IDLE' context-menu item should run IDLE
with a subprocess.


I understand your point that having the shell be restarted every time
helps teach good programming practices. But IDLE is used not only as a
learning environment; it's also a great Python shell for other purposes,
such as testing & debugging or scientific uses. I agree that these are
more advanced uses, so perhaps restarting the shell could be the
default, and the option to not have it restarted available when needed.

Thinking about it, I like the idea of an extension which is disabled by
default. I'll think about it some more, and then perhaps implement it.
Just a thought: It would be important to mention such an extension in a
prominent place in the documentation.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2049>
__________________________________

From report at bugs.python.org  Tue Feb 12 00:57:08 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 11 Feb 2008 23:57:08 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202774228.46.0.573928229235.issue2066@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Some background information: http://www.cns11643.gov.tw/eng/word.jsp

The most recent version appears to be: "CNS11643-2004", sometimes also
called "CNS11643 version 3" or "CNS11643-3"
(http://docs.hp.com/en/5991-7974/5991-7974.pdf).

Here's the table for version 1 (1986):
ftp://ftp.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/OTHER/CNS11643.TXT

Versions 1 and 2 (1992) are also included in the official Unicode Han
character database (along with several other mappings):
http://www.unicode.org/charts/unihan.html

I couldn't find a reference to a version 3 mapping table.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Tue Feb 12 03:20:32 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Feb 2008 02:20:32 -0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1202782832.87.0.0301095591055.issue1481296@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

A late comment:  I agree with Ronald here;  mightn't it make more sense
to raise an exception (ValueError?) for long(float("nan"))?

For comparison, long(float("inf")) currently raises OverflowError, at 
least on OS X.

----------
nosy: +marketdickinson

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_____________________________________

From report at bugs.python.org  Tue Feb 12 03:31:33 2008
From: report at bugs.python.org (Kuang-che Wu)
Date: Tue, 12 Feb 2008 02:31:33 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202783493.31.0.146784730435.issue2066@psf.upfronthosting.co.za>


Kuang-che Wu added the comment:

FYI, according to the new spec of cns11643-2004 (you can search the 
preview from http://www.cnsonline.com.tw/, at 
http://www.cnsonline.com.tw/preview/preview.jsp?
general_no=1164300&language=C&pagecount=524).
>From page 499, it mensioned an URL http://www.cnscode.org.tw/ and the 
version 3 mapping table could be found at 
http://www.cnscode.org.tw/cnscode/csic_ucs.jsp

----------
nosy: +kcwu

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Tue Feb 12 03:47:19 2008
From: report at bugs.python.org (Simon Percivall)
Date: Tue, 12 Feb 2008 02:47:19 -0000
Subject: [issue2074] pprint._safe_repr() unsafe on ordering differently types
	objects with same str represenation
In-Reply-To: <1202784439.48.0.0759142195952.issue2074@psf.upfronthosting.co.za>
Message-ID: <1202784439.48.0.0759142195952.issue2074@psf.upfronthosting.co.za>


New submission from Simon Percivall:

_safe_repr() tries to handle the case where two objects are unorderable by 
ordering on (str(type(key)), key, value), but this fails when 
str(type(key)) is equal for two objects, but key is different and 
unorderable. Easy fix: order just on the string representation.

----------
components: Library (Lib)
files: pprint.diff
messages: 62303
nosy: percivall
severity: normal
status: open
title: pprint._safe_repr() unsafe on ordering differently types objects with same str represenation
versions: Python 3.0
Added file: http://bugs.python.org/file9413/pprint.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2074>
__________________________________

From report at bugs.python.org  Tue Feb 12 04:25:24 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Tue, 12 Feb 2008 03:25:24 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202786724.48.0.49059566977.issue2066@psf.upfronthosting.co.za>


Hye-Shik Chang added the comment:

I've generated the mapping table from ICU's CNS11643-1992 mapping.
I see that CNS11643 is quite rarely used in the internet, but it's the
only national standard character set in Taiwan.  Asking Taiwanese
python users, even they didn't think that it's necessary to add into
Python.  I'll study how much compression is possible and how efficient
it is, then submit a revised patch again.

Thank you for comments!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Tue Feb 12 05:28:46 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Tue, 12 Feb 2008 04:28:46 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202790526.49.0.896977467961.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Re convergents: In the interest of minimality, I don't think
from_continued_fraction and to_continued_fraction need to stick around.
 I think the other thread established pretty conclusively that
.convergents() is not a particularly good building block for either
nearby-fraction method, so I'd let people who want it implement it
themselves. Neal Norwitz suggested and I agree that .trim() isn't
descriptive enough, so let's follow Raymond's alternative of
.limit_denominator(). Would you like to commit your implementation?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 06:36:04 2008
From: report at bugs.python.org (will)
Date: Tue, 12 Feb 2008 05:36:04 -0000
Subject: [issue2075] Float number comparision problem
In-Reply-To: <1202794564.07.0.200566904668.issue2075@psf.upfronthosting.co.za>
Message-ID: <1202794564.07.0.200566904668.issue2075@psf.upfronthosting.co.za>


New submission from will:

c=22.99*5.0
print c==114.95
"""This will produce false"""

c=22.99*4.0
print c==91.96
"""This will produce true"""

"""This is not expected behavior for python"""

----------
components: Interpreter Core, Library (Lib)
messages: 62306
nosy: tsxy
severity: normal
status: open
title: Float number comparision problem
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2075>
__________________________________

From report at bugs.python.org  Tue Feb 12 06:37:24 2008
From: report at bugs.python.org (will)
Date: Tue, 12 Feb 2008 05:37:24 -0000
Subject: [issue2075] Float number comparision problem
In-Reply-To: <1202794564.07.0.200566904668.issue2075@psf.upfronthosting.co.za>
Message-ID: <1202794644.09.0.587881295747.issue2075@psf.upfronthosting.co.za>


will added the comment:

The issue is reproduced under WIN32, version info as follows:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit 
(Intel)] on win32

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2075>
__________________________________

From report at bugs.python.org  Tue Feb 12 09:11:24 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Feb 2008 08:11:24 -0000
Subject: [issue2075] Float number comparision problem
In-Reply-To: <1202794564.07.0.200566904668.issue2075@psf.upfronthosting.co.za>
Message-ID: <1202803884.4.0.4839828575.issue2075@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

This is expected behavior. Please see 
http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2075>
__________________________________

From report at bugs.python.org  Tue Feb 12 12:04:13 2008
From: report at bugs.python.org (Erno Kuusela)
Date: Tue, 12 Feb 2008 11:04:13 -0000
Subject: [issue2076] xmlrpclib closes connection after each call
In-Reply-To: <1202814252.95.0.393197834217.issue2076@psf.upfronthosting.co.za>
Message-ID: <1202814252.95.0.393197834217.issue2076@psf.upfronthosting.co.za>


New submission from Erno Kuusela:

xmlrpclib is using the old HTTP and HTTPS classes from httplib which are
to quote the docstring, "Compatibility classes with httplib.py from 1.5."
and force the use of HTTP 1.0. This prevents connection reuse and
pipelining.

Attacked is some code we are using as a workaround.

Is the xmlrpclib in the standard library required to keep compatibility
with old python versions?

----------
components: Library (Lib)
files: transport.py
messages: 62309
nosy: erno
severity: normal
status: open
title: xmlrpclib closes connection after each call
versions: Python 2.5
Added file: http://bugs.python.org/file9414/transport.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2076>
__________________________________

From report at bugs.python.org  Tue Feb 12 12:50:25 2008
From: report at bugs.python.org (Rupert Summerton)
Date: Tue, 12 Feb 2008 11:50:25 -0000
Subject: [issue2077] Interpreter crash on shutdown
In-Reply-To: <1202817025.41.0.0817912479052.issue2077@psf.upfronthosting.co.za>
Message-ID: <1202817025.41.0.0817912479052.issue2077@psf.upfronthosting.co.za>


New submission from Rupert Summerton:

1. Description: The Python interpretor is crashing on shutdown due to a
segmentation fault:

Unhandled exception at 0x1e03d41f in python.exe: 0xC0000005: Access
violation reading location 0x0000002c.

2. Reproducibility: At least 10% on Windows XP Professional SP2, P4
3.20GHz, 2.00GB RAM, when running the attached module, threadpool.py.
(Running with Python 2.5.1). Unfortunately I cannot get the attached
test case to crash on Linux or Solaris. However, executing this code as
part of our Python test framework (see context below), with Python
2.4.1, what looks like the same crash produced the following backtrace:

#0  reset_exc_info (tstate=0x8254458) at
/tools/src/python/python-2.4.1/Python/ceval.c:2861
        tstate = (PyThreadState *) 0x8254458
        frame = (PyFrameObject *) 0x0
        tmp_type = (PyObject *) 0x82a3a18
        tmp_value = (PyObject *) 0x0
        tmp_tb = (PyObject *) 0x2
#1  0x080a9b56 in PyEval_EvalFrame (f=0x82a38ac) at
/tools/src/python/python-2.4.1/Python/ceval.c:2490
        stack_pointer = (PyObject **) 0x82a3a18
        next_instr = (unsigned char *) 0x81d4f1e ""
        opcode = 136660056
        oparg = 0
        why = WHY_RETURN
        err = 0
        x = (PyObject *) 0x810d940
        v = (PyObject *) 0x81d4f1e
        w = (PyObject *) 0xf6462fc0
        u = (PyObject *) 0xf642ec50
        t = (PyObject *) 0x0
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82a39f8
        freevars = (PyObject **) 0x82a3a18
        retval = (PyObject *) 0x810d940
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf6134c60
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81d4d9c "|"
        names = (PyObject *) 0xf63d762c
        consts = (PyObject *) 0xf6134c2c
#2  0x080aa263 in PyEval_EvalCodeEx (co=0xf6134c60, globals=0xf6075824,
locals=0x0, args=0x82c1080, argcount=2, kws=0x82c1088, kwcount=0,
defs=0xf6414298, 
    defcount=1, closure=0x0) at
/tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf6134c60
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0x82c1080
        argcount = 2
        kws = (PyObject **) 0x82c1088
        kwcount = 0
        defs = (PyObject **) 0xf6414298
        defcount = 1
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x82a38ac
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82a39f8
        freevars = (PyObject **) 0x82a3a18
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x82a38ac
#3  0x080acda7 in fast_function (func=0xf613e8b4, pp_stack=0xe951f3dc,
n=2, na=2, nk=0) at /tools/src/python/python-2.4.1/Python/ceval.c:3643
        func = (PyObject *) 0x82a38ac
        co = (PyCodeObject *) 0x8254458
        globals = (PyObject *) 0xf6075824
        argdefs = (PyObject *) 0x8254458
        d = (PyObject **) 0xf6414298
        nd = 1
#4  0x080ab08a in call_function (pp_stack=0xe951f3dc, oparg=1) at
/tools/src/python/python-2.4.1/Python/ceval.c:3568
        oparg = 136660056
        na = 2
        nk = 0
        n = 2
        pfunc = (PyObject **) 0x82c1080
        func = (PyObject *) 0xf613e8b4
        x = (PyObject *) 0x8172f54
        w = (PyObject *) 0x82a38ac
#5  0x080a9338 in PyEval_EvalFrame (f=0x82c0f1c) at
/tools/src/python/python-2.4.1/Python/ceval.c:2163
        sp = (PyObject **) 0x82c1088
        stack_pointer = (PyObject **) 0x82c1088
        next_instr = (unsigned char *) 0x81f58cc "\001q\225"
        opcode = 136660056
        oparg = 1
        why = WHY_NOT
        err = 0
        x = (PyObject *) 0x82a37ec
        v = (PyObject *) 0x81f58cc
        w = (PyObject *) 0xf6444de0
        u = (PyObject *) 0xf642ec50
        t = (PyObject *) 0x1
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82c1068
        freevars = (PyObject **) 0x82c1080
        retval = (PyObject *) 0x0
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf618c920
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81f57f4 "|"
        names = (PyObject *) 0xf63a484c
        consts = (PyObject *) 0xf6164a1c
#6  0x080aa263 in PyEval_EvalCodeEx (co=0xf618c920, globals=0xf5d658ac,
locals=0x0, args=0x827d690, argcount=1, kws=0x827d694, kwcount=1,
defs=0xf5d77e78, 
    defcount=2, closure=0x0) at
/tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf618c920
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0x8136f18
        argcount = 1
        kws = (PyObject **) 0x827d694
        kwcount = 1
        defs = (PyObject **) 0xf5d77e78
        defcount = 2
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x82c0f1c
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x82c1068
        freevars = (PyObject **) 0x82c1080
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x82c0f1c
#7  0x080acda7 in fast_function (func=0xf616af7c, pp_stack=0xe951f5ac,
n=3, na=1, nk=1) at /tools/src/python/python-2.4.1/Python/ceval.c:3643
        func = (PyObject *) 0x82a38ac
        co = (PyCodeObject *) 0x8254458
        globals = (PyObject *) 0xf5d658ac
        argdefs = (PyObject *) 0x8254458
        d = (PyObject **) 0xf5d77e78
        nd = 2
#8  0x080ab08a in call_function (pp_stack=0xe951f5ac, oparg=256) at
/tools/src/python/python-2.4.1/Python/ceval.c:3568
        oparg = 136660056
        na = 1
        nk = 1
        n = 3
        pfunc = (PyObject **) 0x827d690
        func = (PyObject *) 0xf616af7c
        x = (PyObject *) 0x81284cc
        w = (PyObject *) 0x82a38ac
#9  0x080a9338 in PyEval_EvalFrame (f=0x827d534) at
/tools/src/python/python-2.4.1/Python/ceval.c:2163
        sp = (PyObject **) 0x827d69c
        stack_pointer = (PyObject **) 0x827d69c
        next_instr = (unsigned char *) 0x81f9e53 "}\002"
        opcode = 136660056
        oparg = 256
        why = WHY_NOT
        err = 0
        x = (PyObject *) 0x8136f18
        v = (PyObject *) 0x81f9e53
        w = (PyObject *) 0xf63cabe0
        u = (PyObject *) 0x18c
        t = (PyObject *) 0x100
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827d680
        freevars = (PyObject **) 0x827d690
        retval = (PyObject *) 0x0
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf613f8a0
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81f9d6c "z\n\003y?\002x?\002|"
        names = (PyObject *) 0xf63cc8c4
        consts = (PyObject *) 0xf6165e9c
#10 0x080acd43 in fast_function (func=0xf6171064, pp_stack=0xe951f6ec,
n=1, na=1, nk=0) at /tools/src/python/python-2.4.1/Python/ceval.c:3629
        retval = (PyObject *) 0x827d680
        fastlocals = (PyObject **) 0x827d680
        i = 136660056
        f = (PyFrameObject *) 0x827d534
        tstate = (PyThreadState *) 0x8254458
        stack = (PyObject **) 0x82a38ac
        func = (PyObject *) 0x82a38ac
        co = (PyCodeObject *) 0x8254458
        globals = (PyObject *) 0x827d680
        argdefs = (PyObject *) 0x8254458
        d = (PyObject **) 0x8254458
        nd = 0
#11 0x080ab08a in call_function (pp_stack=0xe951f6ec, oparg=0) at
/tools/src/python/python-2.4.1/Python/ceval.c:3568
        oparg = 136660056
        na = 1
        nk = 0
        n = 1
        pfunc = (PyObject **) 0x827b2a8
        func = (PyObject *) 0xf6171064
        x = (PyObject *) 0x7f
        w = (PyObject *) 0x82a38ac
#12 0x080a9338 in PyEval_EvalFrame (f=0x827b14c) at
/tools/src/python/python-2.4.1/Python/ceval.c:2163
        sp = (PyObject **) 0x827b2ac
        stack_pointer = (PyObject **) 0x827b2ac
        next_instr = (unsigned char *) 0x81d4b2f "\001Wn)\001\004t\021"
        opcode = 136660056
        oparg = 0
        why = WHY_NOT
        err = 0
        x = (PyObject *) 0xf5e7cd4c
        v = (PyObject *) 0x81d4b2f
        w = (PyObject *) 0xf61360e0
        u = (PyObject *) 0xf5e87f4c
        t = (PyObject *) 0x0
        stream = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827b298
        freevars = (PyObject **) 0x827b2a8
        retval = (PyObject *) 0x0
        tstate = (PyThreadState *) 0x8254458
        co = (PyCodeObject *) 0xf61386e0
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81d4a84 "z?\001t"
        names = (PyObject *) 0xf643295c
        consts = (PyObject *) 0xf613a0cc
#13 0x080aa263 in PyEval_EvalCodeEx (co=0xf61386e0, globals=0xf6075824,
locals=0x0, args=0xf5de6f38, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, 
    closure=0x0) at /tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf61386e0
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0xf5de6f38
        argcount = 1
        kws = (PyObject **) 0x0
        kwcount = 0
        defs = (PyObject **) 0x0
        defcount = 0
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x827b14c
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827b298
        freevars = (PyObject **) 0x827b2a8
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x827b14c
#14 0x080ee2b7 in function_call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/funcobject.c:548
        result = (PyObject *) 0x0
        argdefs = (PyObject *) 0x0
        d = (PyObject **) 0x0
        k = (PyObject **) 0x0
        nk = 136660056
        nd = 0
#15 0x0805a7f4 in PyObject_Call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf5de6f2c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
#16 0x08061497 in instancemethod_call (func=0xf613edbc, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/classobject.c:2431
        arg = (PyObject *) 0xf5de6f2c
        self = (PyObject *) 0x0
        class = (PyObject *) 0xf5de6f2c
        result = (PyObject *) 0xf5de6f2c
#17 0x0805a7f4 in PyObject_Call (func=0xf5e858c4, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf642902c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
        co = (PyCodeObject *) 0xf61386e0
        instr_ub = -1
        instr_lb = 0
        instr_prev = -1
        first_instr = (unsigned char *) 0x81d4a84 "z?\001t"
        names = (PyObject *) 0xf643295c
        consts = (PyObject *) 0xf613a0cc
#13 0x080aa263 in PyEval_EvalCodeEx (co=0xf61386e0, globals=0xf6075824,
locals=0x0, args=0xf5de6f38, argcount=1, kws=0x0, kwcount=0, defs=0x0,
defcount=0, 
    closure=0x0) at /tools/src/python/python-2.4.1/Python/ceval.c:2730
        co = (PyCodeObject *) 0xf61386e0
        globals = (PyObject *) 0x8254458
        locals = (PyObject *) 0x82a38ac
        args = (PyObject **) 0xf5de6f38
        argcount = 1
        kws = (PyObject **) 0x0
        kwcount = 0
        defs = (PyObject **) 0x0
        defcount = 0
        closure = (PyObject *) 0x0
        f = (PyFrameObject *) 0x827b14c
        retval = (PyObject *) 0x0
        fastlocals = (PyObject **) 0x827b298
        freevars = (PyObject **) 0x827b2a8
        tstate = (PyThreadState *) 0x8254458
        x = (PyObject *) 0x82a38ac
        u = (PyObject *) 0x827b14c
#14 0x080ee2b7 in function_call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/funcobject.c:548
        result = (PyObject *) 0x0
        argdefs = (PyObject *) 0x0
        d = (PyObject **) 0x0
        k = (PyObject **) 0x0
        nk = 136660056
        nd = 0
#15 0x0805a7f4 in PyObject_Call (func=0xf613edbc, arg=0xf5de6f2c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf5de6f2c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
#16 0x08061497 in instancemethod_call (func=0xf613edbc, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/classobject.c:2431
        arg = (PyObject *) 0xf5de6f2c
        self = (PyObject *) 0x0
        class = (PyObject *) 0xf5de6f2c
        result = (PyObject *) 0xf5de6f2c
#17 0x0805a7f4 in PyObject_Call (func=0xf5e858c4, arg=0xf642902c,
kw=0x0) at /tools/src/python/python-2.4.1/Objects/abstract.c:1751
        result = (PyObject *) 0xf642902c
        func = (PyObject *) 0x8254458
        call = 0x82a38ac
---Type <return> to continue, or q <return> to quit---
#18 0x080ac52b in PyEval_CallObjectWithKeywords (func=0xf5e858c4,
arg=0xf642902c, kw=0x0) at
/tools/src/python/python-2.4.1/Python/ceval.c:3419
        arg = (PyObject *) 0xf642902c
        kw = (PyObject *) 0x0
        result = (PyObject *) 0x0
#19 0x080d0c86 in t_bootstrap (boot_raw=0x82543f8) at
/tools/src/python/python-2.4.1/Modules/threadmodule.c:432
        boot_raw = (void *) 0x82543f8
        gstate = PyGILState_UNLOCKED
        res = (PyObject *) 0x82a38ac
#20 0xf65cede8 in start_thread () from /lib/tls/libpthread.so.0
No symbol table info available.
#21 0xf654693a in clone () from /lib/tls/libc.so.6


3. Context: We have an automated test framework written in Python. To
speed up execution it has been multi-threaded so that tests can be run
in parallel. Rather than re-invent the wheel we simply used this
threadpool (http://chrisarndt.de/en/software/python/threadpool/), work
requests essentially being calls to a method that runs an individual
test case. However, we have substantially modified the code to add
functionality. Specifically, we need to find a way to limit the number
of tests that can run concurrently because: (1) different tests place
different loads on a machine, and (2) different machines have different
capacities (CPUs, memory, etc.).  We do this by associating a cost with
each work request, and by using the number of CPUs on the machine as a
limit (crude, but reasonably effective) -- if running the next job would
exceed the cost limit, the thread sleeps, and then checks again. In
order to verify that this cost logic works, we have also added some
logging code that can be activated by setting a flag. The other
significant modification has been to extend the Python Queue module to
add a peek method, because peeking at the front of the job queue to
determine the cost of the next job, and not removing it until there is
sufficient capacity to run it, speeds up the execution of tests. The
crash in the Python interpretor occurs only when (1) the cost logging is
switched on AND (2) the module peekablequeue is used instead of the
built in Queue module. I am quite willing to believe that these
modifications could be better implemented, but however bad the code, the
Python interpretor should not crash.

----------
components: Interpreter Core
files: python_crash_test.zip
messages: 62310
nosy: rupert.summerton
severity: normal
status: open
title: Interpreter crash on shutdown
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9415/python_crash_test.zip

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2077>
__________________________________

From report at bugs.python.org  Tue Feb 12 13:08:41 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Feb 2008 12:08:41 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202818121.91.0.0942689383199.issue1682@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I mentioned my dislike of the classmethod->staticmethod change on the
python-checkins list, but given the lack of response there, I figure I
should bring it up here. It is well established that the way to
implement an alternate constructor in Python is to write a classmethod.
This means the alternate constructor will behave in a way similar to
__new__: invocation via a subclass will result in an instance of that
subclass rather than of the base type.

Now, this does usually mean the parent class is placing certain
expectations on the signature of the subclass constructor. However, this
is a pretty common Python idiom, and a lot friendlier than coercing the
result to the base type. It makes the common case (constructor signature
unchanged or at least compatible) simple, while still permitting the
rarer case of changing the signature in an incompatible way (by
overriding the class methods as well as the __new__ and __init__ methods)

If you want to make this more convenient for users that do want to
subclass and change the constructor signature, the expected interface
can be factored out to a single method, similar to the way it is done
for collections.Set and its _from_iterable class method (i.e. if a Set
subclass constructor doesn't accept an iterable directly, it can just
override _from_iterable to adapt the supplied iterable to the new
interface).

----------
nosy: +ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 13:29:11 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Feb 2008 12:29:11 -0000
Subject: [issue1866] const arg for PyInt_FromString
In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
Message-ID: <1202819351.08.0.17980285165.issue1866@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The test suite is run via test/regrtest.py. If you aren't on windows,
'make test' works as well.

For myself, I tend to just run "./python -m test.regrtest" in the
directory where I built Python.

----------
nosy: +ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1866>
__________________________________

From report at bugs.python.org  Tue Feb 12 13:49:56 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 12 Feb 2008 12:49:56 -0000
Subject: [issue2063] os.times() utime and stime exchanged on windows
In-Reply-To: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>
Message-ID: <1202820596.46.0.396442165641.issue2063@psf.upfronthosting.co.za>


Facundo Batista added the comment:

How can we test it? What can we do to "see" it?

----------
nosy: +facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2063>
__________________________________

From report at bugs.python.org  Tue Feb 12 13:54:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Feb 2008 12:54:57 -0000
Subject: [issue1193099] Embedded python thread crashes
Message-ID: <1202820897.07.0.337610515108.issue1193099@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

This is a duplicate of issue1856: while a thread is sleeping,
Py_Finalize() deallocates the thread's frame. During deallocation the
thread wakes up and boom.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1193099>
_____________________________________

From report at bugs.python.org  Tue Feb 12 14:01:27 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Feb 2008 13:01:27 -0000
Subject: [issue2077] Interpreter crash on shutdown
In-Reply-To: <1202817025.41.0.0817912479052.issue2077@psf.upfronthosting.co.za>
Message-ID: <1202821287.46.0.673644489944.issue2077@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

This seems to be another incarnation of issue1856.
See also issue1193099, which shows the same backtrace on Windows.

----------
nosy: +amaury.forgeotdarc
resolution:  -> duplicate
status: open -> pending

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2077>
__________________________________

From report at bugs.python.org  Tue Feb 12 14:14:50 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Feb 2008 13:14:50 -0000
Subject: [issue2063] os.times() utime and stime exchanged on windows
In-Reply-To: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>
Message-ID: <1202822090.32.0.6138883623.issue2063@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

As a suggestion, we could just run some computation that does no system
call:

>>> import os
>>> os.times()
(0.015625, 0.015625, 0.0, 0.0, 0.0)
>>> max(xrange(10000000))   # this takes half a second on my machine
9999999
>>> os.times()
(0.015625, 0.484375, 0.0, 0.0, 0.0)

utime delta should be much higher than stime delta. This is obviously
not the case here; the values seems inverted.
   (os.times() -> (utime, stime, cutime, cstime, elapsed_time))

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2063>
__________________________________

From report at bugs.python.org  Tue Feb 12 14:48:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Feb 2008 13:48:53 -0000
Subject: [issue1736] Three bugs of FCICreate (PC/_msi.c)
In-Reply-To: <1199458428.92.0.688794479817.issue1736@psf.upfronthosting.co.za>
Message-ID: <1202824133.25.0.888548118525.issue1736@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks for the patch. Committed as r60743 and r60744.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736>
__________________________________

From report at bugs.python.org  Tue Feb 12 16:17:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Feb 2008 15:17:52 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202829472.62.0.0303961721669.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Nick Coghlan wrote:
> I mentioned my dislike of the classmethod->staticmethod change on the
> python-checkins list, but given the lack of response there, I figure I
> should bring it up here.

Yes, I missed it.  Apologies.  I'll rethink this (and likely-as-not 
revert it, but I want to get my head around the issues first).

One problem I'm having is imagining any real-life examples of subclasses 
of Rational.  An example or two might help inform the discussion.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 17:02:12 2008
From: report at bugs.python.org (Jean-Philippe Laverdure)
Date: Tue, 12 Feb 2008 16:02:12 -0000
Subject: [issue2078] CSV Sniffer does not function properly on single column
	.csv files
In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za>
Message-ID: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za>


New submission from Jean-Philippe Laverdure:

When attempting to sniff() the dialect for the attached .csv file,
csv.Sniffer.sniff() returns an unusable dialect:

>>> import csv
>>> file = open('listB2Mforblast.csv', 'r')
>>> dialect = csv.Sniffer().sniff(file.readline())
>>> file.seek(0)
>>> file.readline()
>>> file.seek(0)
>>> reader = csv.DictReader(file, dialect)
>>> reader.next()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/soft/bioinfo/linux/python-2.5/lib/python2.5/csv.py", line 93,
in next
    d = dict(zip(self.fieldnames, row))
TypeError: zip argument #1 must support iteration

However, this works fine:
>>> file.seek(0)
>>> reader = csv.DictReader(file)
>>> reader.next()
{'Sequence': 'AALENTHLL'}

If I use a 2 column file, sniff() works perfectly.
It only seems to have a problem with single column .csv files (which are
still .csv files in my opinion)

Thanks for looking into this.

----------
components: Extension Modules
files: listB2Mforblast.csv
messages: 62319
nosy: jplaverdure
severity: normal
status: open
title: CSV Sniffer does not function properly on single column .csv files
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9416/listB2Mforblast.csv

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2078>
__________________________________

From report at bugs.python.org  Tue Feb 12 17:10:48 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Feb 2008 16:10:48 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202832648.61.0.337809990622.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Okay, Nick; you've got me convinced.  For some reason I wasn't really 
thinking of these methods as alternative constructors---in this light, 
your arguments about doing the same as __new__, and about established 
patterns, make perfect sense.

Looking back at the discussion, Jeffrey looked like he was +/-0 on the 
change, and Guido was answering a slightly different question (about 
__add__ instead of constructors);  I then took his answer out of context 
to justify the change  :(

So I'll change this back unless there's further discussion.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 17:11:27 2008
From: report at bugs.python.org (phil)
Date: Tue, 12 Feb 2008 16:11:27 -0000
Subject: [issue1866] const arg for PyInt_FromString
In-Reply-To: <1200681970.2.0.912718232693.issue1866@psf.upfronthosting.co.za>
Message-ID: <1202832687.03.0.748419964226.issue1866@psf.upfronthosting.co.za>


phil added the comment:

Ok.  Ran 'make test' before and after patch.  Output identical. 
Attaching output after patch.

Added file: http://bugs.python.org/file9417/make_test_after

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1866>
__________________________________

From report at bugs.python.org  Tue Feb 12 17:29:03 2008
From: report at bugs.python.org (Gabriel Sean Farrell)
Date: Tue, 12 Feb 2008 16:29:03 -0000
Subject: [issue2079] UserDict documentation typo
In-Reply-To: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>
Message-ID: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>


New submission from Gabriel Sean Farrell:

2nd paragraph of documentation at
http://docs.python.org/lib/module-UserDict.html should read as follows:

This module also defines a class...

The "also" is out of place.

----------
components: Documentation
messages: 62322
nosy: gsf
severity: minor
status: open
title: UserDict documentation typo
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2079>
__________________________________

From report at bugs.python.org  Tue Feb 12 18:19:52 2008
From: report at bugs.python.org (David W. Lambert)
Date: Tue, 12 Feb 2008 17:19:52 -0000
Subject: [issue2085] Syntax for property set method
In-Reply-To: <1202836792.56.0.267768565577.issue2085@psf.upfronthosting.co.za>
Message-ID: <1202836792.56.0.267768565577.issue2085@psf.upfronthosting.co.za>


New submission from David W. Lambert:

# proposed syntax:
# object.property = *args,**kwargs

# python 3k could accept property setter with multiple arguments

class c:
    def f(self,a,b,c):
        print a,b,c
    F=property(None,f)

c().F=*'hi',**{'c':'third setter argument'}

----------
components: None
messages: 62323
nosy: LambertDW
severity: minor
status: open
title: Syntax for property set method
type: rfe
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2085>
__________________________________

From report at bugs.python.org  Tue Feb 12 18:53:24 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 12 Feb 2008 17:53:24 -0000
Subject: [issue2079] UserDict documentation typo
In-Reply-To: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>
Message-ID: <1202838804.1.0.629216762381.issue2079@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


----------
assignee:  -> rhettinger
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2079>
__________________________________

From report at bugs.python.org  Tue Feb 12 19:07:08 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 12 Feb 2008 18:07:08 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1202832648.61.0.337809990622.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802121007i7d88ef11rf2da859bd6fbaeae@mail.gmail.com>


Guido van Rossum added the comment:

> Okay, Nick; you've got me convinced.  For some reason I wasn't really
> thinking of these methods as alternative constructors---in this light,
> your arguments about doing the same as __new__, and about established
> patterns, make perfect sense.
>
> Looking back at the discussion, Jeffrey looked like he was +/-0 on the
> change, and Guido was answering a slightly different question (about
> __add__ instead of constructors);  I then took his answer out of context
> to justify the change  :(
>
> So I'll change this back unless there's further discussion.

Sounds good.

BTW I think the next goal should be to reduce the cost of constructing
a Fraction out of to plain ints by at least an order of magnitude. I
believe this is possible.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 19:14:54 2008
From: report at bugs.python.org (Jean-Philippe Laverdure)
Date: Tue, 12 Feb 2008 18:14:54 -0000
Subject: [issue2078] CSV Sniffer does not function properly on single column
	.csv files
In-Reply-To: <1202832132.24.0.528453630912.issue2078@psf.upfronthosting.co.za>
Message-ID: <1202840094.18.0.747698515665.issue2078@psf.upfronthosting.co.za>


Changes by Jean-Philippe Laverdure:


----------
components: +Library (Lib) -Extension Modules
versions: +Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2078>
__________________________________

From report at bugs.python.org  Tue Feb 12 19:40:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Feb 2008 18:40:41 -0000
Subject: [issue2016] Crash when modifying the **kwargs passed to a function.
In-Reply-To: <1202259671.39.0.146513031133.issue2016@psf.upfronthosting.co.za>
Message-ID: <1202841641.68.0.864067510301.issue2016@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I think we agree that this patch has the potential of breaking existing
valid code. So based on the policy that we should avoid doing so in a
bugfix release, I'd rather reject that fix (fix2016.txt) for 2.5.x.
OTOH, if it is really unlikely that is ever occurs in existing code,
there would be no point in backporting it to 2.5.x, since the check
wouldn't trigger. 

I also can't see a security concern - applications shouldn't pass
untrusted objects as keyword arguments (if they were, such objects could
 put their malicious code inside __hash__).

----------
assignee: loewis -> 
priority: high -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2016>
__________________________________

From report at bugs.python.org  Tue Feb 12 19:48:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Feb 2008 18:48:48 -0000
Subject: [issue1966] infinite loop in httplib
In-Reply-To: <1201634049.27.0.941407141284.issue1966@psf.upfronthosting.co.za>
Message-ID: <1202842128.66.0.22237433695.issue1966@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks for the patch. Committed as r60747 and r60748.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1966>
__________________________________

From report at bugs.python.org  Tue Feb 12 19:57:19 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Feb 2008 18:57:19 -0000
Subject: [issue1652] subprocess should have an option to restore SIGPIPE to
	default action
In-Reply-To: <1197992466.47.0.0612439954222.issue1652@psf.upfronthosting.co.za>
Message-ID: <1202842639.48.0.197974149967.issue1652@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The patch as it stands (subprocess-sigpipe.patch) definitely can't go
into 2.5.x: it introduces a new feature.

It's not clear to me whether Colin intended to target it for 2.5.x, as
it is against the trunk. For the trunk, the patch is fine.

Regargeting for 2.6. Colin, if that wasn't your intention, please speak up.

----------
assignee: loewis -> 
priority: high -> normal
versions: +Python 2.6 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
__________________________________

From report at bugs.python.org  Tue Feb 12 20:27:37 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Feb 2008 19:27:37 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202844457.77.0.26665041347.issue2065@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Ithink this patch still conflicts with issue 1763 - SHGetFolderPathW is
(apparently) only available on W2k. So I don't see why we *shouldn't*
mandate W2k-or-better platform headers. VC6 users should install the W2k
SDK, or the W2k3 SDK (or any later SDK that still supports VC6).

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Tue Feb 12 20:27:54 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 12 Feb 2008 19:27:54 -0000
Subject: [issue1390] toxml generates output that is not well formed
In-Reply-To: <1194224464.02.0.498094570041.issue1390@psf.upfronthosting.co.za>
Message-ID: <1202844474.61.0.761625569389.issue1390@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

I wanted to start contributing to python for quite a while, so here's my very 
first try (cleaning out old patchless open tickets).

So, whatever is the final decision on this, here's a patch.

CDATASection.writexml() already raises ValueError when finding invalid data, 
so it seems consistent to me to extend the behavior to Comment.writexml()

note: I can't add the "patch" keyword myself?

----------
nosy: +vdupras
Added file: http://bugs.python.org/file9418/minidom_comment.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1390>
__________________________________

From report at bugs.python.org  Tue Feb 12 20:30:57 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Feb 2008 19:30:57 -0000
Subject: [issue1595] Probable extra semicolon in Py_LeaveRecursiveCall macro
In-Reply-To: <1197409249.11.0.710274454226.issue1595@psf.upfronthosting.co.za>
Message-ID: <1202844657.07.0.671953754177.issue1595@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks again for pointing that out. Fixed in r60750.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1595>
__________________________________

From report at bugs.python.org  Tue Feb 12 20:46:18 2008
From: report at bugs.python.org (Thomas Conway)
Date: Tue, 12 Feb 2008 19:46:18 -0000
Subject: [issue1390] toxml generates output that is not well formed
In-Reply-To: <1202844474.61.0.761625569389.issue1390@psf.upfronthosting.co.za>
Message-ID: <784a62100802121146w210c7a07ge2996fb059fb7485@mail.gmail.com>


Thomas Conway added the comment:

On Feb 13, 2008 6:27 AM, Virgil Dupras <report at bugs.python.org> wrote:
> CDATASection.writexml() already raises ValueError when finding invalid data,
> so it seems consistent to me to extend the behavior to Comment.writexml()

That looks fine to me.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1390>
__________________________________

From report at bugs.python.org  Tue Feb 12 20:58:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Feb 2008 19:58:46 -0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1202846326.75.0.467124784515.issue1943@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is an updated patch against the current py3k branch, and with
spaces instead of tabs for indentation.

Added file: http://bugs.python.org/file9419/unialloc2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
__________________________________

From report at bugs.python.org  Tue Feb 12 21:50:37 2008
From: report at bugs.python.org (hauser)
Date: Tue, 12 Feb 2008 20:50:37 -0000
Subject: [issue2090] __import__ with fromlist=[''] causes double
	initialization of modules
In-Reply-To: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>
Message-ID: <1202849437.01.0.315019169694.issue2090@psf.upfronthosting.co.za>


New submission from hauser:

This construction:

__import__( 'pkg', {}, {}, [''] )

Will cause double initialization of package 'pkg', once with name 'pkg'
and second one with name 'pkg.' (trailing dot). Implementation tries to
import subpackage of 'pkg' with empty name, and imports the same package
twice.

This kind of construction is used as a hacky way to obtain exact module
instead of top-level module in return value. It is a hack, but should
not cause this kind of side effects.

----------
components: Interpreter Core
files: empty_import.tgz
messages: 62333
nosy: hauser
severity: minor
status: open
title: __import__ with fromlist=[''] causes double initialization of modules
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9420/empty_import.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2090>
__________________________________

From report at bugs.python.org  Tue Feb 12 22:23:46 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 12 Feb 2008 21:23:46 -0000
Subject: [issue2085] Syntax for property set method
In-Reply-To: <1202836792.56.0.267768565577.issue2085@psf.upfronthosting.co.za>
Message-ID: <1202851426.27.0.935725950791.issue2085@psf.upfronthosting.co.za>


Georg Brandl added the comment:

First, syntax proposals for 3.0 are no longer accepted.
Second, this sort of proposal should be discussed on the python-ideas
mailing list first.
Third, this is really ugly :)

So, closing this.

----------
nosy: +georg.brandl
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2085>
__________________________________

From report at bugs.python.org  Tue Feb 12 22:51:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Feb 2008 21:51:17 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202853077.73.0.0224444097347.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

limit_denominator implemented in r60752
from_decimal and from_float restored to classmethods in r60754

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:00:51 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 12 Feb 2008 22:00:51 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202853651.52.0.938645688709.issue2065@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Is it permitted to allow python compile with older compilers, even with
some functions missing?

This patch already skips some functions not included with VC6:
socket.ioctl, msvcrt.getwch &co.
Even socket.RCVALL_IPLEVEL is not available on my installation of VS8
(Professional Edition).

Even if the result is only a subset of the official python (as shown
when running the test suite), it may still be useful, when embedded in
legacy applications for example, where installing a new SDK is not
always possible.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:15:59 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 12 Feb 2008 22:15:59 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202854559.7.0.323946066269.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> BTW I think the next goal should be to reduce the cost of constructing
> a Fraction out of to plain ints by at least an order of magnitude. I
> believe this is possible.

I certainly hope so!  Here's a very simple (and simplistic) benchmark:

# start benchmark

from fractions import Fraction
from cProfile import run

def test1():
    return sum(Fraction(1, n*n-1) for n in xrange(2, 100000))

run("test1()")

#end benchmark

On my MacBook this reports a total time of 38.072 seconds, with 22.731 of 
those (i.e. around 60%) being spent in abc.__instancecheck__ and its 
callees.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:19:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Feb 2008 22:19:06 -0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1202854746.47.0.80903789566.issue2013@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I don't get the same impressive speedup as you do, although it's still
significant.

$ ./python -m timeit "for i in range(100): list(range(1000))"
Without patch:
100 loops, best of 3: 5.05 msec per loop
With patch:
100 loops, best of 3: 3.57 msec per loop

Also, your patch is leaky. I'm attaching a fixed version (for py3k,
didn't check the trunk version).

----------
nosy: +pitrou
Added file: http://bugs.python.org/file9421/py3k_longfreelist2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:32:17 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 12 Feb 2008 22:32:17 -0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202180868.04.0.23342807926.issue2013@psf.upfronthosting.co.za>
Message-ID: <1202855537.8.0.818471719112.issue2013@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Christian, maybe you did your measurements with the DEBUG flag turned
on? That would explain the discrepancy.

Also, I'm not sure the patch is useful for 2.x since long objects with
size -1 or 1 should be represented as ints instead :-)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:39:42 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 12 Feb 2008 22:39:42 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202855982.73.0.706346096977.issue1682@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Thanks for adding the class methods back Mark.

On the constructor front, we got a fair payoff in the early Decimal days
just by reordering the type checks in the constructor. Other than that,
I'd have to dig into the code a bit more to offer any useful suggestions.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:46:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 12 Feb 2008 22:46:44 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202853651.52.0.938645688709.issue2065@psf.upfronthosting.co.za>
Message-ID: <47B221D1.3070204@v.loewis.de>


Martin v. L?wis added the comment:

> Is it permitted to allow python compile with older compilers, even with
> some functions missing?

It's certainly ok that Python may not have some functions on "some
system". Even though there might not be any precedence, I think this
extends to "some compilers on the same system".

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:48:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 12 Feb 2008 22:48:20 -0000
Subject: [issue2013] Long object free list optimization
In-Reply-To: <1202855537.8.0.818471719112.issue2013@psf.upfronthosting.co.za>
Message-ID: <47B22232.7070400@cheimes.de>


Christian Heimes added the comment:

Antoine Pitrou wrote:
> Christian, maybe you did your measurements with the DEBUG flag turned
> on? That would explain the discrepancy.
> 
> Also, I'm not sure the patch is useful for 2.x since long objects with
> size -1 or 1 should be represented as ints instead :-)

Yes, I've used a Py_Debug build to measure the speed difference.

You are right. The patch makes no sense for the 2.x series.

Christian

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2013>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:55:10 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 12 Feb 2008 22:55:10 -0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>


New submission from Brett Cannon:

The docs on file's constructor says that the 'U' mode should not work
with '+', and yet 'rU+' does not throw an error.

----------
components: Interpreter Core
messages: 62343
nosy: brett.cannon
severity: normal
status: open
title: file accepts 'rU+' as a mode
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
__________________________________

From report at bugs.python.org  Tue Feb 12 23:55:36 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 12 Feb 2008 22:55:36 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202853651.52.0.938645688709.issue2065@psf.upfronthosting.co.za>
Message-ID: <47B223E5.8060706@cheimes.de>


Christian Heimes added the comment:

Amaury Forgeot d'Arc wrote:
> Is it permitted to allow python compile with older compilers, even with
> some functions missing?

When a user compiles her own Python binary she is most probably
experienced enough to notice the difference. We can't hold the hand of
every user who strolls off the official path. New features was one of
reasons for the migration to VS 2008. Legacy support shouldn't stop us
from introducing new features.

So yes, it's permitted to build Python with old compilers but users must
not expect full support of all features.

Christian

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Wed Feb 13 02:07:47 2008
From: report at bugs.python.org (John-Mark Gurney)
Date: Wed, 13 Feb 2008 01:07:47 -0000
Subject: [issue1777134] minidom pretty xml output improvement
Message-ID: <1202864867.14.0.784766688813.issue1777134@psf.upfronthosting.co.za>


John-Mark Gurney added the comment:

I think this is a good patch.  It gives more useful pretty XML output. 
I would suggest that possibly this routine be moved to xml.dom or
xml.dom.utils instead of being part of minidom since it should not be
minidom specific.

There is one bug in the patch in that:
node.writexml(writer, (%s%s) % (indent,addindent)

the parens around the %s%s should be quotes instead.

----------
nosy: +jmg

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777134>
_____________________________________

From report at bugs.python.org  Wed Feb 13 03:37:04 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Wed, 13 Feb 2008 02:37:04 -0000
Subject: [issue2092] PEP-3100 should reflect removal of 'cmp' parameter in
	sort() and sorted()
In-Reply-To: <1202870223.96.0.851994555787.issue2092@psf.upfronthosting.co.za>
Message-ID: <1202870223.96.0.851994555787.issue2092@psf.upfronthosting.co.za>


New submission from Kurt B. Kaiser:

Document the decision to remove the comparision ('cmp') 
parameter from list.sort() and builtin.sorted()

----------
assignee: rhettinger
components: Documentation
files: pep-3100.patch
messages: 62346
nosy: kbk, rhettinger
priority: normal
severity: normal
status: open
title: PEP-3100 should reflect removal of 'cmp' parameter in sort() and sorted()
versions: Python 3.0
Added file: http://bugs.python.org/file9422/pep-3100.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2092>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:03:33 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 13 Feb 2008 06:03:33 -0000
Subject: [issue2096] Reporting bugs page refers to old site
In-Reply-To: <1202882612.84.0.928632969277.issue2096@psf.upfronthosting.co.za>
Message-ID: <1202882612.84.0.928632969277.issue2096@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich:

http://www.python.org/doc/ext/reporting-bugs.html refers to
http://sourceforge.net/bugs/?group_id=5470 instead  of
http://bugs.python.org

----------
components: Documentation
messages: 62347
nosy: Yinon
severity: minor
status: open
title: Reporting bugs page refers to old site
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2096>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:04:57 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 Feb 2008 06:04:57 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202882697.53.0.173919513089.issue2065@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto:


----------
nosy: +ocean-city

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:05:05 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 13 Feb 2008 06:05:05 -0000
Subject: [issue2097] typo in exception-handling tutorial
In-Reply-To: <1202882705.49.0.845697699561.issue2097@psf.upfronthosting.co.za>
Message-ID: <1202882705.49.0.845697699561.issue2097@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich:

At http://docs.python.org/tut/node10.html#SECTION0010300000000000000000
there is "One my also instantiate" instead of "One may also instantiate"

----------
components: Documentation
messages: 62348
nosy: Yinon
severity: normal
status: open
title: typo in exception-handling tutorial
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2097>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:07:05 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Wed, 13 Feb 2008 06:07:05 -0000
Subject: [issue2099] unclear error message on bug reporting
In-Reply-To: <1202882825.69.0.96074029618.issue2099@psf.upfronthosting.co.za>
Message-ID: <1202882825.69.0.96074029618.issue2099@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich:

When filing a new bug on http://bugs.python.org/issue and not filling
the "Change Note" the following message appears: "Error: list index out
of range"... instead of "please fill the change notes" or something alike...

----------
messages: 62349
nosy: Yinon
severity: normal
status: open
title: unclear error message on bug reporting
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2099>
__________________________________

From report at bugs.python.org  Wed Feb 13 07:51:11 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 Feb 2008 06:51:11 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202885471.89.0.166498347987.issue2065@psf.upfronthosting.co.za>


Hirokazu Yamamoto added the comment:

I tried PSDK Feb 2003 downloadable from
http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdk-full.htm
and this two issues went away.

>- When WINVER is set to 0x500, vc6 gives a long warning because at the
>time, windows nt 5.0 was only at beta stage. Moreover, there are other
>clashes between winsock.h and winsock2.h, that show up when WINVER is
>0x500.

Next, I tried to compile Modules/socketmodule.h's _MSC_VER >= 1300 part
but this didn't work.

#if _MSC_VER >= 1300
# include <winsock2.h>
# include <ws2tcpip.h>
# include <MSTcpIP.h> /* for SIO_RCVALL */
# define HAVE_ADDRINFO
# define HAVE_SOCKADDR_STORAGE
# define HAVE_GETADDRINFO
# define HAVE_GETNAMEINFO
# define ENABLE_IPV6
#else
# include <winsock.h>
#endif

I didn't investigate too much, but it seems
#include <windows.h>
#include <winsock2.h>
causes another conflicts between winsock.h and winsock2.h
this time.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Wed Feb 13 08:02:26 2008
From: report at bugs.python.org (Ron Adam)
Date: Wed, 13 Feb 2008 07:02:26 -0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1202886146.1.0.905487231893.issue2001@psf.upfronthosting.co.za>


Ron Adam added the comment:

Added a topics and keywords index choices to the navbar.

This gives the web interface the same functionality as the cli interface.

Fixed the -p option which I had missed.

Added file: http://bugs.python.org/file9423/pydocnotk.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
__________________________________

From report at bugs.python.org  Wed Feb 13 08:20:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 13 Feb 2008 07:20:35 -0000
Subject: [issue2063] os.times() utime and stime exchanged on windows
In-Reply-To: <1202715697.45.0.686523581746.issue2063@psf.upfronthosting.co.za>
Message-ID: <1202887235.09.0.628766654027.issue2063@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed on trunk in r60758. Should this be backported?

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2063>
__________________________________

From report at bugs.python.org  Wed Feb 13 11:24:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 Feb 2008 10:24:20 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202898260.85.0.315305375558.issue2065@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

> Next, I tried to compile Modules/socketmodule.h's _MSC_VER >= 1300 
> part but this didn't work.

Which compiler are you using? And which errors did you get?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Wed Feb 13 12:09:29 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 13 Feb 2008 11:09:29 -0000
Subject: [issue2096] Reporting bugs page refers to old site
In-Reply-To: <1202882612.84.0.928632969277.issue2096@psf.upfronthosting.co.za>
Message-ID: <1202900969.33.0.92488616321.issue2096@psf.upfronthosting.co.za>


Facundo Batista added the comment:

It's fixed in the trunk.

If in doubt, always you can check in the state-of-the-art docs:

  http://docs.python.org/dev/

Thanks!

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2096>
__________________________________

From report at bugs.python.org  Wed Feb 13 12:26:59 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 13 Feb 2008 11:26:59 -0000
Subject: [issue2099] unclear error message on bug reporting
In-Reply-To: <1202882825.69.0.96074029618.issue2099@psf.upfronthosting.co.za>
Message-ID: <1202902019.69.0.547071987896.issue2099@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Moved this to the Meta Tracker
(http://psf.upfronthosting.co.za/roundup/meta), issue 187.

Thanks!

----------
nosy: +facundobatista
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2099>
__________________________________

From report at bugs.python.org  Wed Feb 13 12:28:53 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 13 Feb 2008 11:28:53 -0000
Subject: [issue2097] typo in exception-handling tutorial
In-Reply-To: <1202882705.49.0.845697699561.issue2097@psf.upfronthosting.co.za>
Message-ID: <1202902133.91.0.230340478149.issue2097@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Already fixed: http://docs.python.org/dev/tutorial/errors.html

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2097>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:09:18 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 13 Feb 2008 14:09:18 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1202911758.35.0.727421072059.issue2065@psf.upfronthosting.co.za>


Hirokazu Yamamoto added the comment:

>Which compiler are you using? And which errors did you get?

VC6 + PSDK2003Feb. The error was same to
http://svn.haxx.se/users/archive-2006-10/0557.shtml

E:\Microsoft\PSDK\Include\ws2tcpip.h(593) : error C2632: 'int'
followed by 'int' is illegal 

>causes another conflicts between winsock.h and winsock2.h
>this time.

This was not true. This error happened because pyconfig.h defines
socklen_t to int on VC6. I could fix this and build python with VC6 +
winsock2. Probably this is way to go. (Attached patch as ocean.zip)

regrtest.py passed other than test_float (this is because VC6 doesn't
support NaN comparation, I don't care)

# I'm still missing my 500MB disk space occupied by PSDK2003Feb though ;-)

Added file: http://bugs.python.org/file9424/ocean.zip

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:21:04 2008
From: report at bugs.python.org (Joseph Armbruster)
Date: Wed, 13 Feb 2008 14:21:04 -0000
Subject: [issue2100] unit test UnicodeWarning
In-Reply-To: <1202912464.45.0.11566210495.issue2100@psf.upfronthosting.co.za>
Message-ID: <1202912464.45.0.11566210495.issue2100@psf.upfronthosting.co.za>


New submission from Joseph Armbruster:

I receive the following warning when running the test_unicode_file unit
tests out of the trunk (60758)

python  -E -tt ../../lib/test/regrtest.py -g "test_unicode_file"
test_unicode_file
D:\work\pytrunk\lib\test\test_unicode_file.py:103: UnicodeWarning:
Unicode equal comparison failed to convert both arguments to Unicode -
interpreting them as being unequal
  filename1==filename2
D:\work\pytrunk\lib\shutil.py:36: UnicodeWarning: Unicode equal
comparison failed to convert both arguments to Unicode - interpreting
them as being unequal
  os.path.normcase(os.path.abspath(dst)))
1 test OK.

It looks like the warning was meant to be suppressed in
test_unicode_file.py line 104:

# Try using shutil on the filenames.
try:
    filename1==filename2
except UnicodeDecodeError:
    # these filenames can't be compared - shutil.copy tries to do
    # just that.  This is really a bug in 'shutil' - if one of shutil's
    # 2 params are Unicode and the other isn't, it should coerce the
    # string to Unicode with the filesystem encoding before comparison.
    pass


This does not handle the UnicodeWarning, was it meant to?

----------
components: Tests
messages: 62358
nosy: JosephArmbruster
severity: normal
status: open
title: unit test UnicodeWarning
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2100>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:37:14 2008
From: report at bugs.python.org (Stefan Seefeld)
Date: Wed, 13 Feb 2008 14:37:14 -0000
Subject: [issue2101] xml.dom documentation doesn't match implementation
In-Reply-To: <1202913434.5.0.501643425154.issue2101@psf.upfronthosting.co.za>
Message-ID: <1202913434.5.0.501643425154.issue2101@psf.upfronthosting.co.za>


New submission from Stefan Seefeld:

The docs at http://docs.python.org/lib/dom-element-objects.html
claim that removeAttribute(name) silently ignores the attempt to
remove an unknown attribute. However, the current implementation
in the minidom module (part of _xmlplus) raises an xml.dom.NotFoundErr
exception.

----------
components: Documentation, XML
messages: 62359
nosy: stefan
severity: normal
status: open
title: xml.dom documentation doesn't match implementation
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2101>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:46:25 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Feb 2008 14:46:25 -0000
Subject: [issue2073] asynchat push always sends 512 bytes (ignoring
	ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1202913985.77.0.592152760487.issue2073@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

ac_out_buffer_size value is already used when sending data.
Look at initiate_send method:

    def initiate_send (self):
        obs = self.ac_out_buffer_size
        ...
        if self.ac_out_buffer and self.connected:
            try:
                num_sent = self.send (self.ac_out_buffer[:obs])
        ...

----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
__________________________________

From report at bugs.python.org  Wed Feb 13 15:51:15 2008
From: report at bugs.python.org (Wummel)
Date: Wed, 13 Feb 2008 14:51:15 -0000
Subject: [issue2102] New style classes __ror__() operator overloading problem
In-Reply-To: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za>
Message-ID: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za>


New submission from Wummel:

Hi,

the attached code in t.py fails to run:
class C (object):
    def __ror__ (self, other):
        return 42
print C() | C()

$ python t.py
Traceback (most recent call last):
  File "t.py", line 5, in ?
    print C() | C()
TypeError: unsupported operand type(s) for |: 'C' and 'C'

If I use old style classes (ie. "class C:" instead of "class
C(object):"), the code runs fine. I suspect that the method lookup for
special operator methods is different in new style classes, but why?
This might also be related to issue #643841 but I am not sure.

----------
components: Interpreter Core
files: t.py
messages: 62361
nosy: calvin
severity: normal
status: open
title: New style classes __ror__()  operator overloading problem
type: behavior
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9425/t.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2102>
__________________________________

From report at bugs.python.org  Wed Feb 13 16:01:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 13 Feb 2008 15:01:25 -0000
Subject: [issue2102] New style classes __ror__() operator overloading problem
In-Reply-To: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za>
Message-ID: <1202914885.29.0.851747542642.issue2102@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Doc says:
http://docs.python.org/dev/reference/datamodel.html#object.__ror__

"""
These functions are only called if the left operand does not support the
corresponding operation and the operands are of different types.

For operands of the same type, it is assumed that if the non-reflected
method (such as __add__()) fails the operation is not supported, which
is why the reflected method is not called.
"""

So I'd say the opposite: this is an old-style class problem.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2102>
__________________________________

From report at bugs.python.org  Wed Feb 13 16:06:50 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Wed, 13 Feb 2008 15:06:50 -0000
Subject: [issue2092] PEP-3100 should reflect removal of 'cmp' parameter in
	sort() and sorted()
In-Reply-To: <1202870223.96.0.851994555787.issue2092@psf.upfronthosting.co.za>
Message-ID: <1202915210.37.0.22532805453.issue2092@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

r60759

----------
assignee: rhettinger -> kbk
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2092>
__________________________________

From report at bugs.python.org  Wed Feb 13 16:59:42 2008
From: report at bugs.python.org (Mike Coleman)
Date: Wed, 13 Feb 2008 15:59:42 -0000
Subject: [issue2073] asynchat push always sends 512 bytes (ignoring
	ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1202918382.95.0.952374301523.issue2073@psf.upfronthosting.co.za>


Mike Coleman added the comment:

The value is used there, but this is not effective in causing larger
packets to be sent, which I noticed by watching with strace.  I think
the reason for this is that 'refill_buffer' will only make at most one
call to simple_producer.more, and that call will produce at most 512
bytes, because that's the default value of that argument, and its not
overridden in the call that creates the simple_producer inside of 'push'.

In addition, I see at least one other place in the code where the
constant '512' appears.  Probably all of these should be changed to use
the 'ac_*' values, or at least a larger constant.

Looking at the big picture, though, I don't understand why we're trying
to break this stuff up in the first place.  That seems like the job of
the OS, and it may well do it faster and better anyway.  I would think
that every call to socket 'send' should try to ram as much data through
as possible.  The return value will let us know what actually happened.

(In my application, send's of size >200K are regularly succeeding, as
seen with strace.  I got this behavior by overriding 'push' with a fixed
version.)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
__________________________________

From report at bugs.python.org  Wed Feb 13 17:45:18 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 13 Feb 2008 16:45:18 -0000
Subject: [issue2073] asynchat push always sends 512 bytes (ignoring
	ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1202921118.9.0.760443106939.issue2073@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

> The value is used there, but this is not effective in causing larger
> packets to be sent, which I noticed by watching with strace.  I think
> the reason for this is that 'refill_buffer' will only make at most one
> call to simple_producer.more, and that call will produce at most 512
> bytes, because that's the default value of that argument, and its not
> overridden in the call that creates the simple_producer inside of 
> 'push'.

Sorry, you're right. 
I remember now that I reported a similar thing in bug #1736190:
http://bugs.python.org/msg57581

> In addition, I see at least one other place in the code where the
> constant '512' appears.

Where? Aside from simple_producer.__init__ I don't see other places
where it is used.

----------
nosy: +akuchling, josiahcarlson, klimkin

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
__________________________________

From report at bugs.python.org  Wed Feb 13 18:35:14 2008
From: report at bugs.python.org (Mike Coleman)
Date: Wed, 13 Feb 2008 17:35:14 -0000
Subject: [issue2073] asynchat push always sends 512 bytes (ignoring
	ac_out_buffer_size)
In-Reply-To: <1202768252.75.0.386707250967.issue2073@psf.upfronthosting.co.za>
Message-ID: <1202924114.12.0.657672683972.issue2073@psf.upfronthosting.co.za>


Mike Coleman added the comment:

The other place I see the constant is in asyncore.py:

class dispatcher_with_send(dispatcher):

    def __init__(self, sock=None, map=None):
        dispatcher.__init__(self, sock, map)
        self.out_buffer = ''

    def initiate_send(self):
        num_sent = 0
        num_sent = dispatcher.send(self, self.out_buffer[:512])
        self.out_buffer = self.out_buffer[num_sent:]


This code seems to be undocumented and perhaps unused, but until/unless
it's deleted, it probably ought to be fixed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2073>
__________________________________

From report at bugs.python.org  Wed Feb 13 19:00:01 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 13 Feb 2008 18:00:01 -0000
Subject: [issue1762] Inheriting from ABCs makes classes slower.
In-Reply-To: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
Message-ID: <1202925601.72.0.534429702111.issue1762@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I've committed the inlined option as r60762.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________

From report at bugs.python.org  Wed Feb 13 19:41:33 2008
From: report at bugs.python.org (bob gailer)
Date: Wed, 13 Feb 2008 18:41:33 -0000
Subject: [issue2103] __x should be _x in documentation of property()
In-Reply-To: <1202928092.92.0.376105758723.issue2103@psf.upfronthosting.co.za>
Message-ID: <1202928092.92.0.376105758723.issue2103@psf.upfronthosting.co.za>


New submission from bob gailer:

Library Reference 2.1 under property():

class C(object):
   def __init__(self): self.__x = None

__x should be _x

----------
components: Documentation
messages: 62368
nosy: bgailer
severity: normal
status: open
title: __x should be _x in documentation of property()
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2103>
__________________________________

From report at bugs.python.org  Wed Feb 13 23:15:59 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Feb 2008 22:15:59 -0000
Subject: [issue2103] __x should be _x in documentation of property()
In-Reply-To: <1202928092.92.0.376105758723.issue2103@psf.upfronthosting.co.za>
Message-ID: <1202940959.54.0.193123047528.issue2103@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks for the report!

It looks like this was previously reported in issue #1575746, and has 
been fixed in the 2.5 maintenance branch and the trunk.  Python 2.5.2 
should be out any day now; the fix should then hit docs.python.org.

----------
nosy: +marketdickinson
resolution:  -> duplicate
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2103>
__________________________________

From report at bugs.python.org  Wed Feb 13 23:26:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 13 Feb 2008 22:26:14 -0000
Subject: [issue1678380] 0.0 and -0.0 identified, with surprising results
Message-ID: <1202941574.65.0.175571879048.issue1678380@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Closing.

----------
status: pending -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1678380>
_____________________________________

From report at bugs.python.org  Thu Feb 14 00:03:06 2008
From: report at bugs.python.org (=?utf-8?q?=C3=81rni_M=C3=A1r_J=C3=B3nsson?=)
Date: Wed, 13 Feb 2008 23:03:06 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1202943786.84.0.541525563072.issue1813@psf.upfronthosting.co.za>


Changes by ?rni M?r J?nsson:


----------
components: +Library (Lib) -Interpreter Core

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Thu Feb 14 00:12:38 2008
From: report at bugs.python.org (Tal Einat)
Date: Wed, 13 Feb 2008 23:12:38 -0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1202944358.78.0.132252113263.issue2062@psf.upfronthosting.co.za>


Tal Einat added the comment:

After fixing the aforementioned bug and testing as thoroughly as I can,
here is a revised patch.

Added file: http://bugs.python.org/file9426/IDLE_AutoComplete_complete_string_optimization.080214.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Thu Feb 14 03:50:07 2008
From: report at bugs.python.org (Bill Janssen)
Date: Thu, 14 Feb 2008 02:50:07 -0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1202957407.75.0.667587710387.issue1563@psf.upfronthosting.co.za>


Changes by Bill Janssen:


----------
nosy: +janssen

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
__________________________________

From report at bugs.python.org  Thu Feb 14 04:22:10 2008
From: report at bugs.python.org (bob gailer)
Date: Thu, 14 Feb 2008 03:22:10 -0000
Subject: [issue2103] __x should be _x in documentation of property()
In-Reply-To: <1202940959.54.0.193123047528.issue2103@psf.upfronthosting.co.za>
Message-ID: <47B3B3DF.80708@alum.rpi.edu>


bob gailer added the comment:

I tried to search for a prior report with no success. How should I have 
done tha

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2103>
__________________________________

From report at bugs.python.org  Thu Feb 14 04:59:38 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Feb 2008 03:59:38 -0000
Subject: [issue2103] __x should be _x in documentation of property()
In-Reply-To: <1202928092.92.0.376105758723.issue2103@psf.upfronthosting.co.za>
Message-ID: <1202961578.55.0.974621707003.issue2103@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I'm guessing that you used the 'search in open issues' box at the top 
right.  Of course, the problem is that this issue was already closed.

Instead, go to 'Search' on the left-hand side under 'Issues', enter 
'property' and '__x' into the 'All text' box, select 'don't care' as the 
status, and try the search again...

...and you'll see that you're not the only person to have rereported this!

In any case, better to have multiple reports that none at all.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2103>
__________________________________

From report at bugs.python.org  Thu Feb 14 05:01:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Feb 2008 04:01:05 -0000
Subject: [issue2103] __x should be _x in documentation of property()
In-Reply-To: <1202928092.92.0.376105758723.issue2103@psf.upfronthosting.co.za>
Message-ID: <1202961665.93.0.865244667229.issue2103@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I should have added:

You can also check the in-development version of the documentation at

docs.python.org/dev

to see if it's already been fixed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2103>
__________________________________

From report at bugs.python.org  Thu Feb 14 05:50:40 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Thu, 14 Feb 2008 04:50:40 -0000
Subject: [issue1562716] Spurious Tabnanny error
Message-ID: <1202964640.3.0.792493811457.issue1562716@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

backported 2.5.2c1

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1562716>
_____________________________________

From report at bugs.python.org  Thu Feb 14 05:52:41 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Thu, 14 Feb 2008 04:52:41 -0000
Subject: [issue1571112] simple moves freeze IDLE
Message-ID: <1202964761.63.0.756559008344.issue1571112@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

backported 2.5.2c1

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1571112>
_____________________________________

From report at bugs.python.org  Thu Feb 14 05:53:46 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Thu, 14 Feb 2008 04:53:46 -0000
Subject: [issue1743] IDLE fails to launch
In-Reply-To: <1199623661.98.0.40278746371.issue1743@psf.upfronthosting.co.za>
Message-ID: <1202964826.51.0.681654541199.issue1743@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

backported 2.5.2c1

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1743>
__________________________________

From report at bugs.python.org  Thu Feb 14 05:55:12 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Thu, 14 Feb 2008 04:55:12 -0000
Subject: [issue1647] IDLE messes around with sys.exitfunc
In-Reply-To: <1197948552.45.0.790109797324.issue1647@psf.upfronthosting.co.za>
Message-ID: <1202964912.45.0.836472079809.issue1647@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

backported 2.5.2c1

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647>
__________________________________

From report at bugs.python.org  Thu Feb 14 06:59:26 2008
From: report at bugs.python.org (Daniel Arbuckle)
Date: Thu, 14 Feb 2008 05:59:26 -0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1202968766.05.0.471605851832.issue1563@psf.upfronthosting.co.za>


Changes by Daniel Arbuckle:


Added file: http://bugs.python.org/file9427/asyn_py3k.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
__________________________________

From report at bugs.python.org  Thu Feb 14 07:00:32 2008
From: report at bugs.python.org (Daniel Arbuckle)
Date: Thu, 14 Feb 2008 06:00:32 -0000
Subject: [issue1563] asyncore and asynchat incompatible with Py3k str and bytes
In-Reply-To: <1196967051.24.0.955219786763.issue1563@psf.upfronthosting.co.za>
Message-ID: <1202968832.79.0.348973126438.issue1563@psf.upfronthosting.co.za>


Changes by Daniel Arbuckle:


Added file: http://bugs.python.org/file9428/asyn_py3k_restructured.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1563>
__________________________________

From report at bugs.python.org  Thu Feb 14 08:16:04 2008
From: report at bugs.python.org (Wummel)
Date: Thu, 14 Feb 2008 07:16:04 -0000
Subject: [issue2102] New style vs. old style classes __ror__() operator
	overloading
In-Reply-To: <1202914275.65.0.0408321545289.issue2102@psf.upfronthosting.co.za>
Message-ID: <1202973364.45.0.97967775111.issue2102@psf.upfronthosting.co.za>


Wummel added the comment:

Ah yes, I did not realize the "different types" part. So it is indeed an
old-style class problem, which should behave just like the new-style
classes but they don't.

However I would probably not fix this in the 2.x series of Python.
Changing the behaviour would break compatibility. The documentation
should mention the different behaviour though.

----------
title: New style classes __ror__()  operator overloading problem -> New style vs. old style classes __ror__()  operator overloading

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2102>
__________________________________

From report at bugs.python.org  Thu Feb 14 08:21:59 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 14 Feb 2008 07:21:59 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1202973719.87.0.796973531225.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

r60785 speeds the benchmark up from 10.536s to 4.910s (on top of
whatever my __instancecheck__ fix did). Here are the remaining
interesting-looking calls:

   ncalls  tottime  percall  cumtime  percall filename:lineno(function)
...
        1    0.207    0.207    4.999    4.999 {sum}
   199996    1.587    0.000    3.419    0.000 fractions.py:58(__new__)
    99997    0.170    0.000    3.236    0.000 fractions.py:295(forward)
    99998    0.641    0.000    2.881    0.000 fractions.py:322(_add)
    99999    0.202    0.000    1.556    0.000 benchmark.py:3(<genexpr>)
   199996    0.829    0.000    0.829    0.000 fractions.py:17(gcd)
   199996    0.477    0.000    0.757    0.000 abc.py:63(__new__)
   399993    0.246    0.000    0.246    0.000 abc.py:164(__instancecheck__)
   199996    0.207    0.000    0.207    0.000 {method 'get' of
'dictproxy' objects}
   100071    0.185    0.000    0.185    0.000 {isinstance}
   399990    0.109    0.000    0.109    0.000 fractions.py:200(denominator)
   200004    0.073    0.000    0.073    0.000 {built-in method __new__
of type object at 0xfeea0}
   199995    0.065    0.000    0.065    0.000 fractions.py:196(numerator)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Thu Feb 14 09:01:36 2008
From: report at bugs.python.org (susanna)
Date: Thu, 14 Feb 2008 08:01:36 -0000
Subject: [issue2109] ?
In-Reply-To: <1202976095.92.0.353026153278.issue2109@psf.upfronthosting.co.za>
Message-ID: <1202976095.92.0.353026153278.issue2109@psf.upfronthosting.co.za>


New submission from susanna:

question: 
i open python and type: 

from pylab import *
plot([1,2,3,4])
show()

an EMPTY gui pops up, the line is not plotted.
why?

this is on MAC OSX 10.4.11

----------
messages: 62381
nosy: susanna
severity: normal
status: open
title: ?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2109>
__________________________________

From report at bugs.python.org  Thu Feb 14 09:05:16 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 14 Feb 2008 08:05:16 -0000
Subject: [issue1762] Inheriting from ABCs makes classes slower.
In-Reply-To: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
Message-ID: <1202976316.96.0.432384673598.issue1762@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Guido and I discussed this, and the next step seems to be to rewrite
_Abstract in C and push it into object. For an idea of how much that'll
help, just commenting out _Abstract.__new__ takes the Fraction()
constructor from 9.35us to 6.7us on my box, and the C we need (a new
flag on the class) should run very quickly.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________

From report at bugs.python.org  Thu Feb 14 09:23:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 14 Feb 2008 08:23:57 -0000
Subject: [issue2109] ?
In-Reply-To: <1202976095.92.0.353026153278.issue2109@psf.upfronthosting.co.za>
Message-ID: <1202977437.13.0.396121322082.issue2109@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

For this kind of help, please ask on comp.lang.python forum.
See http://www.python.org/community/lists/

Or on a pylab mailing list.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2109>
__________________________________

From report at bugs.python.org  Thu Feb 14 10:14:25 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Thu, 14 Feb 2008 09:14:25 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202980465.62.0.0714879420319.issue2066@psf.upfronthosting.co.za>


Hye-Shik Chang added the comment:

I have generated compressed mapping tables by several ways.

I extracted mapping data into individual files and reorganized
them by translating into Python source code or archiving into a zip file.

The following table shows the result: (in kilobytes)
(also available at
http://spreadsheets.google.com/pub?key=pWRBaY2ZM7mRgddF0Itd2IA )

                none    minimal MSjk    MSall   current
Text            0       207     312     342     570 
Data            904     696     592     562     333 
                                            
raw-py          3006    2392    2016    1932    996 
zip-py          720     496     416     384     304 
                                            
raw-pyc         952     734     624     590     346 
zip-pyc         560     384     336     304     240 
Text+zip-pyc    560     591     648     646     810 
                                            
raw-both        3954    3124    2638    2520    1340
zip-both        1248    864     736     672     512 
                                               
zip-bare        560     384     336     304     240 
tarbz2-bare     496     352     320     304     240 

Columns represent which mapping files are separated into external
files.  In "none", no mapping is left as static const C data while
only new cns11643 mappings are extracted in "current" column.
"minimal" set has the major character set for each country in
static C data and other are out.  And "MSjk" includes some more
MS codepages of Japan and Korea, and "MSall" includes all MS
codepage extensions in static const C data.  We may fix the list
which character sets remain as C data or let users pick the sets
using configure option.

"Text" is portion that remains in static const C data where is all
the current mapping tables are in.  As discussed when CJKCodecs had
been integrated into python, it can be shared over processes in a
system and efficient, but it can't be compressed or reorganized
easily by users for redistribution.  "Data" is externally managed
mapping tables.

"raw-py" row shows total volume of mapping tables as in Python
source code.  "raw-pyc" shows compiled (pyc) version of mapping
tables.  "zip-py" and "zip-pyc" are zip-compressed archive of
"raw-py" and "raw-pyc", respectively.  Those can be imported
using python zipimport machinery.

"zip-bare" and "tarbz2-bare" shows volume of archived raw mapping
table files as you can notice from their name.

We have 560KB of mapping tables in the Python CJKCodecs part.
If we choose "zip-pyc" of "minimal" set, the binary distribution
will be just as big as before even if we include CNS11643 character
set and pythonXY.dll will get smaller by 363KB.

What do you think about the scheme or
Any other idea for compression?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Thu Feb 14 10:59:47 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Feb 2008 09:59:47 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202983187.54.0.129972379241.issue2066@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I think Martin was looking for other optimizations that still leave the
data in a static C const (in order to be shared between processes and
only loaded on demand), but do compress the data representation, e.g.
using some form of Huffman coding.

While I don't see adding a few 100kB of static C data to a DLL as a
major problem (even less so, if it's possible to disable support via a
configure switch, e.g. for embedded systems), it would be interesting to
check whether the lookups tables can be compressed by way of their
structure.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Thu Feb 14 11:52:11 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 14 Feb 2008 10:52:11 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1202986331.37.0.290077321312.issue1813@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I can confirm this on SVN trunk on a Mandriva system.

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Thu Feb 14 12:30:10 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Thu, 14 Feb 2008 11:30:10 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202988610.57.0.662117267255.issue2066@psf.upfronthosting.co.za>


Hye-Shik Chang added the comment:

I couldn't find an appropriate method to implement in situ
compressed mapping table.  AFAIK, python has the smallest
mapping table footprint for each charset among major open
source transcoding programs.  I have thought about the
compression many times, but every neat method required
severe performance sacrifice.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Thu Feb 14 12:33:46 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Thu, 14 Feb 2008 11:33:46 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1202988826.79.0.018763434787.issue2066@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

In that case, I'm +1 on adding it.

The OS won't load those tables unless really needed, so it's more a
question of disk space than anything else.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Thu Feb 14 14:04:15 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 14 Feb 2008 13:04:15 -0000
Subject: [issue2110] Implement __format__ for Decimal
In-Reply-To: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>
Message-ID: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>


New submission from Facundo Batista:

A remainder.

----------
assignee: facundobatista
components: Library (Lib)
messages: 62389
nosy: facundobatista
severity: normal
status: open
title: Implement __format__ for Decimal
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2110>
__________________________________

From report at bugs.python.org  Thu Feb 14 15:40:04 2008
From: report at bugs.python.org (Thomas Herve)
Date: Thu, 14 Feb 2008 14:40:04 -0000
Subject: [issue2111] mmap segfaults when trying to write a block opened with
	PROT_READ
In-Reply-To: <1203000004.58.0.354729016159.issue2111@psf.upfronthosting.co.za>
Message-ID: <1203000004.58.0.354729016159.issue2111@psf.upfronthosting.co.za>


New submission from Thomas Herve:

Basically, the write method of mmap objects check the state with
is_writable, which check the writability with the access attributes. But
the mmap object can be opened correctly specifying the rights with
prot=mmap.PROt_READ.

Attached patch corrects the problem by setting access to ACCESS_READ
with prot is set to PROT_READ, with a test.

----------
components: Library (Lib)
files: mmap.diff
messages: 62390
nosy: therve
severity: normal
status: open
title: mmap segfaults when trying to write a block opened with PROT_READ
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9429/mmap.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2111>
__________________________________

From report at bugs.python.org  Thu Feb 14 15:57:51 2008
From: report at bugs.python.org (Thomas Herve)
Date: Thu, 14 Feb 2008 14:57:51 -0000
Subject: [issue2112] mmap.error should be a subclass of EnvironmentError and
	not a direct EnvironmentError
In-Reply-To: <1203001070.89.0.819333878266.issue2112@psf.upfronthosting.co.za>
Message-ID: <1203001070.89.0.819333878266.issue2112@psf.upfronthosting.co.za>


New submission from Thomas Herve:

mmap.error in mmapmodule is a direct reference to
PyExc_EnvironmentError, whereas it should be a subclass. It makes it
provide a specific string representation, and allows to be more specific
when catching exceptions.

The attached patch tries to provide that.

----------
components: Library (Lib)
files: mmap2.diff
messages: 62391
nosy: therve
severity: normal
status: open
title: mmap.error should be a subclass of EnvironmentError and not a direct EnvironmentError
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9430/mmap2.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2112>
__________________________________

From report at bugs.python.org  Thu Feb 14 16:39:03 2008
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 14 Feb 2008 15:39:03 -0000
Subject: [issue2113] Bad interaction between signal and subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>


New submission from Daniele Varrazzo:

During Popen.communicate(), if a signal is caught during the select(),
an unhandled exception is raised, and the output gathered is lost.

This means that a long running or hanged process can't be killed after a
timeout (as shown in the attached example, where the output collected
before the signal is valuable)

The bug happens only when stdout and stderr are not merged and is tested
on linux platform.

----------
files: subprocess_signal_bug.py
messages: 62392
nosy: piro
severity: normal
status: open
title: Bad interaction between signal and subprocess
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9431/subprocess_signal_bug.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
__________________________________

From report at bugs.python.org  Thu Feb 14 16:40:06 2008
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 14 Feb 2008 15:40:06 -0000
Subject: [issue2113] Bad interaction between signal and subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1203003606.83.0.0357553198871.issue2113@psf.upfronthosting.co.za>


Changes by Daniele Varrazzo:


Added file: http://bugs.python.org/file9432/subprocess_signal_bug.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
__________________________________

From report at bugs.python.org  Thu Feb 14 16:40:52 2008
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 14 Feb 2008 15:40:52 -0000
Subject: [issue2113] Bad interaction between signal and subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1203003652.33.0.294114540155.issue2113@psf.upfronthosting.co.za>


Changes by Daniele Varrazzo:


----------
components: +Library (Lib)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
__________________________________

From report at bugs.python.org  Thu Feb 14 16:45:36 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 14 Feb 2008 15:45:36 -0000
Subject: [issue1370380] async_chat.push() can trigger handle_error().
	undocumented.
Message-ID: <1203003936.75.0.94381109831.issue1370380@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

If this won't going to be fixed/modified I suggest to close this report
since it's frozen from year 2005.

----------
nosy: +giampaolo.rodola

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1370380>
_____________________________________

From report at bugs.python.org  Thu Feb 14 16:56:56 2008
From: report at bugs.python.org (Daniele Varrazzo)
Date: Thu, 14 Feb 2008 15:56:56 -0000
Subject: [issue2113] Bad interaction between signal and subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1203004616.29.0.85398064443.issue2113@psf.upfronthosting.co.za>


Daniele Varrazzo added the comment:

Just noticed that in the patch "except select.error:" suffices instead
of "except:"...

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:17:28 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 14 Feb 2008 16:17:28 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>


New submission from Ronald Oussoren:

test_decimal fails on Mac OS X 10.3 when using Python 2.5.2c1. I haven't 
tested other python versions. The same test passes on OSX 10.4 and 10.5 
(both on Intel and PPC machines), this was done using the same binaries 
(the Python.org build for 2.5.2c1).

The end of the output of "python test_decimal.py" is:


======================================================================
FAIL: test_normalize (__main__.DecimalTest)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_decimal.py", line 1351, in <lambda>
    tester = lambda self, f=filename: self.eval_file(directory + f)
  File "test_decimal.py", line 213, in eval_file
    self.fail('Exception "'+exception.__class__.__name__ + '" raised on 
line '+line)
AssertionError: Exception "Clamped" raised on line nrmx218 normalize  
0.001E-999       ->   0         Inexact Rounded Subnormal Underflow

----------------------------------------------------------------------
Ran 189 tests in 35.947s

FAILED (failures=1)
Traceback (most recent call last):
  File "test_decimal.py", line 1376, in <module>
    test_main(arith=True, verbose=True)
  File "test_decimal.py", line 1357, in test_main
    run_unittest(*test_classes)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/test/te
st_support.py", line 451, in run_unittest
    run_suite(suite, testclass)
  File 
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/test/te
st_support.py", line 436, in run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "test_decimal.py", line 1351, in <lambda>
    tester = lambda self, f=filename: self.eval_file(directory + f)
  File "test_decimal.py", line 213, in eval_file
    self.fail('Exception "'+exception.__class__.__name__ + '" raised on 
line '+line)
AssertionError: Exception "Clamped" raised on line nrmx218 normalize  
0.001E-999       ->   0         Inexact Rounded Subnormal Underflow

----------
components: Library (Lib)
messages: 62395
nosy: ronaldoussoren
severity: normal
status: open
title: test_decimal failure on OSX 10.3
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:27:38 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 14 Feb 2008 16:27:38 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1203006458.02.0.316706479259.issue2006@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

Since this seems to be a duplicate of #1641 I propose to close this issue.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:39:23 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 14 Feb 2008 16:39:23 -0000
Subject: [issue2006] asyncore loop lacks timers and work tasks
In-Reply-To: <1202104327.86.0.976441820339.issue2006@psf.upfronthosting.co.za>
Message-ID: <1203007163.58.0.407138415041.issue2006@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Because of Giampaolo suggestion, that is reviewing all these
asyncore/asynchat issues.

----------
nosy: +facundobatista
resolution:  -> duplicate
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2006>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:40:04 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 14 Feb 2008 16:40:04 -0000
Subject: [issue1641] asyncore delayed calls feature
In-Reply-To: <1197908693.3.0.330108725692.issue1641@psf.upfronthosting.co.za>
Message-ID: <1203007204.14.0.485081945815.issue1641@psf.upfronthosting.co.za>


Facundo Batista added the comment:

The issue #2006 (asyncore loop lacks timers and work tasks) was closed
as duplicate of this one... noting this just for reference.

----------
nosy: +facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1641>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:41:43 2008
From: report at bugs.python.org (Daniel Arbuckle)
Date: Thu, 14 Feb 2008 16:41:43 -0000
Subject: [issue1736190] asyncore/asynchat patches
Message-ID: <1203007303.82.0.660057531039.issue1736190@psf.upfronthosting.co.za>


Changes by Daniel Arbuckle:


----------
nosy: +djarb

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1736190>
_____________________________________

From report at bugs.python.org  Thu Feb 14 17:42:15 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Feb 2008 16:42:15 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203007335.83.0.0041373029446.issue2114@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

It looks like you've got a stale normalize.decTest file in 
Lib/test/decimaltestdata.  This file shouldn't be present.  Can you do a 
fresh svn checkout and see if the problem persists?

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:42:54 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 14 Feb 2008 16:42:54 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203007374.5.0.524564710807.issue2114@psf.upfronthosting.co.za>


Changes by Facundo Batista:


----------
nosy: +facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:50:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 14 Feb 2008 16:50:57 -0000
Subject: [issue2113] Bad interaction between signal and subprocess
In-Reply-To: <1203003543.0.0.215384363172.issue2113@psf.upfronthosting.co.za>
Message-ID: <1203007857.16.0.167310629835.issue2113@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

First, this patch has a possible bug: if select() fails on the first
iteration, wlist is left undefined, and the next instruction "if
self.stdin in wlist" will fail.

Second, I think that is is not a good idea to simply exit the loop on
the first signal. In your script, select() is interrupted because of
SIGALRM (try removing the call to os.kill), and there may be more data
to read.

A possible solution could be:

try:
    ...select.select()...
except select.error, e:
    if e.args[0] == errno.EINTR:
        continue  # try again
    else:
        raise
else:
    ...exchange data...

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2113>
__________________________________

From report at bugs.python.org  Thu Feb 14 17:58:47 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Feb 2008 16:58:47 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1202973719.87.0.796973531225.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802140858n46838a5j6604237de26cc391@mail.gmail.com>


Guido van Rossum added the comment:

Yay! And my benchmark went from 70 usec to 15 usec. Not bad!

PS. Never use relative speedup numbers based on profiled code -- the
profiler skews things tremendously. Not saying you did, just stating
the obvious. :)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Thu Feb 14 18:01:28 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 14 Feb 2008 17:01:28 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203008488.89.0.545510455731.issue2114@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I did an upgrade install on the OSX 10.3. Doing a clean install removes 
the problem.

I'm therefore closing this issue as invalid. Sorry about the noise.

----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 18:08:55 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 14 Feb 2008 17:08:55 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203008934.92.0.672776563128.issue1682@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

PS. I can shave off nearly 4 usec of the constructor like this:

-        self = super(Fraction, cls).__new__(cls)
+        if cls is Fraction:
+            self = object.__new__(cls)
+        else:
+            self = super().__new__(cls)

This would seem to give an upper bound for the gain you can make by
moving the check for instantiating an abstract class to C.  Your call.  

I also found that F(2,3)+F(5,7) takes about 22 usecs (or 18 using the
above hack).

Inlining the common case for addition (Fraction+Fraction) made that go
down to 14 usec (combined with the above hack):

-    __add__, __radd__ = _operator_fallbacks(_add, operator.add)
+    __xadd__, __radd__ = _operator_fallbacks(_add, operator.add)
 
+    def __add__(self, other):
+        if type(other) is Fraction:
+            na = self._numerator
+            da = self._denominator
+            nb = other._numerator
+            db = other._denominator
+            return Fraction(na*db + nb*da, da*db)
+        return self.__xadd__(other)
+

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Thu Feb 14 18:17:05 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Feb 2008 17:17:05 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203009425.85.0.251885030166.issue2114@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Hmm. But others may run into this problem as well.

Is there any way to force the upgrade install to remove this file?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 18:27:01 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Thu, 14 Feb 2008 17:27:01 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203010021.94.0.568233972839.issue2114@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

OSX installer is lame. The only way to work around this is to have pre- 
and/or post-install hooks that remove the stdlib (but not site-
packages).

As this only affects the unittests I don't think this is worth the 
problem right now. Especially because I have rather limited time 
available until the 2.5.2 release.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 18:47:19 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 14 Feb 2008 17:47:19 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203011239.54.0.669549434556.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Thanks for writing the __add__ optimization down. I hadn't realized how
simple it was. I think both optimizations are worth it. 22% on a rarely
used class is worth 24 lines of python, and I think nearly eliminating
the overhead of ABCs (which will prevent them from getting a bad
performance reputation) is worth some C.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Thu Feb 14 18:52:33 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 14 Feb 2008 17:52:33 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203011553.11.0.250696473253.issue2114@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

A cheap and easy fix would be to update normalize.decTest so that's it's
an exact copy of reduce.decTest.  This would result in all the
normalization tests being run twice, but that's probably better than
seeing failing tests.

(What happened here is that Mike Cowlishaw fixed some buggy tests in
normalize.decTest and also renamed normalize.decTest to reduce.decTest,
and renamed the tests within the file.)

But I agree that it's not a disaster if this doesn't get fixed.  It's
the tests that are buggy, not the Decimal module.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Thu Feb 14 19:01:38 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 14 Feb 2008 18:01:38 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

(On a MacBook Pro 2.33 GHz)

$ ./python.exe -m timeit -s 'class Foo(object): pass' -s 'f = Foo()'
'f.num = 3'
10000000 loops, best of 3: 0.13 usec per loop
$ ./python.exe -m timeit -s 'class Foo(object): __slots__ = ["num"]' -s
'f = Foo()' 'f.num = 3'
1000000 loops, best of 3: 1.24 usec per loop

Attribute reading isn't affected:
$ ./python.exe -m timeit -s 'class Foo(object): pass' -s 'f = Foo();
f.num = 3' 'g = f.num'
10000000 loops, best of 3: 0.107 usec per loop
$ ./python.exe -m timeit -s 'class Foo(object): __slots__ = ["num"]' -s
'f = Foo(); f.num = 3' 'g = f.num'
10000000 loops, best of 3: 0.101 usec per loop

----------
components: Interpreter Core
messages: 62408
nosy: jyasskin
severity: normal
status: open
title: __slots__ make attribute setting 10x slower
type: resource usage
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 19:10:43 2008
From: report at bugs.python.org (Facundo Batista)
Date: Thu, 14 Feb 2008 18:10:43 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203012643.62.0.949470453282.issue2115@psf.upfronthosting.co.za>


Changes by Facundo Batista:


----------
nosy: +facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 19:50:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 14 Feb 2008 18:50:06 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203015006.21.0.64780557839.issue2115@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

This slowdown is due to the new implementation of isinstance in python2.6.

If I comment most of the code of PyObject_IsInstance in
Objects/abstract.c (remove all __instancecheck__ stuff; leave only the
last line), timings are much better, and more similar to 2.5 performance.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 21:09:46 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 14 Feb 2008 20:09:46 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203019786.29.0.147783674597.issue2115@psf.upfronthosting.co.za>


Thomas Heller added the comment:

I think this is a serious problem (and thanks, amaury, for finding the
spot). comtypes, like ctypes, uses quite a bit of isinstance calls.

It is the reason that the comtypes unit tests run between 8% and 25%
slower with trunk than with python 2.5.1.  If I comment out the code
that you mentioned, python trunk is slightly faster than 2.5.1.  I
suggest to raise the severity.

----------
nosy: +theller

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 21:20:49 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 14 Feb 2008 20:20:49 -0000
Subject: [issue2091] file accepts 'rU+' as a mode
In-Reply-To: <1202856909.89.0.801927341292.issue2091@psf.upfronthosting.co.za>
Message-ID: <1203020449.45.0.700138952757.issue2091@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
priority:  -> high

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2091>
__________________________________

From report at bugs.python.org  Thu Feb 14 21:36:32 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 14 Feb 2008 20:36:32 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203021392.58.0.651720146481.issue2115@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I agree, Thomas

----------
nosy: +tiran
priority:  -> high

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 21:55:49 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 14 Feb 2008 20:55:49 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203022549.54.0.268407173996.issue2115@psf.upfronthosting.co.za>


Thomas Heller added the comment:

PyObject_IsSubclass() has the same problem.

BTW; calling PyObject_GetAttr() with interned strings for
"__instancecheck__" and "__subclasscheck__" brings not enough speedup.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 22:22:35 2008
From: report at bugs.python.org (Rick Harris)
Date: Thu, 14 Feb 2008 21:22:35 -0000
Subject: [issue2116] weakref copy module interaction
In-Reply-To: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za>
Message-ID: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za>


New submission from Rick Harris:

The copy module will not properly copy/deepcopy weakrefs, it will bomb
out with __new__ not having enough args. This is a problem b/c it makes
deepcopying of objects that make use of Weak(Key|Value)Dictionaries
difficult.

To replicate:

import copy, weakref
class Test(object): pass
t = Test()
wr = weakref.ref(t)
wr_new = copy.copy(wr)

----------
components: Library (Lib)
files: copy.patch
messages: 62413
nosy: rharris
severity: normal
status: open
title: weakref copy module interaction
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9433/copy.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2116>
__________________________________

From report at bugs.python.org  Thu Feb 14 22:30:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 14 Feb 2008 21:30:39 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203024639.06.0.492038116638.issue2115@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Something interesting:
- attribute setting uses PyObject_IsInstance, which is slower since the
introduction of ABCs.
- attribute reading uses PyObject_TypeCheck, which only searches the
__mro__.

Does this means that many calls to IsInstance could be replaced by
TypeCheck? Of course this makes sense only for new-style classes, but it
is the case for all built-in objects.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 22:46:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 14 Feb 2008 21:46:47 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203025607.79.0.242778692625.issue2115@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

With this trivial patch, all tests still pass:

Index: Objects/descrobject.c
===================================================================
--- Objects/descrobject.c       (revision 60754)
+++ Objects/descrobject.c       (working copy)
@@ -166,7 +166,7 @@
               int *pres)
 {
        assert(obj != NULL);
-       if (!PyObject_IsInstance(obj, (PyObject *)(descr->d_type))) {
+       if (!PyObject_TypeCheck(obj, descr->d_type)) {
                PyErr_Format(PyExc_TypeError,
                             "descriptor '%.200s' for '%.100s' objects "
                             "doesn't apply to '%.100s' object",

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 23:23:13 2008
From: report at bugs.python.org (stranger4good)
Date: Thu, 14 Feb 2008 22:23:13 -0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>


New submission from stranger4good:

smtplib.SMTP() raises socket.error rather than SMTPConnectError

just try this on a non-responding address

>>> srv=smtplib.SMTP('192.168.13.22')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python25\lib\smtplib.py", line 244, in __init__
    (code, msg) = self.connect(host, port)
  File "c:\python25\lib\smtplib.py", line 311, in connect
    (code, msg) = self.getreply()
  File "c:\python25\lib\smtplib.py", line 352, in getreply
    line = self.file.readline()
  File "C:\Python25\lib\socket.py", line 346, in readline
    data = self._sock.recv(self._rbufsize)
socket.error: (10054, 'Connection reset by peer')

----------
components: Library (Lib)
messages: 62416
nosy: stranger4good
severity: normal
status: open
title: smtplib.SMTP() raises socket.error rather than SMTPConnectError
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Thu Feb 14 23:42:32 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 14 Feb 2008 22:42:32 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203022549.54.0.268407173996.issue2115@psf.upfronthosting.co.za>
Message-ID: <47B4C3D5.5020408@cheimes.de>


Christian Heimes added the comment:

Thomas Heller wrote:
> BTW; calling PyObject_GetAttr() with interned strings for
> "__instancecheck__" and "__subclasscheck__" brings not enough speedup.

I've implemented the interning as static PyObject* in r60822. It should
give a small speedup.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Thu Feb 14 23:51:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Feb 2008 22:51:38 -0000
Subject: [issue2119] Empty test
Message-ID: <1203029494.75.0.298873586511.issue2119@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
nosy: loewis
severity: normal
status: open
title: Empty test

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2119>
__________________________________

From report at bugs.python.org  Thu Feb 14 23:52:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 14 Feb 2008 22:52:04 -0000
Subject: [issue2119] Empty test
Message-ID: <1203029524.68.0.826323768859.issue2119@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2119>
__________________________________

From report at bugs.python.org  Fri Feb 15 01:05:14 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 15 Feb 2008 00:05:14 -0000
Subject: [issue2110] Implement __format__ for Decimal
In-Reply-To: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>
Message-ID: <1203033914.4.0.850680025134.issue2110@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I can take a look at this if you like.  But I don't want to spoil your fun 
:)

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2110>
__________________________________

From report at bugs.python.org  Fri Feb 15 01:16:53 2008
From: report at bugs.python.org (Ori Avtalion)
Date: Fri, 15 Feb 2008 00:16:53 -0000
Subject: [issue2120] broken links in advocacy HOWTO
In-Reply-To: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>
Message-ID: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>


New submission from Ori Avtalion:

The file python/trunk/Doc/howto/advocacy.rst has two broken links:

"http://www.catb.org/ esr/jargon/html/C/compact.html"
should be
"http://www.catb.org/~esr/jargon/html/C/compact.html"

"http://homepages.cwi.nl/ steven/abc/" (line-wrapped in the source)
should be
"http://homepages.cwi.nl/~steven/abc/"

----------
components: Documentation
messages: 62419
nosy: georg.brandl, salty-horse
severity: minor
status: open
title: broken links in advocacy HOWTO
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2120>
__________________________________

From report at bugs.python.org  Fri Feb 15 06:53:08 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Fri, 15 Feb 2008 05:53:08 -0000
Subject: [issue2120] broken links in advocacy HOWTO
In-Reply-To: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>
Message-ID: <1203054788.9.0.804778095747.issue2120@psf.upfronthosting.co.za>


Robert Lehmann added the comment:

Aye, this patch removes the spaces and re-aligns the paragraph of the
latter link.

----------
nosy: +lehmannro
Added file: http://bugs.python.org/file9434/spaces.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2120>
__________________________________

From report at bugs.python.org  Fri Feb 15 08:06:45 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 15 Feb 2008 07:06:45 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203059205.75.0.150906452692.issue2114@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

That's a good idea. I'll try to get this into the installer before 2.5.2 
is actually released.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Fri Feb 15 09:15:17 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2008 08:15:17 -0000
Subject: [issue2121] complex constructor doesn't accept string with nan and inf
In-Reply-To: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>
Message-ID: <1203063317.15.0.466109223175.issue2121@psf.upfronthosting.co.za>


New submission from Christian Heimes:

This is a reminder.

The issue makes the complex(repr(...)) round-trip impossible when either
the real or imag part is nan or infinite.

----------
components: Interpreter Core
messages: 62422
nosy: tiran
priority: normal
severity: normal
status: open
title: complex constructor doesn't accept string with nan and inf
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2121>
__________________________________

From report at bugs.python.org  Fri Feb 15 09:15:48 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2008 08:15:48 -0000
Subject: [issue2120] broken links in advocacy HOWTO
In-Reply-To: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>
Message-ID: <1203063348.63.0.00595512239478.issue2120@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> georg.brandl
priority:  -> normal
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2120>
__________________________________

From report at bugs.python.org  Fri Feb 15 09:16:33 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2008 08:16:33 -0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1203063393.24.0.461861905927.issue2118@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Why is this a bug? Do the docs promise that smtplib only raises
SMTPConnectError?

----------
nosy: +tiran
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Fri Feb 15 09:21:04 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2008 08:21:04 -0000
Subject: [issue2111] mmap segfaults when trying to write a block opened with
	PROT_READ
In-Reply-To: <1203000004.58.0.354729016159.issue2111@psf.upfronthosting.co.za>
Message-ID: <1203063664.44.0.0590368856588.issue2111@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Fixed in r60830 (trunk)

Martin, is the fix a candidate for 2.5.3, too?

----------
assignee:  -> loewis
nosy: +loewis, tiran
priority:  -> high
resolution:  -> accepted
status: open -> pending
versions: +Python 2.5 -Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2111>
__________________________________

From report at bugs.python.org  Fri Feb 15 09:22:39 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 15 Feb 2008 08:22:39 -0000
Subject: [issue2112] mmap.error should be a subclass of EnvironmentError and
	not a direct EnvironmentError
In-Reply-To: <1203001070.89.0.819333878266.issue2112@psf.upfronthosting.co.za>
Message-ID: <1203063758.97.0.702409671671.issue2112@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Sounds fine with me

----------
keywords: +easy, patch
nosy: +tiran
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2112>
__________________________________

From report at bugs.python.org  Fri Feb 15 12:43:56 2008
From: report at bugs.python.org (Ori Avtalion)
Date: Fri, 15 Feb 2008 11:43:56 -0000
Subject: [issue2120] broken links in advocacy HOWTO
In-Reply-To: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>
Message-ID: <1203075836.06.0.596411362446.issue2120@psf.upfronthosting.co.za>


Ori Avtalion added the comment:

Removing the spaces is wrong. They should be replaced with '~'.

I also found two other punctuation problems:
* A period that should be a colon.
* A comma that should be a dash/semicolon/something else. I'm not really
sure what's the best replacement.

See the attached advocacy.patch

Added file: http://bugs.python.org/file9435/advocacy.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2120>
__________________________________

From report at bugs.python.org  Fri Feb 15 14:20:03 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 15 Feb 2008 13:20:03 -0000
Subject: [issue2122] mmap.flush does not check for errors on windows
In-Reply-To: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>
Message-ID: <1203081603.58.0.172093843344.issue2122@psf.upfronthosting.co.za>


New submission from Ralf Schmitt:

mmap.flush returns the result of the call to FlushViewOfFile as an
integer, and does not check for errors. On unix it does check for
errors. The function should return None and raise an exception if an
error occurs...
This bug can lead to data loss...

Here's the current version of that function:

static PyObject *
mmap_flush_method(mmap_object *self, PyObject *args)
{
	Py_ssize_t offset = 0;
	Py_ssize_t size = self->size;
	CHECK_VALID(NULL);
	if (!PyArg_ParseTuple(args, "|nn:flush", &offset, &size))
		return NULL;
	if ((size_t)(offset + size) > self->size) {
		PyErr_SetString(PyExc_ValueError, "flush values out of range");
		return NULL;
	}
#ifdef MS_WINDOWS
	return PyInt_FromLong((long) FlushViewOfFile(self->data+offset, size));
#elif defined(UNIX)
	/* XXX semantics of return value? */
	/* XXX flags for msync? */
	if (-1 == msync(self->data + offset, size, MS_SYNC)) {
		PyErr_SetFromErrno(mmap_module_error);
		return NULL;
	}
	return PyInt_FromLong(0);
#else
	PyErr_SetString(PyExc_ValueError, "flush not supported on this system");
	return NULL;
#endif
}

----------
components: Library (Lib)
messages: 62427
nosy: schmir
severity: major
status: open
title: mmap.flush does not check for errors on windows
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
__________________________________

From report at bugs.python.org  Fri Feb 15 14:57:39 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Fri, 15 Feb 2008 13:57:39 -0000
Subject: [issue2120] broken links in advocacy HOWTO
In-Reply-To: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>
Message-ID: <1203083859.66.0.477772236933.issue2120@psf.upfronthosting.co.za>


Robert Lehmann added the comment:

Right, the second link requires a tilde -- I just tried the first one
(which works without). You should change all lines to be 80 characters
wide maximum, though (can quickly be done by any commiter, not worth a
new patch IMO). The dash thing looks okay, "---" is used a couple of
times throughout the docs.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2120>
__________________________________

From report at bugs.python.org  Fri Feb 15 15:25:05 2008
From: report at bugs.python.org (Armin Rigo)
Date: Fri, 15 Feb 2008 14:25:05 -0000
Subject: [issue2123] ctypes pointer not always keeping target alive
In-Reply-To: <1203085504.98.0.560350426708.issue2123@psf.upfronthosting.co.za>
Message-ID: <1203085504.98.0.560350426708.issue2123@psf.upfronthosting.co.za>


New submission from Armin Rigo:

It's hard to tell for sure, given the lack of precise definition, but I
believe that the attached piece of code "should" work.  What it does is
make p1 point to c_long(20).  So ctypes should probably keep the
c_long(20) alive as long as p1 is alive (and not further modified). 
This test shows that the c_long(20) gets freed instead, making the
p1.contents reference garbage.

----------
components: Extension Modules
files: x.py
messages: 62429
nosy: arigo
severity: normal
status: open
title: ctypes pointer not always keeping target alive
Added file: http://bugs.python.org/file9436/x.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2123>
__________________________________

From report at bugs.python.org  Fri Feb 15 15:42:55 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 14:42:55 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>


New submission from A.M. Kuchling:

The W3C posted an item at
http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic
describing how their DTDs are being fetched up to 130M times per day.  

The Python parsers are part of the problem, as 
noted by Paul Boddie on the python-advocacy list:

There are two places which stand out:

xml/dom/xmlbuilder.py
xml/sax/saxutils.py

What gives them away is the way as the cause of the described problem is
that 
they are both fetching things which are given as "system identifiers" - the 
things you get in the document type declaration at the top of an XML
document 
which look like a URL.

If you then put some trace statements into the code and then try and parse 
something using, for example, the xml.sax API, it becomes evident that by 
default the parser attempts to fetch lots of DTD-related resources, not 
helped by the way that stuff like XHTML is now "modular" and thus employs 
lots of separate files in the DTD. This is obvious because you get
something 
like this printed to the terminal:

saxutils: opened http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlstyle-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-framework-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-datatypes-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-qname-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-events-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-attribs-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml11-model-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-charent-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-lat1.ent
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-symbol.ent
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-special.ent
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-text-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlstruct-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-inlphras-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-blkstruct-1.mod
saxutils: opened http://www.w3.org/MarkUp/DTD/xhtml-blkphras-1.mod

Of course, the "best practice" with APIs like SAX is that you define
your own 
resolver or handler classes which don't go and fetch DTDs from the W3C all 
the time, but this isn't the "out of the box" behaviour. Instead, 
implementers have chosen the most convenient behaviour which arguably 
involves the least effort in telling people how to get hold of DTDs so that 
they may validate their documents, but which isn't necessarily the "right 
thing" in terms of network behaviour. Naturally, since defining specific 
resolvers/handlers involves a lot of boilerplate (and you should try it in 
Java!) then a lot of developers just incur the penalty of having the
default 
behaviour, instead of considering the finer points of the various W3C 
specifications (which is never really any fun).

Anyway, I posted a comment saying much the same on the blog referenced
at the 
start of this thread, but we should be aware that this is default standard 
library behaviour, not rogue application developer behaviour.

----------
components: XML
messages: 62430
nosy: akuchling
severity: normal
status: open
title: xml.sax and xml.dom fetch DTDs by default
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Fri Feb 15 16:15:09 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 15:15:09 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203088508.92.0.545443917543.issue2124@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Here's a simple test to demonstrate the problem:

from xml.sax import make_parser
from xml.sax.saxutils import prepare_input_source
parser = make_parser()
inp = prepare_input_source('file:file.xhtml')
parser.parse(inp)

file.xhtml contains:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" />

If you insert a debug print into saxutils.prepare_input_source, 
in the branch which uses urllib.urlopen(), you get the above list of
inputs accessed: the XHTML 1.1 DTD, which is nicely modular and pulls in
all those other files.

I don't see a good way to fix this without breaking backward
compatibility to some degree.  The 
external-general-entities features defaults to 'on', which enables this
fetching; we could change the default to 'off', which would save the
parsing effort, but would also mean that entities like &eacute; weren't
defined.

If we had catalog support, we could ship the XHTML 1.1 DTDs and any
other DTDs of wide usage, but we don't.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Fri Feb 15 16:17:19 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 15:17:19 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203088639.89.0.513281975022.issue2124@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
priority:  -> urgent

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Fri Feb 15 16:17:44 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 15:17:44 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203088664.73.0.125225048913.issue2124@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
type:  -> resource usage

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Fri Feb 15 17:35:37 2008
From: report at bugs.python.org (Floris Bruynooghe)
Date: Fri, 15 Feb 2008 16:35:37 -0000
Subject: [issue2125] [patch] Read support for Records in msilib
In-Reply-To: <1203093337.85.0.620181363068.issue2125@psf.upfronthosting.co.za>
Message-ID: <1203093337.85.0.620181363068.issue2125@psf.upfronthosting.co.za>


New submission from Floris Bruynooghe:

The msilib documentation mentions that read support of MSI files is
supported, however the actual methods on the Record class for it are
missing.  This patch wraps two more functions from the MSI API to the
record class, enabling to read integers and strings.  The only one left
then (AFAIK) is "Stream" but I didn't need that so couldn't test it.

----------
components: Extension Modules, Library (Lib), Windows
files: msilib.diff
messages: 62432
nosy: flub
severity: normal
status: open
title: [patch] Read support for Records in msilib
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9437/msilib.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2125>
__________________________________

From report at bugs.python.org  Fri Feb 15 17:36:36 2008
From: report at bugs.python.org (=?utf-8?q?=C3=81rni_M=C3=A1r_J=C3=B3nsson?=)
Date: Fri, 15 Feb 2008 16:36:36 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1203093396.39.0.0513412009916.issue1813@psf.upfronthosting.co.za>


?rni M?r J?nsson added the comment:

There is more to this bug than appears. I'm guessing that the name
mangling code in locale (e.g. the normalizing code) is locale dependent. 

See this example:

#!/usr/bin/python2.5

import locale

print 'TR', locale.normalize('tr')

print locale.setlocale(locale.LC_ALL, ('tr_TR', 'ISO8859-9'))

# first issue, not quite the same coming out, as came in
print locale.getlocale()

# and this fails
print locale.setlocale(locale.LC_ALL, ('tr_TR', 'ISO8859-9'))



First, the value returned from getlocale is ('tr_TR', 'so8859-9'), not
('tr_TR', 'ISO8859-9'), and the second setlocale fails.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Fri Feb 15 18:30:54 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 17:30:54 -0000
Subject: [issue2072] SimpleXMLRPCServer documentation about rpc_paths might be
	wrong
In-Reply-To: <1202756969.25.0.603492596378.issue2072@psf.upfronthosting.co.za>
Message-ID: <1203096654.52.0.350542303432.issue2072@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
assignee:  -> akuchling
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2072>
__________________________________

From report at bugs.python.org  Fri Feb 15 18:35:29 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 17:35:29 -0000
Subject: [issue2101] xml.dom documentation doesn't match implementation
In-Reply-To: <1202913434.5.0.501643425154.issue2101@psf.upfronthosting.co.za>
Message-ID: <1203096929.01.0.906755191157.issue2101@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +easy

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2101>
__________________________________

From report at bugs.python.org  Fri Feb 15 18:47:25 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 15 Feb 2008 17:47:25 -0000
Subject: [issue1390] toxml generates output that is not well formed
In-Reply-To: <1194224464.02.0.498094570041.issue1390@psf.upfronthosting.co.za>
Message-ID: <1203097645.18.0.161245374835.issue1390@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1390>
__________________________________

From report at bugs.python.org  Fri Feb 15 19:59:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Feb 2008 18:59:18 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203101958.74.0.428554361816.issue2115@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

__instancecheck__ is not only slower, it can also cause crashes:

import abc
class MyABC:
    __metaclass__ = abc.ABCMeta
    __slots__ = ["a"]

class Unrelated:
    pass
MyABC.register(Unrelated)

u=Unrelated()
assert isinstance(u, MyABC)

MyABC.a.__set__(u, 3) # Boom


The patch I proposed above correctly raises the error:
TypeError: descriptor 'a' for 'MyABC' objects doesn't apply to
'Unrelated' object

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Fri Feb 15 20:31:06 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 15 Feb 2008 19:31:06 -0000
Subject: [issue1777134] minidom pretty xml output improvement
Message-ID: <1203103866.48.0.257042417324.issue1777134@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

If the patch would have better styling ("if(onetextnode == True):"), correct the test it breaks, and even better, add new ones, I guess it 
would be an acceptable one.

----------
nosy: +vdupras

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777134>
_____________________________________

From report at bugs.python.org  Fri Feb 15 21:00:13 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 15 Feb 2008 20:00:13 -0000
Subject: [issue2123] ctypes pointer not always keeping target alive
In-Reply-To: <1203085504.98.0.560350426708.issue2123@psf.upfronthosting.co.za>
Message-ID: <1203105613.79.0.707144726286.issue2123@psf.upfronthosting.co.za>


Thomas Heller added the comment:

May I ask: do you have a real use case for this, or is it a carefully
constructed example?

Of course I take all the blame for not defining/documenting this
stuff.  My current view is this:

Python code                     C code
=======================         ================

ptr = POINTER(c_long)()         int *ptr = NULL;
x = c_long(42)                  int x = 42;

ptr.contents = x                ptr = &x;

a = ptr[0]                      int a = *ptr;
b = ptr[n]                      int b = ptr[n];

Assigning to .contents changes 'where the pointer points to'.
__setitem__ changes the pointed to memory location; __getitem__
retrieves the pointed to memory location.

Having said that, it is no longer clear to me what reading the
.contents attribute should mean.  Would making the .contents attribute
write-only help - is it impossible to construct this 'bug' without
assigning to .contents?

----------
assignee:  -> theller
nosy: +theller

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2123>
__________________________________

From report at bugs.python.org  Fri Feb 15 21:13:16 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 15 Feb 2008 20:13:16 -0000
Subject: [issue1734234] Fast path for unicodedata.normalize()
Message-ID: <1203106396.07.0.641097578119.issue1734234@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

It's a very interesting patch. I wonder why it fell into oblivion. stuff 
like "unicode.normalize('NFC', u'\xe9')" was more than twice as fast for 
me.

Making sure that all unicode is normalized can be a bottleneck in a lot 
of applications (it somewhat is in my apps).

The downside is that it makes test_codecs and test_unicode_file fail.

----------
nosy: +vdupras

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1734234>
_____________________________________

From report at bugs.python.org  Fri Feb 15 21:32:45 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 20:32:45 -0000
Subject: [issue1061803] Source code encoding in IDLE console
Message-ID: <1203107564.97.0.69839286483.issue1061803@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

No response from OP, closing.

----------
assignee: loewis -> kbk
resolution:  -> rejected

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1061803>
_____________________________________

From report at bugs.python.org  Fri Feb 15 21:35:27 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 20:35:27 -0000
Subject: [issue1948] Cant open python gui using VISTA
In-Reply-To: <1201462739.88.0.734539859059.issue1948@psf.upfronthosting.co.za>
Message-ID: <1203107727.39.0.784939009558.issue1948@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

Please switch to the recently released 2.5.2 and let us know if the 
problem is still there.

----------
priority: high -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1948>
__________________________________

From report at bugs.python.org  Fri Feb 15 21:36:54 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 20:36:54 -0000
Subject: [issue1599] IDLE hangs if os.spwanv command is given
In-Reply-To: <1198817915.6.0.119772685048.issue1599@psf.upfronthosting.co.za>
Message-ID: <1203107814.72.0.623366830496.issue1599@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

No response from OP, closing.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1599>
__________________________________

From report at bugs.python.org  Fri Feb 15 21:42:22 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 20:42:22 -0000
Subject: [issue1061803] Source code encoding in IDLE console
Message-ID: <1203108142.39.0.215426666527.issue1061803@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser:


----------
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1061803>
_____________________________________

From report at bugs.python.org  Fri Feb 15 22:30:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 15 Feb 2008 21:30:41 -0000
Subject: [issue2115] __slots__ make attribute setting 10x slower
In-Reply-To: <1203012098.28.0.839264314729.issue2115@psf.upfronthosting.co.za>
Message-ID: <1203111041.71.0.61780512669.issue2115@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I think I fixed the issue.
"svn annotate" showed that the exact same optimization was applied on
__slots__ read access, five years ago: r28297.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2115>
__________________________________

From report at bugs.python.org  Fri Feb 15 22:40:42 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 15 Feb 2008 21:40:42 -0000
Subject: [issue2067] file.__exit__ does not call subclass' close method
In-Reply-To: <1202742715.17.0.365952775258.issue2067@psf.upfronthosting.co.za>
Message-ID: <1203111642.56.0.332607916303.issue2067@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

The patch looks good, I've tested it on trunk and also release25-maint.
It applies with fuzz and one has to add a "from __future import
with_statement".
I think this should also be applied to release25-maint. IMHO, this is a
rather severe problem, as it can easily lead to data loss.

----------
nosy: +schmir
severity: normal -> major
versions: +Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2067>
__________________________________

From report at bugs.python.org  Fri Feb 15 22:57:15 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 21:57:15 -0000
Subject: [issue2050] IDLE - make ScriptBinding event handlers return 'break'
In-Reply-To: <1202474747.18.0.823869647576.issue2050@psf.upfronthosting.co.za>
Message-ID: <1203112635.09.0.554004088476.issue2050@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

r60843. Thanks for the patch!

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2050>
__________________________________

From report at bugs.python.org  Fri Feb 15 23:01:56 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 22:01:56 -0000
Subject: [issue2061] IDLE - autocompletion to support alternate patch
	separators
In-Reply-To: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>
Message-ID: <1203112916.82.0.0187127573939.issue2061@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

Why do we care about Python 2.2?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2061>
__________________________________

From report at bugs.python.org  Fri Feb 15 23:02:20 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 22:02:20 -0000
Subject: [issue2061] IDLE - autocompletion to support alternate path separators
In-Reply-To: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>
Message-ID: <1203112940.73.0.357925007114.issue2061@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser:


----------
title: IDLE - autocompletion to support alternate patch separators -> IDLE - autocompletion to support alternate path separators

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2061>
__________________________________

From report at bugs.python.org  Fri Feb 15 23:19:34 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 22:19:34 -0000
Subject: [issue1334] IDLE - Fix several highlighting bugs
In-Reply-To: <1193404569.43.0.620999793422.issue1334@psf.upfronthosting.co.za>
Message-ID: <1203113974.06.0.259897310323.issue1334@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser:


Removed file: http://bugs.python.org/file8618/IDLE_highlighting.071026.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1334>
__________________________________

From report at bugs.python.org  Fri Feb 15 23:25:44 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 15 Feb 2008 22:25:44 -0000
Subject: [issue1334] IDLE - Fix several highlighting bugs
In-Reply-To: <1193404569.43.0.620999793422.issue1334@psf.upfronthosting.co.za>
Message-ID: <1203114344.75.0.317162628051.issue1334@psf.upfronthosting.co.za>


Kurt B. Kaiser added the comment:

r60844. Thanks for the patch!

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1334>
__________________________________

From report at bugs.python.org  Sat Feb 16 00:48:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 15 Feb 2008 23:48:33 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203119313.03.0.102998963013.issue2124@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

On systems that support catalogs, the parsers should be changed to
support public identifiers, using local copies of these DTDs. 

However, I see really no way how the library could avoid resolving the
DTDs altogether. The blog is WRONG in claiming that the system
identifier is not a downloadable URL, but a mere identification (the
namespace is a mere identification, but our parsers would never try to
download anything). The parser needs the DTDs in case external entities
occur in the document (of course, download could be delayed until the
first reference occurs).

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sat Feb 16 02:38:17 2008
From: report at bugs.python.org (stranger4good)
Date: Sat, 16 Feb 2008 01:38:17 -0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203063393.24.0.461861905927.issue2118@psf.upfronthosting.co.za>
Message-ID: <841873.95285.qm@web55107.mail.re4.yahoo.com>


stranger4good added the comment:

Not in so many words, but yes it does

I cite:

exception SMTPException 
Base exception class for all exceptions raised by this
module
...
exception SMTPConnectError 
Error occurred during establishment of a connection
with the server. 
...

Note the word "all". So, at least one should be able
to catch SMTPException, but it is not the case

Just my 2 cents. I do believe it is a great piece of
work.

Regards

--- Christian Heimes <report at bugs.python.org> wrote:

> 
> Christian Heimes added the comment:
> 
> Why is this a bug? Do the docs promise that smtplib
> only raises
> SMTPConnectError?
> 
> ----------
> nosy: +tiran
> priority:  -> normal
> 
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2118>
> __________________________________
> 

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Sat Feb 16 04:18:38 2008
From: report at bugs.python.org (sandy)
Date: Sat, 16 Feb 2008 03:18:38 -0000
Subject: [issue960406] unblock signals in threads
Message-ID: <1203131918.43.0.681940016151.issue960406@psf.upfronthosting.co.za>


Changes by sandy:


----------
components: +XML
type:  -> rfe

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue960406>
____________________________________

From report at bugs.python.org  Sat Feb 16 04:19:45 2008
From: report at bugs.python.org (sandy)
Date: Sat, 16 Feb 2008 03:19:45 -0000
Subject: [issue960406] handler
Message-ID: <1203131985.78.0.924576531898.issue960406@psf.upfronthosting.co.za>


Changes by sandy:


----------
severity: normal -> critical
title: unblock signals in threads -> handler
type: rfe -> security

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue960406>
____________________________________

From report at bugs.python.org  Sat Feb 16 05:25:10 2008
From: report at bugs.python.org (sandy)
Date: Sat, 16 Feb 2008 04:25:10 -0000
Subject: [issue960406] unblock signals in threads
Message-ID: <1203135910.19.0.432954751399.issue960406@psf.upfronthosting.co.za>


sandy added the comment:

undoing spam

----------
components:  -XML
nosy: +sandylovesedward
severity: critical -> normal
title: handler -> unblock signals in threads
type: security -> 

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue960406>
____________________________________

From report at bugs.python.org  Sat Feb 16 05:29:37 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 16 Feb 2008 04:29:37 -0000
Subject: [issue960406] unblock signals in threads
Message-ID: <1203136177.56.0.453420255144.issue960406@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

restore nosy list

----------
nosy:  -sandylovesedward

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue960406>
____________________________________

From report at bugs.python.org  Sat Feb 16 06:14:18 2008
From: report at bugs.python.org (Andrew Trusty)
Date: Sat, 16 Feb 2008 05:14:18 -0000
Subject: [issue1124861] subprocess fails on GetStdHandle in interactive GUI
Message-ID: <1203138858.47.0.755305293359.issue1124861@psf.upfronthosting.co.za>


Andrew Trusty added the comment:

I agree with Daniel, I think this bug or a variant is still present in
2.5.1 because my wxPython app on Windows XP would fail to execute a
Popen with only stdout using PIPE but succeeded with the described
workaround of having stdout, stderr, and stdin set to PIPE.

----------
nosy: +atrusty
versions: +Python 2.5 -Python 2.4

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1124861>
_____________________________________

From report at bugs.python.org  Sat Feb 16 08:40:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Feb 2008 07:40:00 -0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1203147600.71.0.122235008391.issue2118@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I see! You are right. Either the docs or the code need an update

----------
keywords: +easy
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Sat Feb 16 09:43:47 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Sat, 16 Feb 2008 08:43:47 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203151427.38.0.553217457314.issue2124@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

The blog page talked about 503 responses. What about issuing a warning 
on these responses? Maybe it would be enough to make developers aware of 
the problem?

Or what about in-memory caching of the DTDs? Sure, it wouldn't be as 
good as a catalog or anything, but it might help for the worst cases?

----------
nosy: +vdupras

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sat Feb 16 09:52:11 2008
From: report at bugs.python.org (Armin Rigo)
Date: Sat, 16 Feb 2008 08:52:11 -0000
Subject: [issue2123] ctypes pointer not always keeping target alive
In-Reply-To: <1203085504.98.0.560350426708.issue2123@psf.upfronthosting.co.za>
Message-ID: <1203151931.9.0.660514503135.issue2123@psf.upfronthosting.co.za>


Armin Rigo added the comment:

We're finding such bugs because we are trying to reimplement ctypes in PyPy.

I guess your last question was "is it impossible to construct this 'bug'
without *reading* .contents?".  The answer is that it doesn't change
much; you can replace all the reads from .contents with reads from [0],
and still see the issue.  See attached y.py, where I've put the
equivalent C code in comments.

Added file: http://bugs.python.org/file9438/y.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2123>
__________________________________

From report at bugs.python.org  Sat Feb 16 10:37:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 16 Feb 2008 09:37:45 -0000
Subject: [issue2120] broken links in advocacy HOWTO
In-Reply-To: <1203034613.19.0.44109712509.issue2120@psf.upfronthosting.co.za>
Message-ID: <1203154664.21.0.0860361918493.issue2120@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed in r60855, thanks!

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2120>
__________________________________

From report at bugs.python.org  Sat Feb 16 14:16:58 2008
From: report at bugs.python.org (June Kim)
Date: Sat, 16 Feb 2008 13:16:58 -0000
Subject: [issue2126] BaseHTTPServer.py
Message-ID: <1203167818.82.0.906473822.issue2126@psf.upfronthosting.co.za>


Changes by June Kim:


----------
components: Library (Lib)
nosy: juneaftn, rhettinger
severity: normal
status: open
title: BaseHTTPServer.py
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2126>
__________________________________

From report at bugs.python.org  Sat Feb 16 14:18:58 2008
From: report at bugs.python.org (June Kim)
Date: Sat, 16 Feb 2008 13:18:58 -0000
Subject: [issue2126] BaseHTTPServer.py and long POST from IE
In-Reply-To: <1203167938.11.0.556138107236.issue2126@psf.upfronthosting.co.za>
Message-ID: <1203167938.11.0.556138107236.issue2126@psf.upfronthosting.co.za>


New submission from June Kim:

http://bugs.python.org/issue430160
http://bugs.python.org/issue427345

These two issues refer to the same bug, which occurs when there is a
POST from an Internet Explorer and the POST's content is long enough.
The issue was resolved by changing the CGIHTTPServer.py to consume the
remaining garbage. However, the bug potentially remains with
BaseHTTPServer.py(and hence its descendants like SimpleHTTPServer, and
3rd party libraries like MoinMoin's stand alone server).

People should have the knowledge of the IE POST bug and put the code
for treating it everytime when they use BaseHTTPServer.

Simple way to solve this is inserting the garbage consuming code in
the "finish" method:

        while select.select([self.rfile], [],[],0)[0]:
           if not self.rfile.read(1): break

----------
title: BaseHTTPServer.py -> BaseHTTPServer.py and long POST from IE

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2126>
__________________________________

From report at bugs.python.org  Sat Feb 16 14:23:59 2008
From: report at bugs.python.org (June Kim)
Date: Sat, 16 Feb 2008 13:23:59 -0000
Subject: [issue2126] BaseHTTPServer.py fails long POST from IE
In-Reply-To: <1203167938.11.0.556138107236.issue2126@psf.upfronthosting.co.za>
Message-ID: <1203168239.47.0.75959920057.issue2126@psf.upfronthosting.co.za>


Changes by June Kim:


----------
title: BaseHTTPServer.py and long POST from IE -> BaseHTTPServer.py fails long POST from IE

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2126>
__________________________________

From report at bugs.python.org  Sat Feb 16 15:08:48 2008
From: report at bugs.python.org (Damien Elmes)
Date: Sat, 16 Feb 2008 14:08:48 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>


New submission from Damien Elmes:

The docs on http://docs.python.org/lib/sqlite3-Module-Contents.html
should mention that the connection string should always be UTF-8,
regardless of the encoding system of the underlying filesystem. See the
'note to windows users' on 

http://www.sqlite.org/c3ref/open.html

----------
components: Documentation
messages: 62456
nosy: resolve1
severity: normal
status: open
title: sqlite3 docs should mention utf8 requirement
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Sat Feb 16 15:35:59 2008
From: report at bugs.python.org (Daniel Serodio)
Date: Sat, 16 Feb 2008 14:35:59 -0000
Subject: [issue1124861] subprocess fails on GetStdHandle in interactive GUI
Message-ID: <1203172559.61.0.558391856082.issue1124861@psf.upfronthosting.co.za>


Daniel Serodio added the comment:

Is there any chance of having this fixed for 2.5.2 ?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1124861>
_____________________________________

From report at bugs.python.org  Sat Feb 16 17:27:46 2008
From: report at bugs.python.org (Giovanni Bajo)
Date: Sat, 16 Feb 2008 16:27:46 -0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>


New submission from Giovanni Bajo:

Under Windows, sys.argv is created through the Windows ANSI API.

When you have a file/directory which can't be represented in the 
system encoding (eg: a japanese-named file or directory on a Western 
Windows), Windows will encode the filename to the system encoding using
what we call the "replace" policy, and thus sys.argv[] will contain an
entry like "c:\\foo\\??????????????.dat".

My suggestion is that:

* At the Python level, we still expose a single sys.argv[], which will 
contain unicode strings. I think this exactly matches what Py3k does now. 

* At the C level, I believe it involves using GetCommandLineW() and 
CommandLineToArgvW() in WinMain.c, but should Py_Main/PySys_SetArgv() be 
changed to also accept wchar_t** arguments? Or is it better to allow for 
NULL to be passed (under Windows at least), so that the Windows
code-path in there can use GetCommandLineW()/CommandLineToArgvW() to get
the current process' arguments?

----------
components: Interpreter Core
messages: 62458
nosy: giovannibajo
severity: normal
status: open
title: sys.argv is wrong for unicode strings
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
__________________________________

From report at bugs.python.org  Sat Feb 16 17:32:41 2008
From: report at bugs.python.org (June Kim)
Date: Sat, 16 Feb 2008 16:32:41 -0000
Subject: [issue2129] Link error of gethostbyaddr and gethostname in Python
	Manuals (the chm file)
In-Reply-To: <1203179561.47.0.405991627355.issue2129@psf.upfronthosting.co.za>
Message-ID: <1203179561.47.0.405991627355.issue2129@psf.upfronthosting.co.za>


New submission from June Kim:

Finding gethostname and gethostbyaddr entities from the index tab and 
clicking them in Python25.chm results in showing up the wrong section 
of 14.1.1 Process Parameters, instead of the proper section 17.2 
socket.

----------
components: Documentation
messages: 62459
nosy: juneaftn
severity: minor
status: open
title: Link error of gethostbyaddr and gethostname in Python Manuals (the chm file)
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2129>
__________________________________

From report at bugs.python.org  Sat Feb 16 17:54:06 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 16 Feb 2008 16:54:06 -0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1203180846.8.0.81043907644.issue2128@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The issue is related to #1342

Since we have dropped support for older versions of Windows (9x, ME,
NT4) I like to get the Python interface to argv, env and files fixed.

----------
components: +Windows
nosy: +tiran
priority:  -> high
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
__________________________________

From report at bugs.python.org  Sat Feb 16 18:36:45 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 16 Feb 2008 17:36:45 -0000
Subject: [issue2110] Implement __format__ for Decimal
In-Reply-To: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>
Message-ID: <1203183405.3.0.722765987636.issue2110@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Please, be my guest!

Thanks!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2110>
__________________________________

From report at bugs.python.org  Sat Feb 16 19:21:25 2008
From: report at bugs.python.org (Giovanni Bajo)
Date: Sat, 16 Feb 2008 18:21:25 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1203186085.21.0.0710341852062.issue2066@psf.upfronthosting.co.za>


Giovanni Bajo added the comment:

Making the standard Windows Python DLL larger is not only a problem of
disk size: it will make all packages produced by PyInstaller or py2exe
larger, and that means lots of wasted bandwidth.

I see that MvL is still -1 on simply splitting CJK codecs out, and vetos
it by asking for a generalization work of insane proportion (a
hard-to-define PEP, an entirely new build system for Windows, etc.).

I understand (and *agree*) that having a general rule would be a much
superior solution, but CJK is already almost 50% of the python.dll, so
it *is* already a special case by any means. And special cases like
these  could be handled with special-case decisions.

Thus, I still strongly disagree with MvL and would like CJK be split out
 of python.dll as soon as possible. I would not really ask this for any
other modules but CJK, and understand that further actions would really
require a PEP and a new build system for Windows.

So, I ask again MvL to soften his position and reconsider the CJK
splitting in all its singularity. Please!

(in case it's not clear, I would prepare a patch to split CJK out anyday
if there were hopes that it gets accepted)

----------
nosy: +giovannibajo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Sat Feb 16 20:34:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Feb 2008 19:34:22 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1203190462.88.0.607135843876.issue1813@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

The C library's tolower() and toupper() are used in a handful of source
files. It might make sense to replace some of those calls with
ascii-only versions of the corresponding functions.

Modules/_sre.c:    return ((ch) < 256 ? (unsigned int)tolower((ch)) : ch);
Modules/_sqlite/cursor.c:        *dst++ = tolower(*src++);
Modules/stropmodule.c:			*s_new = tolower(c);
Modules/stropmodule.c:			*s_new = toupper(c);
Modules/stropmodule.c:			*s_new = toupper(c);
Modules/stropmodule.c:			*s_new = tolower(c);
Modules/stropmodule.c:			*s_new = toupper(c);
Modules/stropmodule.c:			*s_new = tolower(c);
Modules/unicodedata.c:        h = (h * scale) + (unsigned char)
toupper(Py_CHARMASK(s[i]));
Modules/unicodedata.c:        if (toupper(Py_CHARMASK(name[i])) !=
buffer[i])
Modules/_tkinter.c:		argv0[0] = tolower(Py_CHARMASK(argv0[0]));
Modules/binascii.c:			c = tolower(c);
Objects/stringobject.c:			s[i] = _tolower(c);
Objects/stringobject.c:			s[i] = _toupper(c);
Objects/stringobject.c:			    c = toupper(c);
Objects/stringobject.c:			    c = tolower(c);
Objects/stringobject.c:			*s_new = toupper(c);
Objects/stringobject.c:			*s_new = tolower(c);
Objects/stringobject.c:			*s_new = toupper(c);
Objects/stringobject.c:			*s_new = tolower(c);
Parser/tokenizer.c:		else buf[i] = tolower(c);
Python/codecs.c:            ch = tolower(Py_CHARMASK(ch));
Python/dynload_win.c:		first  = tolower(*string1);
Python/dynload_win.c:		second = tolower(*string2);
Python/pystrcmp.c:	while ((--size > 0) && (tolower(*s1) == tolower(*s2))) {
Python/pystrcmp.c:	return tolower(*s1) - tolower(*s2);
Python/pystrcmp.c:	while (*s1 && (tolower(*s1++) == tolower(*s2++))) {
Python/pystrcmp.c:	return (tolower(*s1) - tolower(*s2));

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Sat Feb 16 20:58:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Feb 2008 19:58:27 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1203191907.78.0.663633794334.issue1813@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

As for the .upper() and .lower() methods, they are used in quite a bunch
of standard library modules :-/...

Lib/base64.py
Lib/BaseHTTPServer.py
Lib/bsddb/test/test_compare.py
Lib/bsddb/test/test_dbobj.py
Lib/CGIHTTPServer.py
Lib/cgi.py
Lib/compiler/ast.py
Lib/ConfigParser.py
Lib/cookielib.py
Lib/Cookie.py
Lib/csv.py
Lib/ctypes/test/test_byteswap.py
Lib/ctypes/util.py
Lib/decimal.py
Lib/distutils/command/bdist_rpm.py
Lib/distutils/command/bdist_wininst.py
Lib/distutils/command/register.py
Lib/distutils/msvc9compiler.py
Lib/distutils/msvccompiler.py
Lib/distutils/sysconfig.py
Lib/distutils/tests/test_dist.py
Lib/distutils/util.py
Lib/email/charset.py
Lib/email/encoders.py
Lib/email/header.py
Lib/email/__init__.py
Lib/email/message.py
Lib/email/_parseaddr.py
Lib/email/test/test_email.py
Lib/email/test/test_email_renamed.py
Lib/encodings/idna.py
Lib/encodings/punycode.py
Lib/formatter.py
Lib/ftplib.py
Lib/gettext.py
Lib/htmllib.py
Lib/HTMLParser.py
Lib/httplib.py
Lib/idlelib/configDialog.py
Lib/idlelib/EditorWindow.py
Lib/idlelib/IOBinding.py
Lib/idlelib/keybindingDialog.py
Lib/idlelib/PyShell.py
Lib/idlelib/SearchDialogBase.py
Lib/idlelib/tabbedpages.py
Lib/idlelib/TreeWidget.py
Lib/imaplib.py
Lib/inspect.py
Lib/lib-tk/turtle.py
Lib/locale.py
Lib/logging/handlers.py
Lib/logging/__init__.py
Lib/_LWPCookieJar.py
Lib/macpath.py
Lib/mailcap.py
Lib/markupbase.py
Lib/mhlib.py
Lib/mimetools.py
Lib/mimetypes.py
Lib/mimify.py
Lib/msilib/__init__.py
Lib/nntplib.py
Lib/ntpath.py
Lib/nturl2path.py
Lib/optparse.py
Lib/os2emxpath.py
Lib/os.py
Lib/pdb.py
Lib/plat-irix5/flp.py
Lib/plat-irix6/flp.py
Lib/plat-mac/buildtools.py
Lib/plat-mac/gensuitemodule.py
Lib/plat-riscos/riscospath.py
Lib/pyclbr.py
Lib/rfc822.py
Lib/robotparser.py
Lib/sgmllib.py
Lib/SimpleHTTPServer.py
Lib/smtpd.py
Lib/smtplib.py
Lib/socket.py
Lib/sqlite3/test/hooks.py
Lib/sre_constants.py
Lib/stringold.py
Lib/stringprep.py
Lib/string.py
Lib/_strptime.py
Lib/subprocess.py
Lib/test/regrtest.py
Lib/test/test_bigmem.py
Lib/test/test_codeccallbacks.py
Lib/test/test_codecs.py
Lib/test/test_cookielib.py
Lib/test/test_datetime.py
Lib/test/test_decimal.py
Lib/test/test_deque.py
Lib/test/test_descr.py
Lib/test/test_fileinput.py
Lib/test/test_grp.py
Lib/test/test_hmac.py
Lib/test/test_httplib.py
Lib/test/test_os.py
Lib/test/test_smtplib.py
Lib/test/test_sort.py
Lib/test/test_ssl.py
Lib/test/test_strop.py
Lib/test/test_strptime.py
Lib/test/test_support.py
Lib/test/test_ucn.py
Lib/test/test_unicodedata.py
Lib/test/test_urllib2.py
Lib/test/test_urllib.py
Lib/test/test_wsgiref.py
Lib/test/test_xmlrpc.py
Lib/urllib2.py
Lib/urllib.py
Lib/urlparse.py
Lib/UserString.py
Lib/uuid.py
Lib/warnings.py
Lib/webbrowser.py
Lib/wsgiref/handlers.py
Lib/wsgiref/headers.py
Lib/wsgiref/simple_server.py
Lib/wsgiref/util.py
Lib/wsgiref/validate.py
Lib/xml/dom/minidom.py
Lib/xml/dom/xmlbuilder.py
Lib/xmllib.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Sat Feb 16 21:01:38 2008
From: report at bugs.python.org (Tal Einat)
Date: Sat, 16 Feb 2008 20:01:38 -0000
Subject: [issue2061] IDLE - autocompletion to support alternate path separators
In-Reply-To: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>
Message-ID: <1203192098.11.0.835952022936.issue2061@psf.upfronthosting.co.za>


Tal Einat added the comment:

Umm, that's me being silly and forgetting to remove some backwards
compatibility stuff.

Revised (simpler) version attached.

Added file: http://bugs.python.org/file9439/IDLE_AutoComplete_path_separators.080216.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2061>
__________________________________

From report at bugs.python.org  Sat Feb 16 21:04:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Feb 2008 20:04:33 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1203192273.81.0.554481227501.issue1813@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Even if we don't fix all uses of (?to)(lower|upper) in the source tree,
I think it's important that codec and locale lookup work properly when
the current locale defines non-latin case folding for latin characters.
Here is a patch.

Perhaps also the str type should grow ascii_lower() and ascii_upper()
methods, since many cases of using lower() and upper() actually assume
ascii semantics (e.g. for parsing of HTTP or SMTP headers).

Added file: http://bugs.python.org/file9440/turklocale.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Sat Feb 16 21:04:38 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Feb 2008 20:04:38 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1203192278.51.0.28376608688.issue1813@psf.upfronthosting.co.za>


Changes by Antoine Pitrou:


----------
versions: +Python 2.6 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Sat Feb 16 21:32:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Feb 2008 20:32:32 -0000
Subject: [issue1943] improved allocation of PyUnicode objects
In-Reply-To: <1201387475.19.0.206333594078.issue1943@psf.upfronthosting.co.za>
Message-ID: <1203193952.63.0.232370560339.issue1943@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is an updated patch, to comply with the introduction of the
PyUnicode_ClearFreeList() function.

Added file: http://bugs.python.org/file9441/unialloc3.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1943>
__________________________________

From report at bugs.python.org  Sat Feb 16 22:11:30 2008
From: report at bugs.python.org (Technologov)
Date: Sat, 16 Feb 2008 21:11:30 -0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1203196290.34.0.462426635659.issue1220212@psf.upfronthosting.co.za>


Technologov added the comment:

Yes, this feature would be very important for me too...

Anybody knows, _when_ it will be integrated into Python ?

If this bugzilla supports email notifications, Please add me as "CC" for
this bug.

-Technologov

----------
nosy: +Technologov

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1220212>
_____________________________________

From report at bugs.python.org  Sat Feb 16 22:15:10 2008
From: report at bugs.python.org (Technologov)
Date: Sat, 16 Feb 2008 21:15:10 -0000
Subject: [issue2130] [feature-request] Please add bool data type to "optparse"
	module
In-Reply-To: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>
Message-ID: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>


New submission from Technologov:

hi !

Currently "optparse" module lacks "bool" data type parsing. It would be
nice to add this feature.

-Technologov, 16.02.2008.

----------
components: Extension Modules
messages: 62469
nosy: Technologov
severity: normal
status: open
title: [feature-request] Please add bool data type to "optparse" module
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2130>
__________________________________

From report at bugs.python.org  Sat Feb 16 22:30:47 2008
From: report at bugs.python.org (Technologov)
Date: Sat, 16 Feb 2008 21:30:47 -0000
Subject: [issue2131] "codecs" module on Windows uses incorrect end-of-line,
	wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>


New submission from Technologov:

"codecs" module on Windows writes incorrect end-of-line, making it
impossible to write Unicode files.

See below, how-to reproduce bug (Python 2.5.1 on Windows XP)
===================================================================

#buggy unicode support module:
import codecs
filewr=codecs.open('myfile.txt','w','utf-8')
filewr.write("abc"+"\n")
===================================================================
Now, try to open this 'myfile.txt' using Windows Notepad.
The bug is perfectly visible.

The code below, will give correct results however:
===================================================================

filewr=open('myfile.txt','w')

filewr.write("abc"+"\n")
===================================================================
Basically this bugs _prevents_ me from writing Unicode text files.

NOTE: I'm not sure, if this bug should relate to "Windows" or "Unicode"
component.
NOTE: This bug is reproducible, even without writing Unicode characters.

-Technologov, 16.02.2008.

----------
components: Unicode
messages: 62470
nosy: Technologov
severity: normal
status: open
title: "codecs" module on Windows uses incorrect end-of-line, wiriting broken Unicode (UTF-8) files
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sat Feb 16 23:13:14 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 16 Feb 2008 22:13:14 -0000
Subject: [issue2131] "codecs" module on Windows uses incorrect end-of-line,
	wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203199994.07.0.120754324411.issue2131@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Could explain what exactly is wrong with the end-of-line on Windows ?

Note that "Unicode text files" on Windows are generally interpreted as
UTF-16 encoded files. Perhaps that's what makes you think there's a bug.

----------
nosy: +lemburg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sat Feb 16 23:20:16 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 16 Feb 2008 22:20:16 -0000
Subject: [issue1813] Codec lookup failing under turkish locale
In-Reply-To: <1200150013.57.0.828744211276.issue1813@psf.upfronthosting.co.za>
Message-ID: <1203200416.58.0.1255902925.issue1813@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

I agree that it's a bit unfortunate that the 8-bit string APIs in Python
use the locale aware C functions per default (this should really be
reversed: there should be locale-aware .upper() and .lower() methods and
the the standard ones should work just like the Unicode ones - without
dependency on the locale, using ASCII mappings), but for historical
reasons this cannot easily be changed.

.lower() and .upper() for 8-bit strings were always locale dependent and
before the addition of Unicode, setting the locale was the most common
way to make an application understand different character sets.

In Python 3k the problem will probably go away, since .lower() and
.upper() will then no longer depend on the locale.

Perhaps we should just convert a few of the cases you found to using
Unicode strings instead of 8-bit strings in 2.6 ?! That would both make
the code more portable and also provide a clear statement of "this is a
text string", making porting to Py3k easier.

----------
nosy: +lemburg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1813>
__________________________________

From report at bugs.python.org  Sat Feb 16 23:27:37 2008
From: report at bugs.python.org (Technologov)
Date: Sat, 16 Feb 2008 22:27:37 -0000
Subject: [issue2131] "codecs" module on Windows uses incorrect end-of-line,
	wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203200857.03.0.727876581175.issue2131@psf.upfronthosting.co.za>


Technologov added the comment:

OK: try
filewr.write("abc"+"\n"+"abc")

The file will be generated with 7 bytes in it (must be 8, because
Windows has two-byte line-end).

Without using "codecs" modules, everything works fine, and the file will
have 8-bytes in it. (see 2nd example)

Plus, the text will be corrupted when opened with Windows Notepad.

-Technologov

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sun Feb 17 00:15:13 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 16 Feb 2008 23:15:13 -0000
Subject: [issue2131] "codecs" module on Windows uses incorrect end-of-line,
	wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203203713.04.0.127539156516.issue2131@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

As stated in the codecs.open() docstring: """Files are always opened in
binary mode, even if no binary mode was specified. This is done to avoid
data loss due to encodings using 8-bit values""". This certainly means
you have to insert "\r\n" yourself (instead of just "\n") if you want
the file contents to respect the end-of-line convention under Windows...

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sun Feb 17 00:47:37 2008
From: report at bugs.python.org (Paul Boddie)
Date: Sat, 16 Feb 2008 23:47:37 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203205657.25.0.481169902322.issue2124@psf.upfronthosting.co.za>


Paul Boddie added the comment:

(Andrew, thanks for making a bug, and apologies for not reporting this
in a timely fashion.)

Although an in-memory caching solution might seem to be sufficient, if
one considers things like CGI programs, it's clear that such programs
aren't going to benefit from such a solution. It would be interesting to
know what widely deployed software does use the affected parsers,
though. A Google code search might be helpful.

I think that the nicest compatible solution would be to have some kind
of filesystem cache for the downloaded resources, but I don't recall any
standard library caching solution of this nature. Things like being able
to write to a known directory, perhaps using the temporary file APIs
which should work even as a "very unprivileged" user, would be useful
properties of such a solution.

----------
nosy: +pboddie

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sun Feb 17 02:45:57 2008
From: report at bugs.python.org (Lea Wiemann)
Date: Sun, 17 Feb 2008 01:45:57 -0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1203212757.38.0.446477863722.issue1771@psf.upfronthosting.co.za>


Lea Wiemann added the comment:

Is this really necessary?

I see that the sorting code gets a little simpler, but I believe that 
there are valid use cases for cmp out there, where using a key would at 
least be cumbersome.  So why remove it when it's useful?

For instance, if you have an algorithm to determine the order in which 
any two elements should occur (and for some reason the algorithm 
satisfies transitivity) then it's usable as the cmp function, but 
turning it into a key function may be complicated (and adversly affect 
performance); you might end up having to map each element to a number 
or tuple describing the ordering properties of the element, which can 
be non-trivial.  Besides, it can also be non-obvious.

----------
nosy: +LeWiemann

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
__________________________________

From report at bugs.python.org  Sun Feb 17 02:49:37 2008
From: report at bugs.python.org (Lea Wiemann)
Date: Sun, 17 Feb 2008 01:49:37 -0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1203212977.38.0.360819600054.issue1771@psf.upfronthosting.co.za>


Lea Wiemann added the comment:

"Non-obvious" to the novice that this technique can be used, and non-
obvious to the reader of the program.

I'm envisioning key functions that return long sequences of -1/0/1 
integers, or numbers between 0 and 2**50...  Not good.

Instead of removing cmp, I'd suggest simply placing a note in the 
documentation saying that key is preferred over cmp, to encourage 
readability.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
__________________________________

From report at bugs.python.org  Sun Feb 17 02:55:40 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sun, 17 Feb 2008 01:55:40 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203213340.37.0.330254099001.issue2124@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

What if we just tried to make the remote accesses apparent to the user,
by making a warning.warn() call in the default implementation that was
deactivated by a setFeature() call.  With a warning, code will continue
to run but the user will at least be aware they're hitting a remote
resource, and can think about it, even if they decide to suppress the
warning.

We should also modify the docs to point this out; it's not likely to
help very much, but it's still worth doing.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sun Feb 17 03:47:25 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 17 Feb 2008 02:47:25 -0000
Subject: [issue1762] Inheriting from ABCs makes classes slower.
In-Reply-To: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
Message-ID: <1203216445.47.0.185991115449.issue1762@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I'd like a second opinion about whether it's a good idea to commit the
attached patch, which moves abc._Abstract into object. Its effect is to
speed

  ./python.exe -m timeit -s 'import abc' -s 'class Foo(object):
__metaclass__=abc.ABCMeta' 'Foo()'

up from 2.5us to 0.201us. For comparison:

  $ ./python.exe -m timeit -s 'import abc' -s 'class Foo(object): pass'
'Foo()'
  10000000 loops, best of 3: 0.203 usec per loop
  $ ./python.exe -m timeit -s 'import abc' -s 'class Foo(object):' -s '
 def __new__(cls): return super(Foo, cls).__new__(cls)' 'Foo()'
  1000000 loops, best of 3: 1.18 usec per loop
  $ ./python.exe -m timeit -s 'import abc' -s 'from decimal import
Decimal' 'Decimal()'
  100000 loops, best of 3: 9.51 usec per loop


After this patch, the only slowdown I can find is an extra .5us in
isinstance, so I think it'll be time to close this bug.

Added file: http://bugs.python.org/file9442/optimize_abc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________

From report at bugs.python.org  Sun Feb 17 06:09:30 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Feb 2008 05:09:30 -0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1203224970.18.0.302719580332.issue1771@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
__________________________________

From report at bugs.python.org  Sun Feb 17 06:27:29 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 17 Feb 2008 05:27:29 -0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1203226049.57.0.770210238556.issue1771@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, an object with a complex element-to-element comparison can define 
an __lt__() method and have it work with sort, min, max, etc.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
__________________________________

From report at bugs.python.org  Sun Feb 17 06:33:28 2008
From: report at bugs.python.org (Lea Wiemann)
Date: Sun, 17 Feb 2008 05:33:28 -0000
Subject: [issue1771] Remove cmp parameter to list.sort() and builtin.sorted()
In-Reply-To: <1199836926.78.0.118789346384.issue1771@psf.upfronthosting.co.za>
Message-ID: <1203226407.84.0.532794992666.issue1771@psf.upfronthosting.co.za>


Lea Wiemann added the comment:

I know, but I don't always want to define the comparison on the object 
itself, because it's not an intrinsic feature of the object.  It's just 
the way I happen to sort it right now.  (That's especially likely if 
the ordering algorithm is complex.)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1771>
__________________________________

From report at bugs.python.org  Sun Feb 17 07:14:50 2008
From: report at bugs.python.org (Leonid Evdokimov)
Date: Sun, 17 Feb 2008 06:14:50 -0000
Subject: [issue1404925] subprocess.Popen inside thread locks the thread in
	some case
Message-ID: <1203228890.53.0.627567806179.issue1404925@psf.upfronthosting.co.za>


Leonid Evdokimov added the comment:

I confirm the bug.

Deadlock at Linux 2.6 (^C does not work):
Python 2.4.4 (#1, Jan  8 2008, 23:42:40) 
[GCC 4.1.1 (Gentoo 4.1.1-r3)] on linux2

Sometimes work and sometimes fails with fatal error at FreeBSD 6.3:
Python 2.4.4 (#2, Oct 31 2007, 05:20:42) 
[GCC 3.4.6 [FreeBSD] 20060305] on freebsd6

before Popen
before first line
FFatal error '_pq_insert_tail: Already in priority queue' at line 200 in
file /usr/src/lib/libpthread/thread/thr_priority_queue.c (errno = 0)
after last line          

And sometimes it deadlocks and ^C shows same traceback Ralf Schmitt
already posted.

----------
nosy: +darkk

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1404925>
_____________________________________

From report at bugs.python.org  Sun Feb 17 07:58:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 17 Feb 2008 06:58:39 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203231518.97.0.0712755390811.issue2124@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

-1 on issuing a warning. I really cannot see much of a problem in this
entire issue. XML was designed to "be straightforwardly usable over the
Internet" (XML rec., section 1.1), and this issue is a direct
consequence of that design decision. You might just as well warn people
against using XML in the first place.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sun Feb 17 11:03:56 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 17 Feb 2008 10:03:56 -0000
Subject: [issue2130] [feature-request] Please add bool data type to "optparse"
	module
In-Reply-To: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>
Message-ID: <1203242636.57.0.74015984366.issue2130@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

Have you read
http://docs.python.org/lib/optparse-standard-option-actions.html ?

If yes, what is the problem with store_true/store_false ?

----------
nosy: +gpolo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2130>
__________________________________

From report at bugs.python.org  Sun Feb 17 11:44:40 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 17 Feb 2008 10:44:40 -0000
Subject: [issue2131] "codecs" module on Windows uses incorrect end-of-line,
	wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203245080.51.0.44688412924.issue2131@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

As Antoine already pointed out: the codecs.open() function does not
support the C lib's text mode. As a result, no magical conversion of a
single newline to a CRLF takes place.

Closing as invalid.

----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sun Feb 17 11:55:54 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 17 Feb 2008 10:55:54 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203245754.38.0.14190395821.issue2124@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

-1 on the systematic warnings too, but what I was talking about is a 
warning that would say "The server you are trying to fetch your resource 
from is refusing the connection. Don't cha think you misbehave?" only on 
5xx and 4xx responses, not on every remote resource fetching.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sun Feb 17 12:07:30 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 17 Feb 2008 11:07:30 -0000
Subject: [issue2066] Adding new CNS11643, a *huge* charset,
	support in cjkcodecs
In-Reply-To: <1202731134.77.0.201279568783.issue2066@psf.upfronthosting.co.za>
Message-ID: <1203246450.15.0.476333693782.issue2066@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Whether or not to keep placing all builtin modules into the Windows
Python DLL is not really a question to be discussed on the tracker.
Given the size of the Python DLL (around 2MB) and the extra 350kB that
the support for CNS11643 would cost, I think such a discussion is pretty
pointless.

I'm still +1 on the basis of enhancing the Taiwanese Python experience
by adding their standard character set to the default Python install.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2066>
__________________________________

From report at bugs.python.org  Sun Feb 17 12:34:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Feb 2008 11:34:05 -0000
Subject: [issue2131] "codecs" module on Windows uses incorrect end-of-line,
	wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203248045.73.0.614449152369.issue2131@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The note in the docstring wasn't in the documentation. Fixed this in r60873.

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sun Feb 17 12:46:35 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 17 Feb 2008 11:46:35 -0000
Subject: [issue2130] [feature-request] Please add bool data type to "optparse"
	module
In-Reply-To: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>
Message-ID: <1203248795.58.0.208694435026.issue2130@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Patches are always welcome

----------
keywords: +easy
nosy: +tiran
priority:  -> normal
type:  -> rfe
versions: +Python 2.6 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2130>
__________________________________

From report at bugs.python.org  Sun Feb 17 12:51:08 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 17 Feb 2008 11:51:08 -0000
Subject: [issue2131] "codecs" module on Windows uses incorrect end-of-line,
	wiriting broken Unicode (UTF-8) files
In-Reply-To: <1203197447.55.0.672622551318.issue2131@psf.upfronthosting.co.za>
Message-ID: <1203249068.31.0.0742215991434.issue2131@psf.upfronthosting.co.za>


Marc-Andre Lemburg added the comment:

Thanks, Georg.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2131>
__________________________________

From report at bugs.python.org  Sun Feb 17 15:05:48 2008
From: report at bugs.python.org (John Lenton)
Date: Sun, 17 Feb 2008 14:05:48 -0000
Subject: [issue2112] mmap.error should be a subclass of EnvironmentError and
	not a direct EnvironmentError
In-Reply-To: <1203001070.89.0.819333878266.issue2112@psf.upfronthosting.co.za>
Message-ID: <1203257148.8.0.294243307089.issue2112@psf.upfronthosting.co.za>


John Lenton added the comment:

Ran the regression test with this patch, all ok (on Ubuntu Gutsy).
Attached diff is the same, with the addition of the NEWS entry.

----------
nosy: +Chipaca
Added file: http://bugs.python.org/file9443/mmap3.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2112>
__________________________________

From report at bugs.python.org  Sun Feb 17 17:09:46 2008
From: report at bugs.python.org (Javier Mansilla)
Date: Sun, 17 Feb 2008 16:09:46 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1203264586.74.0.589200227621.issue1916@psf.upfronthosting.co.za>


Javier Mansilla added the comment:

I merged my working copy with your patches and they look fine. I fixed a
typo on the method doc ("is" instead of "i") so I'm attaching  my
inspect.py.diff patch

----------
nosy: +javimansilla
Added file: http://bugs.python.org/file9444/test_inspect.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Sun Feb 17 17:18:09 2008
From: report at bugs.python.org (Javier Mansilla)
Date: Sun, 17 Feb 2008 16:18:09 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1203265089.88.0.24315268605.issue1916@psf.upfronthosting.co.za>


Javier Mansilla added the comment:

Sorry, I attached the wrong file

The previous post saying "fixing typo" should attached inspect.py.diff.
This is the one.

Added file: http://bugs.python.org/file9445/test_inspect.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Sun Feb 17 17:24:21 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 17 Feb 2008 16:24:21 -0000
Subject: [issue1050828] reindent.py strips execute permission on Unix
Message-ID: <1203265461.45.0.610008210661.issue1050828@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Fixed in r60877, as of the description in my last comment.

----------
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1050828>
_____________________________________

From report at bugs.python.org  Sun Feb 17 17:24:38 2008
From: report at bugs.python.org (Javier Mansilla)
Date: Sun, 17 Feb 2008 16:24:38 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1203265478.41.0.429907580823.issue1916@psf.upfronthosting.co.za>


Javier Mansilla added the comment:

My dear, what is wrong with my browser (or with me). Now, yes, the one
with the typo.

Added file: http://bugs.python.org/file9446/inspect.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Sun Feb 17 17:25:59 2008
From: report at bugs.python.org (Javier Mansilla)
Date: Sun, 17 Feb 2008 16:25:59 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1203265559.45.0.105594371269.issue1916@psf.upfronthosting.co.za>


Javier Mansilla added the comment:

And now I'm attaching a new patch test_inspect.py.diff with a more
complete test coverage. You didn't add isgenerator nor
isgeneratorfunction tests. I did.

Added file: http://bugs.python.org/file9447/test_inspect.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Sun Feb 17 18:19:59 2008
From: report at bugs.python.org (Ron Adam)
Date: Sun, 17 Feb 2008 17:19:59 -0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1203268799.7.0.843563784396.issue2001@psf.upfronthosting.co.za>


Ron Adam added the comment:

Remade the diff with correct directory name so it patches correctly.

Is there a way to add the patch keyword?

Added file: http://bugs.python.org/file9448/pydocnotk.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
__________________________________

From report at bugs.python.org  Sun Feb 17 19:13:58 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 17 Feb 2008 18:13:58 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1203272038.19.0.40948851201.issue1916@psf.upfronthosting.co.za>


Changes by Facundo Batista:


Removed file: http://bugs.python.org/file9444/test_inspect.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Sun Feb 17 19:19:58 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 17 Feb 2008 18:19:58 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1203272398.67.0.347573767162.issue1916@psf.upfronthosting.co.za>


Changes by Facundo Batista:


Removed file: http://bugs.python.org/file9445/test_inspect.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Sun Feb 17 19:56:54 2008
From: report at bugs.python.org (Nathan Duran)
Date: Sun, 17 Feb 2008 18:56:54 -0000
Subject: [issue2132] Blocking sockets take entirely too long to timeout
In-Reply-To: <1203274614.89.0.5704894361.issue2132@psf.upfronthosting.co.za>
Message-ID: <1203274614.89.0.5704894361.issue2132@psf.upfronthosting.co.za>


New submission from Nathan Duran:

The following code:

import smtplib

test = smtplib.SMTP('mail.host.com')

will hang the entire script for about ten minutes when run on a machine 
which is connected to the internet via an ISP who blocks port 25 (which is 
pretty much all of them these days). Closer inspection of the smtplib 
sources reveals that it is making use of blocking sockets, which is all 
well and good, but I do not believe they should be allowed to block for 
such a ridiculously lengthy period of time. 

My task is to walk the list of MX records provided by a DNS query, connect 
to each server listed and check a user-supplied address for validity. If I 
have to wait 10 minutes for an exception to be thrown for each 
unresponsive server, this process could easily take hours per address, 
which is completely unacceptable. 

My workaround is to ditch smtplib entirely and write my own socket code, 
but setting a timeout on a socket throws it into non-blocking mode, which 
is not entirely what I want, either. PHP allows one to apply a perfectly 
sane timeout to a blocking socket without any difficulty, and this is 
something I'm frankly rather surprised to see Python choke on.

What I'd expect to see is an exception after less than a minute's worth of 
repeated failures so the caller can catch it and try another port.

----------
components: Library (Lib)
messages: 62498
nosy: khiltd
severity: normal
status: open
title: Blocking sockets take entirely too long to timeout
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2132>
__________________________________

From report at bugs.python.org  Sun Feb 17 19:58:01 2008
From: report at bugs.python.org (Giovanni Bajo)
Date: Sun, 17 Feb 2008 18:58:01 -0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1203274681.37.0.641196122438.issue2128@psf.upfronthosting.co.za>


Giovanni Bajo added the comment:

I'm attaching a simple patch that seems to work under Py3k. The trick is
that Py3k already attempts (not sure how or why) to decode argv using
utf-8. So it's sufficient to setup argv as UTF8-encoded strings.

Notice that brings the output of "python ?????" from this:

Fatal Python error: no mem for sys.argv
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 0-2:
invalid data

to this:

TypeError: zipimporter() argument 1 must be string without null bytes,
not str

which is expected since zipimporter_init() doesn't even know to ignore
unicode strings (let alone handle them correctly...).

Added file: http://bugs.python.org/file9449/argv_unicode.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
__________________________________

From report at bugs.python.org  Sun Feb 17 20:06:20 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 17 Feb 2008 19:06:20 -0000
Subject: [issue2112] mmap.error should be a subclass of EnvironmentError and
	not a direct EnvironmentError
In-Reply-To: <1203001070.89.0.819333878266.issue2112@psf.upfronthosting.co.za>
Message-ID: <1203275180.66.0.136710201828.issue2112@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Fixed in r60878. Thanks everybody!

----------
nosy: +facundobatista
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2112>
__________________________________

From report at bugs.python.org  Sun Feb 17 20:30:38 2008
From: report at bugs.python.org (Elliott Hughes)
Date: Sun, 17 Feb 2008 19:30:38 -0000
Subject: [issue2133] a typo in pydoc.py causes modules to be cyan instead of
	white
In-Reply-To: <1203276638.12.0.749996572649.issue2133@psf.upfronthosting.co.za>
Message-ID: <1203276638.12.0.749996572649.issue2133@psf.upfronthosting.co.za>


New submission from Elliott Hughes:

A typo ('#fffff' instead of '#ffffff') in pydoc.py causes the "Modules"
section to have cyan text instead of white text. I don't believe this is
deliberate because (a) it looks wrong and (b) anyone doing that
deliberately would have put a '0' in the color to make it look
deliberate. This patch doesn't address the large-scale duplication of
'#ffffff' (instead of using a constant, or even the named color
'white'), and just adds the single missing character.

----------
components: Demos and Tools
files: no-cyan-modules.diff.txt
messages: 62501
nosy: elliotth
severity: normal
status: open
title: a typo in pydoc.py causes modules to be cyan instead of white
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9450/no-cyan-modules.diff.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2133>
__________________________________

From report at bugs.python.org  Sun Feb 17 20:43:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 17 Feb 2008 19:43:37 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za>
Message-ID: <1203277417.9.0.652746928232.issue1740@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hmm, apparently another patch was committed in rev 60872.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Sun Feb 17 21:19:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 17 Feb 2008 20:19:38 -0000
Subject: [issue2132] Blocking sockets take entirely too long to timeout
In-Reply-To: <1203274614.89.0.5704894361.issue2132@psf.upfronthosting.co.za>
Message-ID: <1203279578.0.0.361998319022.issue2132@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I recommend that you stay with non-blocking sockets, and use select/poll
on all sockets. Then you can simultaneously check multiple servers, and
select will tell you which ones you got connected to. For this
application, putting a time-out on the socket and doing the connections
sequentially seems unreasonable - that's exactly what select was
invented for.

I don't understand the "setting a timeout ... is not entirely what I
want, either" remark. The only way to specify a timeout for connect *is*
to set it into non-blocking mode. I'm sure PHP does the same.

If you want to see timeouts for smtplib, a work-around is to set a
global timeout for all sockets, through socket.setdefaulttimeout. This
will transparently apply to smtplib as well.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2132>
__________________________________

From report at bugs.python.org  Sun Feb 17 21:25:00 2008
From: report at bugs.python.org (Anthony Lenton)
Date: Sun, 17 Feb 2008 20:25:00 -0000
Subject: [issue1224] SimpleHTTPServer doesn't understand // at beginning of
	path anymore
In-Reply-To: <1191237626.38.0.0266691685704.issue1224@psf.upfronthosting.co.za>
Message-ID: <1203279900.11.0.259779232785.issue1224@psf.upfronthosting.co.za>


Anthony Lenton added the comment:

Attached is an diff against trunk that adds philfr's suggesitions.  I've
also added a test file for testing url parsing, so's these things stay
fixed.  Updated Misc/NEWS.  No doc or functionallity modified.

----------
nosy: +elachuni, facundobatista
Added file: http://bugs.python.org/file9451/1224.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1224>
__________________________________

From report at bugs.python.org  Sun Feb 17 22:19:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 17 Feb 2008 21:19:12 -0000
Subject: [issue2133] a typo in pydoc.py causes modules to be cyan instead of
	white
In-Reply-To: <1203276638.12.0.749996572649.issue2133@psf.upfronthosting.co.za>
Message-ID: <1203283152.53.0.350169506813.issue2133@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed in r60883. Thanks!

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2133>
__________________________________

From report at bugs.python.org  Sun Feb 17 22:41:47 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sun, 17 Feb 2008 21:41:47 -0000
Subject: [issue1600] str.format() produces different output on different
	platforms (Py30a2)
In-Reply-To: <1197450243.14.0.729685827203.issue1600@psf.upfronthosting.co.za>
Message-ID: <1203284507.78.0.17669027753.issue1600@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Eric, because of this issue the windows buildbots turned to red.
Does the proposed patch still apply? of should be make the tests more
tolerant?

----------
nosy: +amaury.forgeotdarc, eric.smith

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Sun Feb 17 23:06:57 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Feb 2008 22:06:57 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za>
Message-ID: <1203286017.84.0.481028720809.issue1740@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Yeah, that's my fault. I forgot to search the issue tracker first before
committing the GHOP rewrite.

I will do a review of this patch and see which version is better.

----------
assignee:  -> brett.cannon
nosy: +brett.cannon

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Sun Feb 17 23:10:15 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Feb 2008 22:10:15 -0000
Subject: [issue1960] test_gdbm.py converted to unittest
In-Reply-To: <1201563061.25.0.859270038102.issue1960@psf.upfronthosting.co.za>
Message-ID: <1203286215.07.0.883423589266.issue1960@psf.upfronthosting.co.za>


Changes by Brett Cannon:


----------
assignee:  -> brett.cannon

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1960>
__________________________________

From report at bugs.python.org  Sun Feb 17 23:11:48 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Feb 2008 22:11:48 -0000
Subject: [issue1952] test_select.py converted to unittest
In-Reply-To: <1201483280.65.0.166319108689.issue1952@psf.upfronthosting.co.za>
Message-ID: <1203286308.06.0.689464209788.issue1952@psf.upfronthosting.co.za>


Changes by Brett Cannon:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1952>
__________________________________

From report at bugs.python.org  Sun Feb 17 23:12:37 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Feb 2008 22:12:37 -0000
Subject: [issue1864] test_locale doesn't use unittest
In-Reply-To: <1200655778.81.0.227494259318.issue1864@psf.upfronthosting.co.za>
Message-ID: <1203286357.61.0.514064547722.issue1864@psf.upfronthosting.co.za>


Changes by Brett Cannon:


----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1864>
__________________________________

From report at bugs.python.org  Sun Feb 17 23:13:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 17 Feb 2008 22:13:50 -0000
Subject: [issue2055] test_fcntl.py converted to unittest
In-Reply-To: <1202574695.1.0.144086248803.issue2055@psf.upfronthosting.co.za>
Message-ID: <1203286430.22.0.481360087264.issue2055@psf.upfronthosting.co.za>


Changes by Brett Cannon:


----------
assignee:  -> brett.cannon
nosy: +brett.cannon

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2055>
__________________________________

From report at bugs.python.org  Sun Feb 17 23:34:20 2008
From: report at bugs.python.org (Eric V. Smith)
Date: Sun, 17 Feb 2008 22:34:20 -0000
Subject: [issue1600] str.format() produces different output on different
	platforms (Py30a2)
In-Reply-To: <1197450243.14.0.729685827203.issue1600@psf.upfronthosting.co.za>
Message-ID: <1203287660.48.0.581779172953.issue1600@psf.upfronthosting.co.za>


Eric V. Smith added the comment:

The PEP 3101 float formatting code (in Objects/stringlib/formatter.h)
uses PyOS_ascii_formatd for all specifier codes except 'n'.  So applying
the patch would fix the issue that was originally brought up in msg58485.

I think the approach of the patch (if not its content, I haven't
inspected it yet) is correct.  Fix the underlying code and benefit from
this everywhere.  I don't think we should change the tests to be more
tolerant, I think we should be consistent across platforms.

My only concern is breaking code in the wild.  This seems like a change
with wide-reaching implications.

I think 'n' should also be addressed.  It calls PyOS_snprintf directly.

I'll review the patch and comment back here.  Unfortunately, I don't
have a Windows box set up for testing.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Mon Feb 18 00:00:30 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 17 Feb 2008 23:00:30 -0000
Subject: [issue2134] function generate_tokens at tokenize.py yields wrong
	token for colon
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>


New submission from Guilherme Polo:

function generate_tokes at tokenize.py yields token OP (51) for colon,
while it should be token COLON (11). It probably affects other python
versions as well.

I'm attaching a minor sample that demonstrates this, running it returns
the following output:

1 'if' (1, 0) (1, 2) if a == 2:
1 'a' (1, 3) (1, 4) if a == 2:
51 '==' (1, 5) (1, 7) if a == 2:
2 '2' (1, 8) (1, 9) if a == 2:
51 ':' (1, 9) (1, 10) if a == 2:
1 'print' (2, 0) (2, 5) print 'hey'
3 "'hey'" (2, 6) (2, 11) print 'hey'
0 '' (3, 0) (3, 0)

I didn't check if there are problems with other tokens, I noticed this
with colon because I was trying to make some improvements on tabnanny.

----------
components: Library (Lib)
files: tokenize_sample.py
messages: 62509
nosy: gpolo
severity: normal
status: open
title: function generate_tokens at tokenize.py yields wrong token for colon
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9452/tokenize_sample.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
__________________________________

From report at bugs.python.org  Mon Feb 18 00:11:19 2008
From: report at bugs.python.org (Douglas Greiman)
Date: Sun, 17 Feb 2008 23:11:19 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>


New submission from Douglas Greiman:

This patch reorganizes import.c to move functionality into two new PEP
302-style Importer objects.  I attempted to change as little as
feasible, but the patch is still ~4700 lines long, about 1000 of which
is new tests.

BuiltinImporter: handles C_BUILTIN and PY_FROZEN modules
DirectoryImporter: handles PY_SOURCE, PY_COMPILED, PKG_DIRECTORY,
C_EXTENSION modules

BuiltinImporter is put on sys.meta_path, DirectoryImporter is put on
sys.path_hooks.

To preserve backward compatibility of methods like imp.find_module(),
they use new variables sys.builtin_meta_path and sys.builtin_path_hooks
which are analogous to sys.meta_path and sys.path_hook but contain only
the two importer objects above.

Character encoding issues were substantial.  The existing code was
somewhat inscrutable in this regard.  The tests disabled in issue 1377
were re-added with more safeguards and harder tests.  It is possible to
import modules with non-ascii names from non-ascii paths.  Tested on
Windows XP and Linux.

Areas for discussion:

Naming: Names of the importer classes, names of variables, etc

sys: I added three variables to sys.  Is there a better alternative?

ModuleInfo: The importers use a somewhat tricky way to store an open
file between calls to importer.find_module() and importer.load_module(),
so that the new code doesn't do any more system calls that the old code.

semantics: There are many import corner cases where the semantics are
unknown or unclear.  

Frozen packages: the __path__ of a frozen package is a string rather
than a list, and it is possible to replace that string to change how
imports inside that package are resolved.  I have attempted to keep that
functionality intact but it's not clear that it's a feature rather than
a bug.

----------
components: Interpreter Core
files: builtin_importer-20080217.diff
messages: 62510
nosy: dgreiman
severity: normal
status: open
title: Restructure import.c into PEP 302 importer objects
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9453/builtin_importer-20080217.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Mon Feb 18 00:34:53 2008
From: report at bugs.python.org (John Lenton)
Date: Sun, 17 Feb 2008 23:34:53 -0000
Subject: [issue1945] Document back ported C functions
In-Reply-To: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za>
Message-ID: <1203291293.35.0.483523268703.issue1945@psf.upfronthosting.co.za>


John Lenton added the comment:

Copied documentation from the py3k branch for the functions mentioned in
the .h's (those were: PyLong_FromSsize_t, PyLong_FromSize_t,
PyLong_AsSsize_t, PyUnicode_FromStringAndSize, PyUnicode_FromString,
PyUnicode_FromFormat, and PyUnicode_FromFormatV). Tested by building the
documentation; everything seems to be in order. Added NEWS entry.

----------
nosy: +Chipaca
Added file: http://bugs.python.org/file9454/1945.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1945>
__________________________________

From report at bugs.python.org  Mon Feb 18 00:58:11 2008
From: report at bugs.python.org (ajaksu)
Date: Sun, 17 Feb 2008 23:58:11 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203292691.0.0.266930258143.issue2124@psf.upfronthosting.co.za>


ajaksu added the comment:

Martin, I agree that simply not resolving DTDs is an unreasonable
request (and said so in the blog post). But IMHO there are lots of
possible optimizations, and the most valuable would be those darn easy
for newcomers to understand and use.

In Python, a winning combo would be an arbitrary (and explicit) FS
"dtdcache" that people could use with simple a drop-in import (from a
third-party module?). Perhaps the cache lives in a pickled dictionary
with IDs, checksums and DTDs. Could also be a sqlite DB, if updating the
dict becomes problematic.

In that scenario, AMK could save latter W3C hits with:

from xml.sax import make_parser
from dtdcache.sax.saxutils import prepare_input_source # <- dtdcache
parser = make_parser()
inp = prepare_input_source('file:file.xhtml', cache="/tmp/xmlcache")

It might be interesting to have read-only, force-write and read-write
modes. Not sure how to map that on EntityResolver and DTD consumers (I'm
no XML user myself).

Regarding the std-lib, I believe effective caching hooks for DTDs trump
implementing in-memory or sqlite/FS. IMNSHO, correct, accessible support
for catalogs shouldn't be the only change, as caching should give better
performance on both ends.

----------
nosy: +ajaksu2

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Mon Feb 18 02:02:49 2008
From: report at bugs.python.org (Atul Varma)
Date: Mon, 18 Feb 2008 01:02:49 -0000
Subject: [issue2136] urllib2 basic auth handler doesn't handle realm names in
	single-quoted strings
In-Reply-To: <1203296568.46.0.747126970867.issue2136@psf.upfronthosting.co.za>
Message-ID: <1203296568.46.0.747126970867.issue2136@psf.upfronthosting.co.za>


New submission from Atul Varma:

This isn't necessarily a bug in Python--it's really a bug in websites
that produce what are technically malformed WWW-Authenticate headers, I
believe.

According to RFC 2617, a WWW-Authenticate header should be of the form:

  WWW-Authenticate: Basic realm="Private"

However, some websites, produce the header using single-quotes:

  WWW-Authenticate: Basic realm='Private'

The Firefox browser deals with this gracefully, but Python's urllib2
does not; specifically, an AbstractBasicAuthHandler does not recognize
the second type of header as an auth header at all, and as a result it's
impossible to access sites protected with such headers.

The attached patch alters the behavior of the class to deal with this
situation gracefully, and also adds a unit test to ensure that the
functionality works.

Implementation notes: This isn't the most well-engineered fix in the
world; in particular, I didn't change the regex used to parse
WWW-Authenticate headers, in part because (A) such a regex was difficult
to compose and (B) it would've been quite difficult to read, and I
didn't want to inadvertently mess up the current behavior of the code.

----------
components: Library (Lib)
files: urllib2_single_quoted_auth_fix.patch
messages: 62513
nosy: varmaa
severity: minor
status: open
title: urllib2 basic auth handler doesn't handle realm names in single-quoted strings
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9455/urllib2_single_quoted_auth_fix.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2136>
__________________________________

From report at bugs.python.org  Mon Feb 18 03:51:41 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 18 Feb 2008 02:51:41 -0000
Subject: [issue1404925] subprocess.Popen inside thread locks the thread in
	some case (2.4)
Message-ID: <1203303101.27.0.306007680971.issue1404925@psf.upfronthosting.co.za>


Gregory P. Smith added the comment:

This appears to have been fixed in 2.5 and trunk.  2.4.x is old and in
security fixes only mode so I wouldn't expect to see this in any
official 2.4.x source tree released in the future unless the bdfl
changes his mind on that.  here's the patch to fix it (as described in
the email thread mentioned earlier):

Index: Lib/os.py
===================================================================
--- Lib/os.py   (revision 60877)
+++ Lib/os.py   (working copy)
@@ -351,8 +351,8 @@
 
 __all__.extend(["execl","execle","execlp","execlpe","execvp","execvpe"])
 
+import errno
 def _execvpe(file, args, env=None):
-    from errno import ENOENT, ENOTDIR
 
     if env is not None:
         func = execve
@@ -379,7 +379,7 @@
             func(fullname, *argrest)
         except error, e:
             tb = sys.exc_info()[2]
-            if (e.errno != ENOENT and e.errno != ENOTDIR
+            if (e.errno != errno.ENOENT and e.errno != errno.ENOTDIR
                 and saved_exc is None):
                 saved_exc = e
                 saved_tb = tb

----------
components: +Library (Lib) -Interpreter Core
keywords: +easy, patch
resolution:  -> wont fix
status: open -> closed
title: subprocess.Popen inside thread locks the thread in some case -> subprocess.Popen inside thread locks the thread in some case (2.4)
type:  -> behavior

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1404925>
_____________________________________

From report at bugs.python.org  Mon Feb 18 04:01:11 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 18 Feb 2008 03:01:11 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203292691.0.0.266930258143.issue2124@psf.upfronthosting.co.za>
Message-ID: <47B8F4F3.2030805@v.loewis.de>


Martin v. L?wis added the comment:

> In Python, a winning combo would be an arbitrary (and explicit) FS
> "dtdcache" that people could use with simple a drop-in import (from a
> third-party module?). 

It's indeed possible to provide that as a third-party module; one would
have to implement an EntityResolver, and applications would have to use
it. If there was a need for such a thing, somebody would have done it
years ago.

> It might be interesting to have read-only, force-write and read-write
> modes. 

Please take a look at catalogs - they are a read-only repository for
external entities (provided those entities have a public identifier,
which the W3C DTDs all have).

> Regarding the std-lib, I believe effective caching hooks for DTDs trump
> implementing in-memory or sqlite/FS. 

So then nothing needs to be done - the hooks have been in place since 
Python 2.0.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Mon Feb 18 04:45:06 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 18 Feb 2008 03:45:06 -0000
Subject: [issue1916] Add inspect.isgenerator
In-Reply-To: <1201084899.39.0.459999418984.issue1916@psf.upfronthosting.co.za>
Message-ID: <1203306306.27.0.0911152181064.issue1916@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Fixed in r60884. Thank you all very much!

----------
nosy: +facundobatista
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1916>
__________________________________

From report at bugs.python.org  Mon Feb 18 04:49:25 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 18 Feb 2008 03:49:25 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1203306565.31.0.152160190383.issue2051@psf.upfronthosting.co.za>


Changes by Facundo Batista:


----------
assignee:  -> facundobatista
nosy: +facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Mon Feb 18 04:55:06 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 18 Feb 2008 03:55:06 -0000
Subject: [issue1224] SimpleHTTPServer doesn't understand // at beginning of
	path anymore
In-Reply-To: <1191237626.38.0.0266691685704.issue1224@psf.upfronthosting.co.za>
Message-ID: <1203306906.1.0.0449151746224.issue1224@psf.upfronthosting.co.za>


Changes by Facundo Batista:


----------
assignee:  -> facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1224>
__________________________________

From report at bugs.python.org  Mon Feb 18 06:16:34 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 Feb 2008 05:16:34 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1203311794.1.0.575919231639.issue2065@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Mon Feb 18 06:17:07 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 Feb 2008 05:17:07 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1203311827.07.0.981757158091.issue2065@psf.upfronthosting.co.za>


Hirokazu Yamamoto added the comment:

Follow up r60882.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Mon Feb 18 06:18:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 18 Feb 2008 05:18:21 -0000
Subject: [issue2065] trunk version does not compile with vs8 and vc6
In-Reply-To: <1202727039.47.0.783651728329.issue2065@psf.upfronthosting.co.za>
Message-ID: <1203311902.0.0.840821300935.issue2065@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto:


Added file: http://bugs.python.org/file9456/ocean.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2065>
__________________________________

From report at bugs.python.org  Mon Feb 18 08:58:06 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 18 Feb 2008 07:58:06 -0000
Subject: [issue2014] xmlrpclib cannot send datetime objects with dates before
	1900
In-Reply-To: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>
Message-ID: <1203321486.96.0.372691776766.issue2014@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

http://bugs.python.org/issue1777412 describes the cause of this issue
(i.e. strftime not being able to handle years before 1900).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Mon Feb 18 09:43:11 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 18 Feb 2008 08:43:11 -0000
Subject: [issue2137] test_crasher in test_struct uses 8 GB memory on 64 bit
	systems
In-Reply-To: <1203324191.51.0.860214602248.issue2137@psf.upfronthosting.co.za>
Message-ID: <1203324191.51.0.860214602248.issue2137@psf.upfronthosting.co.za>


New submission from Ralf Schmitt:

I think this should be disabled on 64 bit systems. It makes running
regrtest.py for me basically impossible.
Martin, I've put you on the nosy list, as you have committed this one in
revision 60793.

----------
files: test_crasher_only_on_32bit.txt
messages: 62519
nosy: loewis, schmir
severity: normal
status: open
title: test_crasher in test_struct uses 8 GB memory on 64 bit systems
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9457/test_crasher_only_on_32bit.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2137>
__________________________________

From report at bugs.python.org  Mon Feb 18 09:43:43 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 18 Feb 2008 08:43:43 -0000
Subject: [issue2137] test_crasher in test_struct uses 8 GB memory on 64 bit
	systems
In-Reply-To: <1203324191.51.0.860214602248.issue2137@psf.upfronthosting.co.za>
Message-ID: <1203324223.42.0.79108999492.issue2137@psf.upfronthosting.co.za>


Changes by Ralf Schmitt:


----------
components: +Tests
type:  -> resource usage

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2137>
__________________________________

From report at bugs.python.org  Mon Feb 18 11:09:29 2008
From: report at bugs.python.org (David Albert Torpey)
Date: Mon, 18 Feb 2008 10:09:29 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>


New submission from David Albert Torpey:

Add a factorial method.  Everybody understands what it means before 
they are out of high school and it comes up all the time in statistics 
and combinatorics.  Ruby has a factorial method and heck even basic 
calculators have a factorial key.

print n.factorial()

Maybe raise ValueError if n is negative.

----------
components: Interpreter Core
messages: 62520
nosy: dtorp
severity: normal
status: open
title: Factorial
type: rfe
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 11:50:41 2008
From: report at bugs.python.org (carlo verr)
Date: Mon, 18 Feb 2008 10:50:41 -0000
Subject: [issue2139] sqlite3 module needs upgrading
In-Reply-To: <1203331840.91.0.13344654137.issue2139@psf.upfronthosting.co.za>
Message-ID: <1203331840.91.0.13344654137.issue2139@psf.upfronthosting.co.za>


New submission from carlo verr:

In Python 2.5.2.c1 the sqlite3 module contains (exactly as Python 2.5.1
does) PySQLite 2.3.2 with SQLite 3.3.4, which is very old and very
buggy, it hungs randomly.

Last available version of SQLite is 3.5.6. Last available version of
PySQLite for Python 2.5 is 2.4.1, which contains SQLite 3.5.2.

----------
components: Library (Lib)
messages: 62521
nosy: carloverre
severity: normal
status: open
title: sqlite3 module needs upgrading
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2139>
__________________________________

From report at bugs.python.org  Mon Feb 18 12:44:03 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 18 Feb 2008 11:44:03 -0000
Subject: [issue1742669] "%d" format handling for long values
Message-ID: <1203335043.37.0.192468488423.issue1742669@psf.upfronthosting.co.za>


Gabriel Genellina added the comment:

An updated patch, along the lines given by Travis Oliphant.

Added file: http://bugs.python.org/file9458/floatfmt.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1742669>
_____________________________________

From report at bugs.python.org  Mon Feb 18 12:59:08 2008
From: report at bugs.python.org (Gabriel Genellina)
Date: Mon, 18 Feb 2008 11:59:08 -0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1203335948.21.0.0283012462939.issue1518@psf.upfronthosting.co.za>


Changes by Gabriel Genellina:


----------
nosy: +gagenellina

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
__________________________________

From report at bugs.python.org  Mon Feb 18 13:18:06 2008
From: report at bugs.python.org (Markus Stoll)
Date: Mon, 18 Feb 2008 12:18:06 -0000
Subject: [issue2140] calculation bug in long() function
Message-ID: <1203337086.17.0.763664362769.issue2140@psf.upfronthosting.co.za>


Changes by Markus Stoll:


----------
components: None
nosy: must21
severity: normal
status: open
title: calculation bug in long() function
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2140>
__________________________________

From report at bugs.python.org  Mon Feb 18 13:18:19 2008
From: report at bugs.python.org (Markus Stoll)
Date: Mon, 18 Feb 2008 12:18:19 -0000
Subject: [issue2140] calculation bug in long() function
In-Reply-To: <1203337098.92.0.676408985759.issue2140@psf.upfronthosting.co.za>
Message-ID: <1203337098.92.0.676408985759.issue2140@psf.upfronthosting.co.za>


New submission from Markus Stoll:

betrag = 146.95
betrag = float(betrag)
betrag = betrag * 100.0
betrag = long(betrag)
print betrag

gives 14694 as result rather than 14695

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2140>
__________________________________

From report at bugs.python.org  Mon Feb 18 13:25:05 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 18 Feb 2008 12:25:05 -0000
Subject: [issue2140] calculation bug in long() function
In-Reply-To: <1203337098.92.0.676408985759.issue2140@psf.upfronthosting.co.za>
Message-ID: <1203337505.25.0.356653576709.issue2140@psf.upfronthosting.co.za>


Facundo Batista added the comment:

In short: 

>>> long(100 * 146.95)
14694L

This is NOT a bug, but a behaviour of binary floating point:

>>> 146.95
146.94999999999999

In binary you can not express this number exactly.

>>> 146.95 * 100
14694.999999999998

When you long() that, you truncate the number, so it goes to 14694.

Please address further discussion through python-list.

Thanks!

----------
nosy: +facundobatista
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2140>
__________________________________

From report at bugs.python.org  Mon Feb 18 13:49:24 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 18 Feb 2008 12:49:24 -0000
Subject: [issue1224] SimpleHTTPServer doesn't understand // at beginning of
	path anymore
In-Reply-To: <1191237626.38.0.0266691685704.issue1224@psf.upfronthosting.co.za>
Message-ID: <1203338964.09.0.941274380175.issue1224@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Fixed in r60885. Thanks everybody!

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1224>
__________________________________

From report at bugs.python.org  Mon Feb 18 13:55:37 2008
From: report at bugs.python.org (Markus Stoll)
Date: Mon, 18 Feb 2008 12:55:37 -0000
Subject: [issue2140] calculation bug in long() function
In-Reply-To: <1203337505.25.0.356653576709.issue2140@psf.upfronthosting.co.za>
Message-ID: <08FB341A-E1A5-4EDA-90B2-215C4F192F22@mstoll.de>


Markus Stoll added the comment:

thank you for fast reply

I see the point and do not want to argue about that (rounding is fine  
for me). I just think this behaviour makes the long() function pretty  
much useless.

Regards, Markus
Am 18.02.2008 um 13:25 schrieb Facundo Batista:

>
> Facundo Batista added the comment:
>
> In short:
>
>>>> long(100 * 146.95)
> 14694L
>
> This is NOT a bug, but a behaviour of binary floating point:
>
>>>> 146.95
> 146.94999999999999
>
> In binary you can not express this number exactly.
>
>>>> 146.95 * 100
> 14694.999999999998
>
> When you long() that, you truncate the number, so it goes to 14694.
>
> Please address further discussion through python-list.
>
> Thanks!
>
> ----------
> nosy: +facundobatista
> resolution:  -> invalid
> status: open -> closed
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2140>
> __________________________________

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2140>
__________________________________

From report at bugs.python.org  Mon Feb 18 14:22:50 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 18 Feb 2008 13:22:50 -0000
Subject: [issue2134] function generate_tokens at tokenize.py yields wrong
	token for colon
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1203340970.52.0.894500032213.issue2134@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

I'm attaching a patch that solves this and updates tests.

Added file: http://bugs.python.org/file9459/tokenize_r60884.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
__________________________________

From report at bugs.python.org  Mon Feb 18 14:52:18 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Feb 2008 13:52:18 -0000
Subject: [issue1739842] xmlrpclib can no longer marshal Fault objects
Message-ID: <1203342738.59.0.561224005174.issue1739842@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

It looks like this was fixed in the trunk by rev 52790. Can someone
check it is indeed the case?

----------
nosy: +loewis, pitrou

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739842>
_____________________________________

From report at bugs.python.org  Mon Feb 18 15:15:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Feb 2008 14:15:06 -0000
Subject: [issue1739842] xmlrpclib can no longer marshal Fault objects
Message-ID: <1203344106.32.0.486901509697.issue1739842@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Seems fixed indeed. Tested the following script:

import xmlrpclib
e = xmlrpclib.Fault("Error", "Message")
((d,), _) = xmlrpclib.loads(xmlrpclib.dumps((e,)))
assert d['faultString'] == "Message"

which works with python2.4, fails with python2.5, and works again with
python 2.6a0.

Now, this is a bug in 2.5, but the fix can be considered as a new
feature. I don't know if we should backport this.

----------
nosy: +amaury.forgeotdarc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739842>
_____________________________________

From report at bugs.python.org  Mon Feb 18 15:18:55 2008
From: report at bugs.python.org (moreilcon)
Date: Mon, 18 Feb 2008 14:18:55 -0000
Subject: [issue2141] Pydoc interactive browser misses some docs
In-Reply-To: <1203344335.25.0.229282723234.issue2141@psf.upfronthosting.co.za>
Message-ID: <1203344335.25.0.229282723234.issue2141@psf.upfronthosting.co.za>


New submission from moreilcon:

#no mention about formatdate at all:
% pydoc rfc822 | grep formatdate | wc -l
0
# but rfc822.formatdate docstring exists:
% pydoc rfc822.formatdate | wc -l
12
# also same behavior :
% pydoc codecs | getwriter | wc -l
0

Reproduced at:
Python 2.5.1 (r251:54863, Jan 17 2008, 09:20:17) 
[GCC 4.1.2 (Gentoo 4.1.2 p1.0.2)] on linux2

Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2

Python 2.5.1 (r251:54863, Feb 18 2008, 13:35:09)
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7

----------
components: Library (Lib)
messages: 62530
nosy: moreilcon
severity: normal
status: open
title: Pydoc interactive browser misses some docs
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2141>
__________________________________

From report at bugs.python.org  Mon Feb 18 15:37:51 2008
From: report at bugs.python.org (Mike Bonnet)
Date: Mon, 18 Feb 2008 14:37:51 -0000
Subject: [issue1739842] xmlrpclib can no longer marshal Fault objects
Message-ID: <1203345471.06.0.835077901501.issue1739842@psf.upfronthosting.co.za>


Mike Bonnet added the comment:

How can this be considered a new feature?  Code that worked under
python2.4 fails under python2.5 as a result of this bug.  That is
clearly a regression.  I think that qualifies it for a backport to
python2.5.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739842>
_____________________________________

From report at bugs.python.org  Mon Feb 18 16:10:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Feb 2008 15:10:39 -0000
Subject: [issue1739842] xmlrpclib can no longer marshal Fault objects
Message-ID: <1203347439.74.0.551910181188.issue1739842@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

description for rev 52790 is:
"""
Patch #1070046: Marshal new-style objects like InstanceType in xmlrpclib.
"""

This _change_ is a new feature. OTOH it corrects a real regression.
Other thoughts?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739842>
_____________________________________

From report at bugs.python.org  Mon Feb 18 16:21:29 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 18 Feb 2008 15:21:29 -0000
Subject: [issue1739842] xmlrpclib can no longer marshal Fault objects
Message-ID: <1203348089.76.0.89830137457.issue1739842@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Perhaps the backported version should only care about instances of the
Fault class?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739842>
_____________________________________

From report at bugs.python.org  Mon Feb 18 16:43:48 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Mon, 18 Feb 2008 15:43:48 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203349428.53.0.810579641877.issue2138@psf.upfronthosting.co.za>


Alan McIntyre added the comment:

It seems like most of the methods on integers are for two-argument
operations (add, mul, div, etc.), while a lot of single-argument
operations are in the math module.  If this gets added would it fit
better as a function in the math module?

I have to say a factorial function is something I've found myself
writing several times, so I certainly wouldn't mind having one included.
Yeah, it's a one-liner, but so is hypot, and that's already in the
stdlib.  And most calculators don't have a hypot button. ;)

----------
nosy: +alanmcintyre

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 16:46:10 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Feb 2008 15:46:10 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203349570.46.0.944526517039.issue2138@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I don't think it would be appropriate to add this as a method of int; 
it seems like unnecessary clutter on a core type.

Perhaps a math.factorial function could be considered?  Historically,
the math module has just been a way to wrap the (mostly floating-point)
libm functions, but I think that may be changing:  there's at least some
interest in putting gcd into the math module, for example.

David, any chance you could come up with a patch implementing
math.factorial?

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 16:48:31 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Feb 2008 15:48:31 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203349711.01.0.556310850682.issue2138@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Yeah, it's a one-liner, but so is hypot

Except that hypot is not a one-liner, if you want to get edge cases
right.  (Consider hypot(1e200, 1e200), or hypot(1e-200, 1e-200).)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 17:05:09 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 18 Feb 2008 16:05:09 -0000
Subject: [issue1739842] xmlrpclib can no longer marshal Fault objects
Message-ID: <1203350709.79.0.18859370166.issue1739842@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

Trying to understand the real problem:
Exceptions are not correctly marshalled by xmlrpclib, even with 2.6.

Take a standard exception, and process it:
    e = KeyError("message")
    ((d,), _) = xmlrpclib.loads(xmlrpclib.dumps((e,)))
With python2.4: you get
    {'args': ['message']}
With python2.6: you get
    {}
because 'args' is no more in the Exception's __dict__ anymore (another
regression??)

So to be compatible with 2.4, the correction would be to marshal
BaseException (and subclasses) by dumping its __dict__ augmented with
the "args" member:
    d = value.__dict__.copy()
    d['args'] = value.args
    self.dump_struct(d, write)
Since this code would only concern exception objects which always raise
an error in 2.5, it would not break existing code.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739842>
_____________________________________

From report at bugs.python.org  Mon Feb 18 18:48:19 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 18 Feb 2008 17:48:19 -0000
Subject: [issue2137] test_crasher in test_struct uses 8 GB memory on 64 bit
	systems
In-Reply-To: <1203324191.51.0.860214602248.issue2137@psf.upfronthosting.co.za>
Message-ID: <1203356899.03.0.499086724383.issue2137@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks for the report. I have removed the test in r60892.

Not sure why you've marked it as Py2.6 also; this code has not been
merged into the trunk yet.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2137>
__________________________________

From report at bugs.python.org  Mon Feb 18 18:50:52 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Mon, 18 Feb 2008 17:50:52 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203357052.04.0.0404879270189.issue2138@psf.upfronthosting.co.za>


Alan McIntyre added the comment:

>Except that hypot is not a one-liner, if you want to get edge cases
right. 

Ah, true; thanks for pointing that out.

Should there be some upper limit on the argument math.factorial would
take?  At the moment I can't think of any reason for picking a given
limit, except perhaps execution time.  (10**4)! can be done in about 1
second on my old & slow laptop; are there realistic use cases for
numbers much bigger than that?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 18:57:32 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 18 Feb 2008 17:57:32 -0000
Subject: [issue2139] sqlite3 module needs upgrading
In-Reply-To: <1203331840.91.0.13344654137.issue2139@psf.upfronthosting.co.za>
Message-ID: <1203357452.33.0.327158866951.issue2139@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Such bugs should have been reported here much earlier. Blind upgrading
to the latest version is no option, as the latest version may also
introduce new features, which is unacceptable for a bugfix release.
Specific bugs could have been fixed, but really not now as the release
candidate is already made (unless that release candidate would have
shown serious regressions over 2.5.1, which I understand is not the case
here).

Gerhard, what do you think about backporting some fixes to 2.5.3?
(assuming it really is the case that PySQLite 2.3.2 really is very buggy)

----------
assignee:  -> ghaering
nosy: +ghaering, loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2139>
__________________________________

From report at bugs.python.org  Mon Feb 18 19:12:20 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Feb 2008 18:12:20 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203358340.36.0.641304066449.issue2138@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Should there be some upper limit on the argument math.factorial would
take?

I'd say not.  Any such limit would be artificial, and an arbitrary
choice.  Just let the natural time and space requirements be the
limiting factor.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 20:44:42 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Feb 2008 19:44:42 -0000
Subject: [issue1600] str.format() produces different output on different
	platforms (Py30a2)
In-Reply-To: <1197450243.14.0.729685827203.issue1600@psf.upfronthosting.co.za>
Message-ID: <1203363882.91.0.165779734812.issue1600@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I know I'm coming a bit late to this discussion, but I wanted to point
out that the C99 standard does actually specify how many digits should
be in the exponent of a "%e"-formatted number:

In section 7.19.6, in the documentation for fprintf, it says:

"The exponent always contains at least two digits, and only as many more
digits as necessary to represent the exponent."

Not that that's necessarily a reason for Python to do the same :)

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Mon Feb 18 21:16:57 2008
From: report at bugs.python.org (Trent Mick)
Date: Mon, 18 Feb 2008 20:16:57 -0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>


New submission from Trent Mick:

When comparing content with difflib, if the resulting diff covers the
last line of one or both of the inputs that that line doesn't end with
an end-of-line character(s), then the generated diff lines don't include
an EOL. Fair enough.

Naive (and I suspect typical) usage of difflib.unified_diff(...) is:

  diff = ''.join(difflib.unified_diff(...))

This results in an *incorrect* unified diff for the conditions described
above.

>>> from difflib import *
>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
...                    "one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
 one
 two
-three+trois


The proper behaviour would be:

>>> gen = unified_diff("one\ntwo\nthree".splitlines(1),
...                    "one\ntwo\ntrois".splitlines(1))
>>> print ''.join(gen)
---
+++
@@ -1,3 +1,3 @@
 one
 two
-three
\ No newline at end of file
+trois
\ No newline at end of file


I *believe* that "\ No newline at end of file" are the appropriate
markers -- that tools like "patch" will know how to use. At least this
is what "svn diff" generates.


I'll try to whip up a patch. 

Do others concur that this should be fixed?

----------
components: Library (Lib)
messages: 62543
nosy: trentm
severity: normal
status: open
title: naive use of ''.join(difflib.unified_diff(...)) results in bogus diffs with inputs that don't end with end-of-line char
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
__________________________________

From report at bugs.python.org  Mon Feb 18 21:24:10 2008
From: report at bugs.python.org (Trent Mick)
Date: Mon, 18 Feb 2008 20:24:10 -0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1203366250.03.0.811530152171.issue2142@psf.upfronthosting.co.za>


Trent Mick added the comment:

Attached is a patch against the Python 2.6 svn trunk for this.

----------
versions: +Python 2.3, Python 2.4, Python 2.6
Added file: http://bugs.python.org/file9460/python_difflib_unified_diff.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
__________________________________

From report at bugs.python.org  Mon Feb 18 21:25:23 2008
From: report at bugs.python.org (Trent Mick)
Date: Mon, 18 Feb 2008 20:25:23 -0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1203366323.32.0.371354259425.issue2142@psf.upfronthosting.co.za>


Trent Mick added the comment:

At a glance I suspect this patch will work back to Python 2.3 (when
difflib.unified_diff() was added). I haven't looked at the Py3k tree yet.


Note: This *may* also applied to difflib.context_diff(), but I am not sure.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
__________________________________

From report at bugs.python.org  Mon Feb 18 22:17:16 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Mon, 18 Feb 2008 21:17:16 -0000
Subject: [issue1856] shutdown (exit) can hang or segfault with daemon threads
	running
In-Reply-To: <1200535276.53.0.276618350299.issue1856@psf.upfronthosting.co.za>
Message-ID: <1203369436.45.0.107230456504.issue1856@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser:


----------
nosy: +kbk

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
__________________________________

From report at bugs.python.org  Mon Feb 18 23:07:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 18 Feb 2008 22:07:45 -0000
Subject: [issue2137] test_crasher in test_struct uses 8 GB memory on 64 bit
	systems
In-Reply-To: <1203324191.51.0.860214602248.issue2137@psf.upfronthosting.co.za>
Message-ID: <1203372465.45.0.566954240911.issue2137@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

I didn't check the trunk version - I just assumed it would also be there.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2137>
__________________________________

From report at bugs.python.org  Mon Feb 18 23:15:43 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Feb 2008 22:15:43 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203372943.51.0.326782173923.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Two things:

(1) Speedup.  I haven't been helping much here;  apologies.  Christian 
suggested that a C implementation of gcd might help.  Is this true, or 
are we not yet at the stage where the gcd calls are significant?  There 
are some basic tricks that can speed up the usual Euclidean algorithm by 
a constant factor, and I'll try to implement them if that's of interest 
(unless Christian beats me to it). There also some serious super-fast 
recursive gcd algorithms, with running time O(n**(1+epsilon)) for a pair 
of n-bit integers, but those are complicated and probably best left to 
GMP.

(2) PEP 3101:  Should Fraction get a __format__ method?  I'm looking at 
implementing Decimal.__format__, and I think there's quite likely to be 
a fair amount of common code (e.g. for parsing the format specifier) 
between Decimal.__format__ and Fraction.__format__, so it would probably 
make sense for me to do both of these at once.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Mon Feb 18 23:33:02 2008
From: report at bugs.python.org (Eric Smith)
Date: Mon, 18 Feb 2008 22:33:02 -0000
Subject: [issue1600] str.format() produces different output on different
	platforms (Py30a2)
In-Reply-To: <1197450243.14.0.729685827203.issue1600@psf.upfronthosting.co.za>
Message-ID: <1203373982.06.0.349645996271.issue1600@psf.upfronthosting.co.za>


Eric Smith added the comment:

Given Mark Dickinson's input, I think we should follow it.  That
effectively means leaving the Linux/MacOS input as is, and modifying the
Windows output.  I'll work up a patch, but I'd still like to get some
input on changing the output of existing, working code.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Mon Feb 18 23:40:59 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Feb 2008 22:40:59 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203374459.27.0.317433344281.issue2138@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Since the domain and range are ints/longs, this makes more sense as a 
method on <type 'int'> than as a math module function.  The other math 
module functions mostly have real valued inputs and mostly have 
counterparts in cmath.  

IIRC, Tim wanted the math module to maintain that theme and not become 
a home to every function that seems a bit "mathematical". I share the 
sentiment -- it would be nice for the math module to retain its unified 
theme during its growth spurt.

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Mon Feb 18 23:51:06 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 18 Feb 2008 22:51:06 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203375066.09.0.564373913782.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

1) No worries. Even without inlining the common case of __add__, etc.,
Fraction is now faster than Decimal for smallish fractions
[sum(Fraction(1, i) for i in range(1, 100))], and for large ones
[sum(Fraction(1, i) for i in range(1, 1000))] gcd takes so much of the
time that I can't see the effects of any of the optimizations I've made.
Since I wasn't thinking of this as a high-performance class, I'm taking
that as a sign to stop optimizing, but gcd is definitely the function to
tackle if anyone wants to keep going.

2) I haven't been following __format__, but adding it to Rational sounds
fine to me.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Mon Feb 18 23:55:27 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Feb 2008 22:55:27 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203375327.46.0.685106461105.issue2138@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Since the domain and range are ints/longs, this makes more sense as a 
> method on <type 'int'> than as a math module function.

Fair enough.  Raymond, do you have any thoughts on where a gcd 
implementation might most usefully live?  Should it stay in 
fractions.py, or is there a case for moving it somewhere more central?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Tue Feb 19 00:04:31 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 18 Feb 2008 23:04:31 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203375871.22.0.739291437006.issue2138@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

gcd() is probably fine where it is.  People learn about GCD and LCM 
where they first learn fractions.  So, there is a strong association.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Tue Feb 19 00:05:53 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 18 Feb 2008 23:05:53 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203375953.76.0.155757694473.issue2138@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The other issue here is that I see factorial as being the thin end of 
the 
wedge.  If factorial were implemented, it would probably only be on the 
order of minutes before people wanted to know where the binomial() 
function was.

So it seems to me that either there should be a good single place for 
all 
integer-related math, (gcd, xgcd, binomial, factorial, ...) or we should 
leave this for third-party modules for the moment.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Tue Feb 19 02:37:15 2008
From: report at bugs.python.org (John Lenton)
Date: Tue, 19 Feb 2008 01:37:15 -0000
Subject: [issue1945] Document back ported C functions
In-Reply-To: <1201445858.91.0.21119487494.issue1945@psf.upfronthosting.co.za>
Message-ID: <1203385034.99.0.890271970697.issue1945@psf.upfronthosting.co.za>


John Lenton added the comment:

This is the same as the previous patch, but I added the "versionadded"
notation in the rst, and the info in refcounts.dat to get the "return
value" info in the docs.

Added file: http://bugs.python.org/file9461/1945-2.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1945>
__________________________________

From report at bugs.python.org  Tue Feb 19 03:39:08 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 19 Feb 2008 02:39:08 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203388748.76.0.0949998504356.issue2138@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I wouldn't worry about that so much -- our job is to provide good 
primitives.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Tue Feb 19 08:58:48 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 19 Feb 2008 07:58:48 -0000
Subject: [issue1600] str.format() produces different output on different
	platforms (Py30a2)
In-Reply-To: <1203363882.91.0.165779734812.issue1600@psf.upfronthosting.co.za>
Message-ID: <200802190755.56323.mark@qtrac.eu>


Mark Summerfield added the comment:

On 2008-02-18, Mark Dickinson wrote:
> Mark Dickinson added the comment:
>
> I know I'm coming a bit late to this discussion, but I wanted to point
> out that the C99 standard does actually specify how many digits should
> be in the exponent of a "%e"-formatted number:
>
> In section 7.19.6, in the documentation for fprintf, it says:
>
> "The exponent always contains at least two digits, and only as many more
> digits as necessary to represent the exponent."
>
> Not that that's necessarily a reason for Python to do the same :)

I don't really see why Python shouldn't use as few digits as are needed:-)

The patch I submitted just made the exponent at least three digits.

But my aim was cross-platform consistency, and I still think (whether
using the fewest digits, the fewest but at least 2, or whatever other
logic) that the same logic should be used on all platforms since this
makes it easier to test cross-platform applications that output numbers
in exponential form.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Tue Feb 19 09:28:10 2008
From: report at bugs.python.org (David Albert Torpey)
Date: Tue, 19 Feb 2008 08:28:10 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203409690.92.0.503127845081.issue2138@psf.upfronthosting.co.za>


David Albert Torpey added the comment:

Mr. Dickinson thank you for doing this.  I do not know how to help with 
a patch.  If it helps, here is the code I use in python:

def factorial(n, _known=[1]):
    assert isinstance(n, int), "Need an integer. This isn't a gamma"
    assert n >= 0, "Sorry, can't factorilize a negative"
    assert n < 1000, "No way! That's too large"
    try:
        return _known[n]
    except IndexError:
        pass
    for i in range(len(_known), n+1):
        _known.append(_known[-1] * i)
    return _known[n]

When the assertions are turned-off, this runs pretty fast.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Tue Feb 19 10:07:41 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2008 09:07:41 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203412061.31.0.66424416622.issue2135@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> brett.cannon
keywords: +patch
nosy: +brett.cannon, tiran
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Tue Feb 19 10:08:15 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2008 09:08:15 -0000
Subject: [issue2134] function generate_tokens at tokenize.py yields wrong
	token for colon
In-Reply-To: <1203289230.78.0.790200923315.issue2134@psf.upfronthosting.co.za>
Message-ID: <1203412095.23.0.771027241965.issue2134@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2134>
__________________________________

From report at bugs.python.org  Tue Feb 19 10:09:53 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2008 09:09:53 -0000
Subject: [issue2142] naive use of ''.join(difflib.unified_diff(...)) results
	in bogus diffs with inputs that don't end with end-of-line char
In-Reply-To: <1203365817.7.0.0998491412302.issue2142@psf.upfronthosting.co.za>
Message-ID: <1203412193.42.0.401173014012.issue2142@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2142>
__________________________________

From report at bugs.python.org  Tue Feb 19 10:32:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 19 Feb 2008 09:32:20 -0000
Subject: [issue708007] TelnetPopen3, TelnetBase, Expect split
Message-ID: <1203413540.83.0.610787060729.issue708007@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
status: pending -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue708007>
____________________________________

From report at bugs.python.org  Tue Feb 19 12:53:48 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 19 Feb 2008 11:53:48 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1203422027.99.0.142636023279.issue2127@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

+1 I've been pulling my hair off over this one too. Try this on win32:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.mkdir(u'foo\xe9')
>>> import sqlite3
>>> con = sqlite3.connect(u'foo\xe9\\my.db')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in position 3:
ordinal not in range(128)
>>> import sys
>>> sys.getfilesystemencoding()
'mbcs'
>>> con = sqlite3.connect(u'foo\xe9\\my.db'.encode(sys.getfilesystemencoding()))

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
sqlite3.OperationalError: unable to open database file
>>> con = sqlite3.connect(u'foo\xe9\\my.db'.encode('utf-8'))
>>>

----------
nosy: +vdupras

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Tue Feb 19 13:55:53 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 19 Feb 2008 12:55:53 -0000
Subject: [issue1149798] hotshot.runctx: builtins missing
Message-ID: <1203425753.11.0.972429590235.issue1149798@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

Python 2.5.1 (r251:54869, Apr 18 2007, 22:08:04) 
[GCC 4.0.1 (Apple Computer, Inc. build 5367)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hotshot
>>> hotshot.Profile('/tmp/hs').runctx('print len',{'__builtins__':
... __builtins__},{})
<built-in function len>
<hotshot.Profile instance at 0x6a940>
>>> 

Can we close this now?

----------
nosy: +vdupras

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1149798>
_____________________________________

From report at bugs.python.org  Tue Feb 19 13:57:01 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 19 Feb 2008 12:57:01 -0000
Subject: [issue1149798] hotshot.runctx: builtins missing
Message-ID: <1203425821.83.0.143218929752.issue1149798@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

oh crap here goes my ego... pasted the wrong line.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1149798>
_____________________________________

From report at bugs.python.org  Tue Feb 19 14:08:16 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Tue, 19 Feb 2008 13:08:16 -0000
Subject: [issue2139] sqlite3 module needs upgrading
In-Reply-To: <1203331840.91.0.13344654137.issue2139@psf.upfronthosting.co.za>
Message-ID: <1203426496.92.0.210668722969.issue2139@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

I don't think pysqlite 2.3.2 is very buggy. Otherwise a lot more bug
reports about the pysqlite module would have arrived here. About
backporting fixes to 2.5.3, I'd have to look which ones are isolated and
I could then backport them.

As for SQLite, I'm always for just using the latest DLL and ship it with
Windows. But IMO now we should just ship whatever is in the release
candidate right now.

If the SQLite DLL proves to be a problem, users can always just install
their custom one over the one shipped with Python.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2139>
__________________________________

From report at bugs.python.org  Tue Feb 19 14:58:21 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Tue, 19 Feb 2008 13:58:21 -0000
Subject: [issue1149798] hotshot.runctx: builtins missing
Message-ID: <1203429501.56.0.888013880568.issue1149798@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

Well, since I brought that issue back, I might as well supply a patch. So 
if indeed it is decided that hotshot.Profile.runctx() should have 
__builtins__ in its globals by default, here is it.

Added file: http://bugs.python.org/file9462/hotshot_builtins_globals.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1149798>
_____________________________________

From report at bugs.python.org  Tue Feb 19 16:30:37 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 19 Feb 2008 15:30:37 -0000
Subject: [issue2114] test_decimal failure on OSX 10.3
In-Reply-To: <1203005848.03.0.149497232704.issue2114@psf.upfronthosting.co.za>
Message-ID: <1203435037.76.0.681775572102.issue2114@psf.upfronthosting.co.za>


Ronald Oussoren added the comment:

I've applied the workaround in revision 60903 (after testing that it 
actually works).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2114>
__________________________________

From report at bugs.python.org  Tue Feb 19 17:38:22 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Feb 2008 16:38:22 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1203375066.09.0.564373913782.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802190838s5f0eacd3u207fab25ba1a7238@mail.gmail.com>


Guido van Rossum added the comment:

A C reimplementation of gcd probably makes little sense -- for large
numbers it is dominated by the cost of the arithmetic, and that will
remain the same.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 19 17:46:29 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Feb 2008 16:46:29 -0000
Subject: [issue1600] str.format() produces different output on different
	platforms (Py30a2)
In-Reply-To: <200802190755.56323.mark@qtrac.eu>
Message-ID: <ca471dc20802190836u76179b03lcf3ff4849fc1bc9b@mail.gmail.com>


Guido van Rossum added the comment:

I would like Python to follow the C99 rule here. It is practical and
Python has a long tradition of following C where it makes sense.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Tue Feb 19 18:03:30 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Feb 2008 17:03:30 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203440610.93.0.334609785991.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> A C reimplementation of gcd probably makes little sense -- for large
> numbers it is dominated by the cost of the arithmetic, and that will
> remain the same.

That's true for a direct translation of the usual algorithm.   But 
there's a variant due to Lehmer which reduces the number of multi-
precision operations, and dramatically reduces the number of full-
precision divmod operations---they're mostly replaced by n-limb-by-1-
limb multiplications and full-precision additions.  I'd expect at least 
a factor of 2 speedup from using this;  possibly more.  Of course it's 
impossible to tell without implementing it.

I've attached a Python version;  note that:

 * the operations to find x and y at the start of the outer while loop 
are simple lookups when written in C
 * the else branch is taken rarely:  usually once at the beginning of 
any gcd() calculation, and then less than 1 time in 20000 on average 
during the reduction.
 * all the arithmetic in the inner while loop is done with numbers <= 
2**15 in absolute value.

Mark

Added file: http://bugs.python.org/file9463/lehmer_gcd.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 19 18:20:01 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 19 Feb 2008 17:20:01 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1203440610.93.0.334609785991.issue1682@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802190919v388dec69ja71e86afd5cd5aa9@mail.gmail.com>


Guido van Rossum added the comment:

I think this is definitely premature optimization. :-)

In any case, before going any further, you should design a benchmark
and defend it.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 19 20:25:51 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Feb 2008 19:25:51 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203449151.68.0.00571301383296.issue1682@psf.upfronthosting.co.za>


Changes by Mark Dickinson:


Removed file: http://bugs.python.org/file9463/lehmer_gcd.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 19 20:31:26 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 19 Feb 2008 19:31:26 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203449486.81.0.173271196602.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Replacing lehmer_gcd.py with a revised version.  Even in Python, this 
version is faster than the current one, on my machine, once both numbers 
are greater than 10**650 or so (your crossover points may vary).  It's 
over four times faster for very large inputs (over 10**20000).

> In any case, before going any further, you should design a benchmark
> and defend it.

Okay.  I'll stop now :)

Added file: http://bugs.python.org/file9464/lehmer_gcd.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Tue Feb 19 20:53:04 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Tue, 19 Feb 2008 19:53:04 -0000
Subject: [issue2143] smtplib.SSLFakeFile hangs forever if "\n" is not
	encountered
In-Reply-To: <1203450784.48.0.914624365549.issue2143@psf.upfronthosting.co.za>
Message-ID: <1203450784.48.0.914624365549.issue2143@psf.upfronthosting.co.za>


New submission from Giampaolo Rodola':

By looking through the smtplib module code I think I've found a
potential issue in the SSLFakeFile class code since there's a while loop
which is supposed to be stopped only when the "\n" character is encountered:

        def readline(self):
            str = ""
            chr = None
            while chr != "\n":
                chr = self.sslobj.read(1)
                str += chr
            return str


The patch in attachment just adds a break statement to prevent the while
loop to hang forever in case the "\n" character is never encountered.

----------
components: Library (Lib)
files: smptlib.diff
messages: 62569
nosy: facundobatista, giampaolo.rodola, gregory.p.smith
severity: normal
status: open
title: smtplib.SSLFakeFile hangs forever if "\n" is not encountered
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9465/smptlib.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2143>
__________________________________

From report at bugs.python.org  Tue Feb 19 22:52:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 19 Feb 2008 21:52:42 -0000
Subject: [issue2139] sqlite3 module needs upgrading
In-Reply-To: <1203331840.91.0.13344654137.issue2139@psf.upfronthosting.co.za>
Message-ID: <1203457962.72.0.586254701287.issue2139@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thanks; closing this report as "won't fix", then.

----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2139>
__________________________________

From report at bugs.python.org  Tue Feb 19 22:56:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Feb 2008 21:56:52 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

This patch changes os.environ to inherit builtin dict rather than UserDict.

----------
files: environ-modern.diff
messages: 62571
nosy: gutworth
severity: normal
status: open
title: os.environ should inherit dict
type: rfe
versions: Python 2.6
Added file: http://bugs.python.org/file9466/environ-modern.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Tue Feb 19 23:11:35 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 19 Feb 2008 22:11:35 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203459095.62.0.115052926863.issue2144@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

What's the rationale for this change?

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Tue Feb 19 23:37:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 19 Feb 2008 22:37:23 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203460643.87.0.260122751488.issue2144@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

PEP 390. It's cleaner and faster.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Wed Feb 20 00:14:13 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:14:13 -0000
Subject: [issue449227] rlcompleter add "(" to callables feature
Message-ID: <1203462853.94.0.144455075629.issue449227@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +patch

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue449227>
____________________________________

From report at bugs.python.org  Wed Feb 20 00:14:59 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:14:59 -0000
Subject: [issue449227] rlcompleter add "(" to callables feature
Message-ID: <1203462899.12.0.541198641029.issue449227@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +easy

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue449227>
____________________________________

From report at bugs.python.org  Wed Feb 20 00:19:53 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:19:53 -0000
Subject: [issue602291] Bgen should learn about booleans
Message-ID: <1203463193.62.0.410346977425.issue602291@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
type:  -> rfe

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue602291>
____________________________________

From report at bugs.python.org  Wed Feb 20 00:26:01 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:26:01 -0000
Subject: [issue849097] Request: getpos() for sgmllib
Message-ID: <1203463561.13.0.33192805955.issue849097@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +patch
type:  -> rfe

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue849097>
____________________________________

From report at bugs.python.org  Wed Feb 20 00:30:32 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:30:32 -0000
Subject: [issue971330] test_signal sucks
Message-ID: <1203463832.76.0.468343177104.issue971330@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

In Python 2.6, test_signal.py uses unittest.  It still spawns a shell
script, but I don't understand why this is a problem; is it a
portability issue?

----------
nosy: +akuchling

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue971330>
____________________________________

From report at bugs.python.org  Wed Feb 20 00:34:28 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:34:28 -0000
Subject: [issue1038909] pydoc method documentation lookup enhancement
Message-ID: <1203464068.8.0.250619468192.issue1038909@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +easy

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1038909>
_____________________________________

From report at bugs.python.org  Wed Feb 20 00:34:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:34:45 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203464085.46.0.595182894001.issue1040026@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +easy

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Wed Feb 20 00:37:50 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:37:50 -0000
Subject: [issue1044479] docs for Py_UNICODE are wrong
Message-ID: <1203464270.32.0.829239480788.issue1044479@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +easy

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1044479>
_____________________________________

From report at bugs.python.org  Wed Feb 20 00:38:59 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:38:59 -0000
Subject: [issue1081824] Rewrite of docs for compiler.visitor
Message-ID: <1203464339.19.0.514550484127.issue1081824@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1081824>
_____________________________________

From report at bugs.python.org  Wed Feb 20 00:45:58 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:45:58 -0000
Subject: [issue1106262] semaphore errors from Python 2.3.x on AIX 5.2
Message-ID: <1203464758.66.0.874375036137.issue1106262@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Fixed for bug #1234.

----------
nosy: +akuchling
resolution:  -> duplicate
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1106262>
_____________________________________

From report at bugs.python.org  Wed Feb 20 00:53:27 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 19 Feb 2008 23:53:27 -0000
Subject: [issue1167397] Python 2.4 causes BitTorrent 3.4.2 failure
Message-ID: <1203465207.16.0.695781240235.issue1167397@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The Red Hat bug URL is now
https://bugzilla.redhat.com/show_bug.cgi?id=138535 ; it has a lengthy
discussion.

>From that bug's history, the problem now seems to be fixed, though I'm
not sure if it was fixed on the Python or the yum/BitTorrent side. 
Closing this bug, anyway.

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1167397>
_____________________________________

From report at bugs.python.org  Wed Feb 20 01:01:41 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 20 Feb 2008 00:01:41 -0000
Subject: [issue1174606] Reading /dev/zero causes SystemError
Message-ID: <1203465701.81.0.170890823407.issue1174606@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

This seems like an easy fix: just check that S_ISREG(st_mode) is true in
 new_buffersize in fileobject.c.

----------
keywords: +easy
nosy: +akuchling

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1174606>
_____________________________________

From report at bugs.python.org  Wed Feb 20 01:11:26 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 20 Feb 2008 00:11:26 -0000
Subject: [issue1330538] datetime/xmlrpclib.DateTime comparison
Message-ID: <1203466286.04.0.0180696704838.issue1330538@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Skip, I can look at xmlrpclib issues.

----------
assignee: fdrake -> akuchling
nosy: +akuchling

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1330538>
_____________________________________

From report at bugs.python.org  Wed Feb 20 01:13:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Wed, 20 Feb 2008 00:13:45 -0000
Subject: [issue1424148] urllib.FancyURLopener.redirect_internal looses data on
	POST!
Message-ID: <1203466425.18.0.861696783148.issue1424148@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Can this item be closed, given jjlee's argument against changing the
behaviour?

----------
nosy: +akuchling

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1424148>
_____________________________________

From report at bugs.python.org  Wed Feb 20 01:58:00 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Feb 2008 00:58:00 -0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ctypes.util.find_library() fails to locate distorm64.so library 
because it has no SONAME entry:

$ objdump -p -j .dynamic /usr/local/lib/libdistorm64.so
/usr/local/lib/libdistorm64.so:     file format elf32-i386
(...)
Dynamic Section:
  NEEDED      libc.so.6
  INIT        0x12f4c
  FINI        0x1bf84
  HASH        0xb4
  (...)

Compare to libm.so:

$ objdump -p -j .dynamic /usr/lib/libm.so
/usr/lib/libm.so:     file format elf32-i386
(...)
Dynamic Section:
  NEEDED      ld-linux.so.2
  NEEDED      libc.so.6
  SONAME      libm.so.6
  INIT        0x335c
  (...)

I don't know why find_library() does use objdump to get SONAME.

Workaround to find_library() "bug": _get_soname() should return 
os.path.basename(f) instead of None. Is it correct?

Note: libdistorm64.so compilation is maybe broken (it's maybe not 
a "real" so library), but I'm able to use it with ctypes :-)

----------
components: Library (Lib)
messages: 62580
nosy: haypo
severity: normal
status: open
title: ctypes.util.find_library(): posix .so without SONAME
type: rfe
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
__________________________________

From report at bugs.python.org  Wed Feb 20 02:55:14 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Feb 2008 01:55:14 -0000
Subject: [issue2146] ctypes: support double for calling function
In-Reply-To: <1203472514.48.0.201306675616.issue2146@psf.upfronthosting.co.za>
Message-ID: <1203472514.48.0.201306675616.issue2146@psf.upfronthosting.co.za>


New submission from STINNER Victor:

ctypes doesn't support transparent conversion of double arguments. 
Example code:

from ctypes import cdll, c_double
libm = cdll.LoadLibrary("libm.so")
sqrt = libm.sqrt
sqrt.argstype = (c_double,)
sqrt.restype = c_double
print sqrt(4.0)

I wrote a patch to fix it: see attached patch

----------
components: Extension Modules
files: ctypes_callproc_double.patch
messages: 62581
nosy: haypo
severity: normal
status: open
title: ctypes: support double for calling function
type: rfe
versions: Python 2.5
Added file: http://bugs.python.org/file9467/ctypes_callproc_double.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2146>
__________________________________

From report at bugs.python.org  Wed Feb 20 04:51:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 20 Feb 2008 03:51:10 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203479470.11.0.0762429645381.issue2144@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I still must be missing something. There is no PEP 390, AFAICT.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Wed Feb 20 05:03:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 20 Feb 2008 04:03:54 -0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1203480234.34.0.249548164257.issue2145@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Thomas, can you take a look?

----------
assignee:  -> theller
nosy: +loewis, theller

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
__________________________________

From report at bugs.python.org  Wed Feb 20 05:04:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Feb 2008 04:04:24 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203480264.08.0.349842214434.issue2144@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Forgive me. I meant 290.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Wed Feb 20 05:04:50 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 20 Feb 2008 04:04:50 -0000
Subject: [issue2146] ctypes: support double for calling function
In-Reply-To: <1203472514.48.0.201306675616.issue2146@psf.upfronthosting.co.za>
Message-ID: <1203480290.82.0.253958755689.issue2146@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
assignee:  -> theller
nosy: +theller

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2146>
__________________________________

From report at bugs.python.org  Wed Feb 20 05:12:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 20 Feb 2008 04:12:34 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203480754.92.0.554304645582.issue2144@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Sorry, it still makes no sense. Up to r56113, PEP 290 doesn't seem to
talk about UserDict, os.environ, or inheritance from new-style classes.
What section are you specifically referring to?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Wed Feb 20 05:27:38 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 20 Feb 2008 04:27:38 -0000
Subject: [issue2147] int operations no longer overflow
In-Reply-To: <1203481658.28.0.135415143163.issue2147@psf.upfronthosting.co.za>
Message-ID: <1203481658.28.0.135415143163.issue2147@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

Georg, I hope you don't mind me assigning this to you.  Feel free to
unassign.  A colleague pointed me to section 5.7 in the old ref doc:

http://docs.python.org/ref/shifting.html

It says that shifting operations lose data on overflow.  This info is
outdated based on PEP 237.  I suspect there may be other inaccuracies
related to int overflow.  So the purpose of this bug is to point out the
specific problem as well as to log that we need to find all invalid
references to overflow.

----------
assignee: georg.brandl
components: Documentation
messages: 62586
nosy: georg.brandl, nnorwitz
severity: normal
status: open
title: int operations no longer overflow
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2147>
__________________________________

From report at bugs.python.org  Wed Feb 20 05:53:08 2008
From: report at bugs.python.org (Will Robinson)
Date: Wed, 20 Feb 2008 04:53:08 -0000
Subject: [issue2147] int operations no longer overflow
In-Reply-To: <1203481658.28.0.135415143163.issue2147@psf.upfronthosting.co.za>
Message-ID: <1203483188.51.0.0408379419919.issue2147@psf.upfronthosting.co.za>


Will Robinson added the comment:

Just jumping in to say the colleague Neal refers to is me, and I'm
interested in the resolution to this bug.  Thanks in advance for your help.

----------
nosy: +willrobinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2147>
__________________________________

From report at bugs.python.org  Wed Feb 20 11:28:04 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Feb 2008 10:28:04 -0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1203503284.1.0.787428156719.issue2145@psf.upfronthosting.co.za>


Changes by STINNER Victor:


Added file: http://bugs.python.org/file9468/libdistorm64.so

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
__________________________________

From report at bugs.python.org  Wed Feb 20 13:03:39 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Feb 2008 12:03:39 -0000
Subject: [issue2146] ctypes: support double for calling function
In-Reply-To: <1203472514.48.0.201306675616.issue2146@psf.upfronthosting.co.za>
Message-ID: <1203509019.58.0.849343014177.issue2146@psf.upfronthosting.co.za>


STINNER Victor added the comment:

Ooops, I had a typo in my code! Argument types argument name 
is "argtypes" and not "argstype". But well, the ticket is still 
valid :-) But it's more an enhancement than a bugfix ;-) So the right 
code is :

from ctypes import cdll, c_double
libm = cdll.LoadLibrary("libm.so")
sqrt = libm.sqrt
sqrt.restype = c_double
print sqrt(4.0)

The patch is useful when argstype is not set.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2146>
__________________________________

From report at bugs.python.org  Wed Feb 20 13:09:58 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Wed, 20 Feb 2008 12:09:58 -0000
Subject: [issue2039] Pymalloc patch for int and float objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1203509398.25.0.952472721123.issue2039@psf.upfronthosting.co.za>


Andrew I MacIntyre added the comment:

As noted in a posting to python-dev, I've re-evaluated my test methodology.
The results are as follows, with details of the PyBench runs in the 
pybench_summary.txt attachment:

----------------------------------------------------------------------
test        trunk                no-freelists         LIFO(500i,100f)
            case 1    case 2     case 1    case 2     case 1   case 2
----------------------------------------------------------------------
pystone     26500     26100      27000     25600      27000    26600
int 1       7.27us    9.09us     6.69us    20.4us     6.64us   9.25us
int 2       10.4us    9.48us     20.9us    20.9us     10.5us   9.69us
int 3       381us     360us      792us     813us      805us    780us
int 4       393us     373us      829us     834us      844us    799us
float 1     1.14ms    1.1ms      1.2ms     1.2ms      1.2ms    1.27ms
float 2     773us     831us      1.05ms    908us      865us    967us
float 3     733us     759us      970us     825us      804us    906us
float 4     74.6us    76.9us     100us     83.7us     77.6us   86.9us
float 5     7.88ms    8.09ms     10.7ms    8.93ms     8.46ms   9.43ms
pybench     16716ms   16666ms    16674ms   16612ms    16612ms  16611ms
script a    30.7s     30.6s      33.0s     33.0s      32.3s    32.6s
script b    41.7s     40.6s      42.1s     39.4s      40.5s    41.8s
----------------------------------------------------------------------
case: 1=std, 2=no small ints


test details
============

pystone:
 average of 3 runs

int 1:
 ./python -m timeit -s "range(1000)" "range(250)"

int 2:
 ./python -m timeit -s "range(1000)" "range(257,507)"

int 3:
 ./python -m timeit -s "range(10000)" "range(10000)"

int 4:
 ./python -m timeit -s "range(11000)" "range(257,10507)"

float 1:
 ./python -m timeit -s "[float(x) for x in range(1000)]" \
 "[float(x) for x in range(1000)]"

float 2:
 ./python -m timeit -s "map(float, range(1000))" "map(float, range(1000))"

float 3:
 ./python -m timeit -s "t = range(1000)" "map(float, t)"

float 4:
 ./python -m timeit -s "t = range(100)" "map(float, t)"

float 5:
 ./python -m timeit -s "t = range(10000)" "map(float, t)"

pybench:
 average runtime per round of ./python Tools/pybench/pybench.py -f <logfile>

script a:
<code>
import time

def b(time_now=time.clock):
    limit_val = 2000000
    d = [None] * limit_val
    start_time = time_now()
    for j in xrange(25):
        for i in xrange(limit_val):
            d[i] = i
        for i in d:
            d[i] = None
    return time_now() - start_time

if __name__ == '__main__':
    print 'elapsed: %s s' % b()
</code>

script b:
<code>
import time

def b(time_now=time.clock):
    limit_val = 1000000
    f = [None] * limit_val
    d = range(limit_val)
    start_time = time_now()
    for j in xrange(25):
        for i in d:
            f[i] = float(i)
        for i in d:
            f[i] = None
    return time_now() - start_time

if __name__ == '__main__':
    print 'elapsed: %s s' % b()
</code>

Added file: http://bugs.python.org/file9469/pybench_summary.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
__________________________________

From report at bugs.python.org  Wed Feb 20 13:23:14 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Wed, 20 Feb 2008 12:23:14 -0000
Subject: [issue2039] Pymalloc patch for int and float objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1203510194.8.0.255471692749.issue2039@psf.upfronthosting.co.za>


Andrew I MacIntyre added the comment:

My conclusions from the testing I've just reported:
- there are some contradictory results which make little (obvious)
sense, but the testing has been repeated a number of times and nearly
all tests repeat to with 1%;
- leave the int freelist as is, but move the compaction into
gc.collect() as suggested by tiran in a python-dev posting;
- keep the small int cache (it may profitably be increased to cover 
a wider range of ints, perhaps -256..1024?? - more testing required);
- the float freelist and float LIFO, while being attractive in
micro-benchmarks, are not useful enough to keep in large scale usage. 
This is especially the case when you consider that floats are much less
prevalent than ints in a wide range of Python programs.  Serious float
users gravitate to Numpy and other extensions in most cases, and the
simpler memory profile has its own attractions.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
__________________________________

From report at bugs.python.org  Wed Feb 20 13:30:31 2008
From: report at bugs.python.org (Ernst Persson)
Date: Wed, 20 Feb 2008 12:30:31 -0000
Subject: [issue2148] nis module not supporting group aliases
In-Reply-To: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za>
Message-ID: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za>


New submission from Ernst Persson:

Nis (applications?) has a line limit in the "group" entry, so you can't 
have very long lines (=many users)
The way to solve this is to put aliases in the group map, like this:
MY_GROUP::123:user1,user2
MY_GROUP::123:user3,user4

This is supported by the OS, grp.getgrall(), etc, but
nis.cat("group")
only puts the last entry into the dict it returns.

I guess the best thing if you want to return a dict is to merge the 
members if both the name and gid matches.

----------
components: None
messages: 62591
nosy: ernstp
severity: normal
status: open
title: nis module not supporting group aliases
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2148>
__________________________________

From report at bugs.python.org  Wed Feb 20 13:41:20 2008
From: report at bugs.python.org (Andrew I MacIntyre)
Date: Wed, 20 Feb 2008 12:41:20 -0000
Subject: [issue2039] Pymalloc patch for int and float objects
In-Reply-To: <1202404760.1.0.562652734774.issue2039@psf.upfronthosting.co.za>
Message-ID: <1203511280.97.0.846829208721.issue2039@psf.upfronthosting.co.za>


Andrew I MacIntyre added the comment:

I've realised I could have included tests for a build with the int
freelist but without the float freelist, to justify my conclusions.  The
short version: the script tests are almost identical to the baseline
result & most of the other results are between the no-freelist results
and the freelist/LIFO results.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2039>
__________________________________

From report at bugs.python.org  Wed Feb 20 13:55:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Feb 2008 12:55:08 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203512108.07.0.154310633549.issue2144@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I know that it doesn't mention inheriting dict specifically, but you
asked why, so I was referring to the Rationale: "Modernization options
arise when new versions of Python add features that allow improved
clarity or higher performance than previously available." Sorry for the
confusion.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Wed Feb 20 17:36:40 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Wed, 20 Feb 2008 16:36:40 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203525400.91.0.993498511759.issue2144@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

The performance gain is rather good:

hsoft-dev:python hsoft$ ./python.exe -m "timeit" -s "import os" 
"os.environ['HOME']"
1000000 loops, best of 3: 1.16 usec per loop
hsoft-dev:python hsoft$ patch -p0 < environ-modern.diff 
patching file Lib/os.py
hsoft-dev:python hsoft$ ./python.exe -m "timeit" -s "import os" 
"os.environ['HOME']"
1000000 loops, best of 3: 0.428 usec per loop

The regression tests still pass, and modernization of the code is a nice 
thing.

+1

----------
nosy: +vdupras

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Wed Feb 20 18:07:10 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 20 Feb 2008 17:07:10 -0000
Subject: [issue1286] fileinput, StringIO,
	and cStringIO do not support the with protocol
In-Reply-To: <1192538556.96.0.72107595061.issue1286@psf.upfronthosting.co.za>
Message-ID: <1203527230.51.0.0949209210614.issue1286@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Attached patch implements context management protocol for StringIO.

----------
components: +Library (Lib)
nosy: +belopolsky
versions:  -Python 3.0
Added file: http://bugs.python.org/file9470/with_StringIO.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1286>
__________________________________

From report at bugs.python.org  Wed Feb 20 19:51:54 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 20 Feb 2008 18:51:54 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203533514.14.0.265648950996.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

On i386 Linux, HZ is #defined as sysconf(_SC_CLK_TCK)

/usr/include/asm-i386/param.h:7:#define HZ sysconf(_SC_CLK_TCK)

so times does the right thing.  On x86_64 HZ is defined as 100, but it 
is the same value as sysconf returns.

I could not find an authoritative statement in this regard, but it 
appears that on modern Linuxes posix_times implementation usin HZ is 
correct.


On the other hand, os.times would be more useful if it just returned a 
tuple of clock ticks.  I suggest implementing os._times returning 
integer clock ticks in posixmodule and reimplementing os.times in os.py 
in terms of sysconf and _times.

----------
nosy: +belopolsky

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Wed Feb 20 21:15:46 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 20 Feb 2008 20:15:46 -0000
Subject: [issue2146] ctypes: support double for calling function
In-Reply-To: <1203472514.48.0.201306675616.issue2146@psf.upfronthosting.co.za>
Message-ID: <1203538546.25.0.0406650543065.issue2146@psf.upfronthosting.co.za>


Thomas Heller added the comment:

I reject this patch.  It would be an arbitrary decision whether a Python
float should be passed as a C float or as a C double, and the docs
explicitely mention which native Python types can be passed to function
calls when argtypes is not set; see the bottom of the page at
http://docs.python.org/lib/ctypes-calling-functions.html

----------
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2146>
__________________________________

From report at bugs.python.org  Wed Feb 20 21:19:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 20 Feb 2008 20:19:08 -0000
Subject: [issue2148] nis module not supporting group aliases
In-Reply-To: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za>
Message-ID: <1203538748.76.0.526609811176.issue2148@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Can you dig up some specification for that behaviour? The more official,
the better.

Otherwise, I'd rather add an option to return a list instead of a dict;
people wanting that semantics could then do their own processing.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2148>
__________________________________

From report at bugs.python.org  Wed Feb 20 21:28:02 2008
From: report at bugs.python.org (Ernst Persson)
Date: Wed, 20 Feb 2008 20:28:02 -0000
Subject: [issue2148] nis module not supporting group aliases
In-Reply-To: <1203510631.66.0.497834646199.issue2148@psf.upfronthosting.co.za>
Message-ID: <1203539282.02.0.0238460402009.issue2148@psf.upfronthosting.co.za>


Ernst Persson added the comment:

Here's another description of the issue:
http://www.tldp.org/HOWTO/NIS-HOWTO/maps.html#AEN548
There's a suggestion to have different group-names but same gids, but 
automatic splitters of nis-groups doesn't allways do this.

Right, grp.getgrall() returns a list, that's why it works.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2148>
__________________________________

From report at bugs.python.org  Wed Feb 20 21:30:58 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 20 Feb 2008 20:30:58 -0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1203539458.89.0.839658531707.issue2145@psf.upfronthosting.co.za>


Thomas Heller added the comment:

Honestly I do not know enough about linux shared libraries to have any
opinion about this issue.  IIRC, the find_library should behave in a
similar way as dynamic linking works on linux.  If this libdistorm64.so
is not a "real" so library, as you write, then maybe it should be
expected that find_library does not find it.

Can someone else help?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
__________________________________

From report at bugs.python.org  Wed Feb 20 21:46:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 20 Feb 2008 20:46:07 -0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1203540367.52.0.846019997536.issue2145@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

haypo, can you please give precise instructions on how to reproduce this
problem?
a) what operating system are you using?
b) what parameters are you passing to find_library?
c) what result are you getting?
d) what result are expecting instead?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
__________________________________

From report at bugs.python.org  Wed Feb 20 22:09:20 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Wed, 20 Feb 2008 21:09:20 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
Message-ID: <1203541760.62.0.918259488665.issue2149@psf.upfronthosting.co.za>


Changes by Rafael Zanella:


----------
components: Library (Lib)
nosy: zanella
severity: minor
status: open
title: Queue.maxsize, __init__() accepts any value as maxsize
type: security
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Wed Feb 20 22:20:40 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Wed, 20 Feb 2008 21:20:40 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>


New submission from Rafael Zanella:

Queue.Queue(), accepts any value as the maxsize, example:

foo = Queue.Queue('j');
l = []; foo = Queue.Queue(l);
...

Shouldn't the value passed be checked on init :
isinstance(maxsize, int) ?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Wed Feb 20 23:06:27 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 20 Feb 2008 22:06:27 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203545187.45.0.0770376719673.issue2149@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This is probably a matter of style.  For the most part, library code
avoids isinstance() checks and lets the errors surface downstream. 

If a check gets added, we should probably also check that the value is
non-negative.  The checks should not be backported because it could
break Queue subclasses that rely on being able to pass in a non-int
value (like None or like a dynamic object that allows the maxsize to be
increased during the run).

I'm unclear why this got classified as a security issue rather than just
an RFE for Py2.6.

----------
nosy: +rhettinger
priority:  -> low
versions: +Python 2.6 -Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Wed Feb 20 23:15:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 20 Feb 2008 22:15:09 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203545709.77.0.513295138222.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Is there a problem with a dynamic object that changes the maxsize? I
think it might be better to ignore it, and let the client get exceptions
when their maxsize is compared.

----------
nosy: +gutworth

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Wed Feb 20 23:59:50 2008
From: report at bugs.python.org (STINNER Victor)
Date: Wed, 20 Feb 2008 22:59:50 -0000
Subject: [issue2145] ctypes.util.find_library(): posix .so without SONAME
In-Reply-To: <1203469079.72.0.257217245849.issue2145@psf.upfronthosting.co.za>
Message-ID: <1203548390.84.0.667261604228.issue2145@psf.upfronthosting.co.za>


STINNER Victor added the comment:

? haypo, can you please give precise instructions on how to reproduce 
this problem? ?

Sure. Download http://www.ragestorm.net/distorm/dl.php?id=11 
(distorm-pkg1.7.28.tar.bz2), go to build/linux/. Then compile it 
with "make" and install it using make install.

a) what operating system are you using?

I'm using Ubuntu Gutsy, kernel 2.6.22, libc 2.6.1, ld 2.6.1, Python 
2.5.1.

b) what parameters are you passing to find_library?

LIB_FILENAME = find_library('distorm64')

c) what result are you getting?

The function _findLib_ldconfig(), used by find_library() internals, 
returns '/usr/local/lib/libdistorm64.so.1' but _get_soname() returns 
an empty string.

d) what result are expecting instead?

_get_soname(filename) should returns filename instead of None (and not 
basename(filename) as I proposed).

--

libdistorm64.so is not a "real" library, but i'm able to use it with 
cdll.LoadLibrary(). So I think that it can be considered as a Python 
(ctypes) bug.

PS: Why note text box is so small (5 lines) in this bug report???

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2145>
__________________________________

From report at bugs.python.org  Thu Feb 21 00:29:28 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Wed, 20 Feb 2008 23:29:28 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203550168.06.0.554033269383.issue2149@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

Firts: the security type was my error.

The method wich uses the maxsize:
"""
# Check whether the queue is full
def _full(self):
  return self.maxsize > 0 and len(self.queue) == self.maxsize
"""

@rhettinger: As per the documentation, negative values result on an
infinite Queue; well that AND will never be fulfilled with a negative
value anyway;

@gutworth: What I mean is that's "awkward", if you put an string for
example, it'll be the size of the string wich will be used on the
__cmp__ and on len(), but that's not explicit, or is it?

Example:

[zan at tails ~]$ python
Python 2.5.1 (r251:54863, Oct 30 2007, 13:54:11)
[GCC 4.1.2 20070925 (Red Hat 4.1.2-33)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...   def __init__(self): pass;
...
>>> c = C()
>>> import Queue
>>> a = Queue.Queue(c)
>>> len(c)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: C instance has no attribute '__len__'
>>> a = Queue.Queue(c)
>>> a.put('q')
>>> a.get()
'q'
>>> a.put(1)
>>> a.put(2)
>>> a.put(3)
>>>

----------
type: security -> feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 00:36:12 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 20 Feb 2008 23:36:12 -0000
Subject: [issue1600] str.format() produces different output on different
	platforms (Py30a2)
In-Reply-To: <1197450243.14.0.729685827203.issue1600@psf.upfronthosting.co.za>
Message-ID: <1203550572.81.0.495441813465.issue1600@psf.upfronthosting.co.za>


Eric Smith added the comment:

Checked in as r60909.  I started with Mark's patch, but added code to
both increase or decrease the number of zeros, as needed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1600>
__________________________________

From report at bugs.python.org  Thu Feb 21 01:19:11 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Thu, 21 Feb 2008 00:19:11 -0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1203553151.33.0.141968162989.issue2054@psf.upfronthosting.co.za>


Giampaolo Rodola' added the comment:

I've tried to work on this in the last 2 days and here is my
implementation attempt.
The patch in attachment provides a new FTP subclass which connects to
port 21 as usual leaving control and data channels implicitly unprotected.
Securing control and data channels requires user to explicitly ask for
it by using the new auth_tls() and prot_p() methods as recommended by
the standard RFC.

Usage example:

>>> from ftplib import FTP_TLS
>>> ftps = FTP_TLS('ftp.python.org')
>>> ftps.auth_tls()  # switch to secure control connection
'234 Using authentication type TLS'
>>> ftps.login()  # login anonimously
'230 Guest login ok, access restrictions apply.'
>>> ftps.prot_p()  # switch to secure data connection
'200 Protection level set to P'
>>> ftps.retrlines('LIST')  # list directory content securely
total 9
drwxr-xr-x   8 root     wheel        1024 Jan  3  1994 .
drwxr-xr-x   8 root     wheel        1024 Jan  3  1994 ..
drwxr-xr-x   2 root     wheel        1024 Jan  3  1994 bin
drwxr-xr-x   2 root     wheel        1024 Jan  3  1994 etc
d-wxrwxr-x   2 ftp      wheel        1024 Sep  5 13:43 incoming
drwxr-xr-x   2 root     wheel        1024 Nov 17  1993 lib
drwxr-xr-x   6 1094     wheel        1024 Sep 13 19:07 pub
drwxr-xr-x   3 root     wheel        1024 Jan  3  1994 usr
-rw-r--r--   1 root     root          312 Aug  1  1994 welcome.msg
'226 Transfer complete.'
>>> ftps.quit()
'221 Goodbye.'
>>>

It also provides a prot_c() method to switch back to a plain text data
channel.
Sorry in advance for any grammatical error I could have made in comments
and docstrings.

Comments are greatly appreciated.

----------
nosy: +giampaolo.rodola, janssen
Added file: http://bugs.python.org/file9471/ftplib.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
__________________________________

From report at bugs.python.org  Thu Feb 21 02:02:54 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Feb 2008 01:02:54 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203555774.18.0.645892352227.issue2149@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


Added file: http://bugs.python.org/file9472/queue_maxsize.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 03:00:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 02:00:30 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203559230.48.0.81372978659.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Rafael, I agree that it's awkward, and I'm not against restricting the
maxsize to just something sane. However, I'm worried this (Raymond's
patch) will be too restrictive by not allowing dynamic changing of
maxsize. (Of course, you could just change the maxsize attribute of the
Queue, but that would require holding the mutex, too.)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 03:10:32 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 02:10:32 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1203559832.09.0.383433420917.issue2127@psf.upfronthosting.co.za>


Changes by Benjamin Peterson:


----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Thu Feb 21 09:40:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Feb 2008 08:40:01 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203583201.39.0.47405357817.issue2149@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

What about requiring maxsize to be convertible to an int?
This would allow dynamic objects, if they define an __int__ method.
I join a patch.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file9473/queue_maxsize_2.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 10:16:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Feb 2008 09:16:18 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1203585378.93.0.665583491581.issue2127@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

IMO, connect() should accept unicode strings, and encode them to utf-8
when calling the C function.
Patch attached.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file9474/sqlite_connect.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Thu Feb 21 10:24:24 2008
From: report at bugs.python.org (Neil Roques)
Date: Thu, 21 Feb 2008 09:24:24 -0000
Subject: [issue2150] Broken Link to New Style Classes Documentation
In-Reply-To: <1203585864.58.0.589732806546.issue2150@psf.upfronthosting.co.za>
Message-ID: <1203585864.58.0.589732806546.issue2150@psf.upfronthosting.co.za>


New submission from Neil Roques:

http://docs.python.org/ref/node33.html (also packaged in the Python
documentation which comes with Python) links to:

http://www.python.org/doc/newstyle.html for information on new style classes

However, this link has moved, as should now read:

http://www.python.org/doc/newstyle/

----------
components: Documentation
messages: 62612
nosy: passage
severity: normal
status: open
title: Broken Link to New Style Classes Documentation
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2150>
__________________________________

From report at bugs.python.org  Thu Feb 21 10:52:53 2008
From: report at bugs.python.org (paul rubin)
Date: Thu, 21 Feb 2008 09:52:53 -0000
Subject: [issue2151] no way to get http result status from urllib
In-Reply-To: <1203587573.07.0.565348381729.issue2151@psf.upfronthosting.co.za>
Message-ID: <1203587573.07.0.565348381729.issue2151@psf.upfronthosting.co.za>


New submission from paul rubin:

I don't see any way in the docs to get the status of an http request, in
particular I want to know whether it's a 404.  It does show up in the
guts of the library so maybe I can extract it somehow, but there should
be a simple documented way.

Also, the urllib doc says the info() method returns a mimetools.Message
instance, but what actually comes back is an httplib.HTTPMessage
instance.  I guess that's a subclass, but it's confusing.  The doc
should describe what actually comes back.

----------
components: Library (Lib)
messages: 62613
nosy: phr
severity: normal
status: open
title: no way to get http result status from urllib
type: feature request
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2151>
__________________________________

From report at bugs.python.org  Thu Feb 21 11:00:12 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 21 Feb 2008 10:00:12 -0000
Subject: [issue2129] Link error of gethostbyaddr and gethostname in Python
	Manuals (the chm file)
In-Reply-To: <1203179561.47.0.405991627355.issue2129@psf.upfronthosting.co.za>
Message-ID: <1203588012.71.0.634012234412.issue2129@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

That's difficult to fix. Notice that this page does reference
gethostbyaddr (in the uname documentation), and that the online HTML
version links to both the socket and the os modules. Apparently, the CHM
generation picks up the first link.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2129>
__________________________________

From report at bugs.python.org  Thu Feb 21 11:48:32 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 21 Feb 2008 10:48:32 -0000
Subject: [issue2152] make sqlite.Row hashable correctly
In-Reply-To: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za>
Message-ID: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za>


New submission from Thomas Heller:

The attached patch implements hash and cmp for sqlite3.Row objects.

----------
files: sqliterow.patch
keywords: patch
messages: 62615
nosy: theller
severity: normal
status: open
title: make sqlite.Row hashable correctly
type: behavior
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9475/sqliterow.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2152>
__________________________________

From report at bugs.python.org  Thu Feb 21 12:03:17 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Thu, 21 Feb 2008 11:03:17 -0000
Subject: [issue1621] Do not assume signed integer overflow behavior
In-Reply-To: <1197593027.35.0.00314874350765.issue1621@psf.upfronthosting.co.za>
Message-ID: <1203591797.87.0.899102990053.issue1621@psf.upfronthosting.co.za>


Ismail Donmez added the comment:

Any news on this? Also gcc 4.3 & gcc 4.2.3 fixed the -Wall clobbering -
Wstrict-overflow problem, which is good news.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1621>
__________________________________

From report at bugs.python.org  Thu Feb 21 12:16:40 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Thu, 21 Feb 2008 11:16:40 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203592600.29.0.490118621008.issue1533@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

FWIW, using xrange() it seems to give the proper error message:

Traceback (most recent call last):
  File "bad_range.py", line 12, in <module>
    print xrange(MyInt(2**64), MyInt(2**64+10))
OverflowError: long int too large to convert to int

----------
nosy: +zanella

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Thu Feb 21 12:29:01 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Thu, 21 Feb 2008 11:29:01 -0000
Subject: [issue2079] UserDict documentation typo
In-Reply-To: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>
Message-ID: <1203593341.32.0.30930786119.issue2079@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven added the comment:

Patch for against 2.6 trunk @ r60910.

----------
nosy: +asmodai
Added file: http://bugs.python.org/file9476/userdict.rst.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2079>
__________________________________

From report at bugs.python.org  Thu Feb 21 12:30:43 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Thu, 21 Feb 2008 11:30:43 -0000
Subject: [issue2079] UserDict documentation typo
In-Reply-To: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>
Message-ID: <1203593443.09.0.613710190457.issue2079@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven added the comment:

Patch against 2.5 trunk @ r60911.

Added file: http://bugs.python.org/file9477/libuserdict.tex.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2079>
__________________________________

From report at bugs.python.org  Thu Feb 21 13:56:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 12:56:23 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203598582.93.0.699088526874.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I like it.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 14:06:05 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Thu, 21 Feb 2008 13:06:05 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203599165.91.0.865166920052.issue2149@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

@gutworth: Since one of the main uses of Queue is with threads, I think
it *really* should acquire the mutex before changing the maxsize;

@amaury.forgeotdarc: Your patch makes the point of allowing the size to
be changed at some other place (e.g.: an attribute of an instance passed
as the maxsize), but as stated above I think (am not an expert) the
mutex really should be held before the maxsize change, another point:
using an instance on your patch a call to Queue.maxsize would return
something like:
"""
Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class C:
...   def __init(self): self.n = 1;
...   def __int__(self): return int(self.n);
...
>>> c = C()
>>> import Queue
>>> q = Queue.Queue(c)
>>> q.maxsize
<__main__.C instance at 0xb7c341ac>
>>>                                        
"""
wich would force to have a get() to the maxsize attribute;

I have added a diff;

Added file: http://bugs.python.org/file9478/queue_maxsize_3.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 14:18:14 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 13:18:14 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>


New submission from Virgil Dupras:

What prompted me to do these changes is that "Backward compatibility" 
section for 2.1 and earlier. How long are we going to keep this? According 
to svn, no commit has been made on the 2.1 branch since 2003. Is it safe 
to assume no unittest change is ever going to be backported to 2.1?

Then, while I was in it, I made other changes:

 - dict.has_key(key) --> key in dict
 - raise Exception, args --> raise Exception(args)
 - try..except KeyboardInterrupt: raise except: do_stuff() --> try..except 
Exception: do_stuff()
 - __metaclass__ = type --> all classes are now object subclasses

I'm not sure about the last one. Are those 2 equivalent? Is there a reason 
to keep is as "__metaclass__ = type"?

regrtest passed for me.

----------
components: Tests
files: unittest_modern.diff
messages: 62622
nosy: vdupras
severity: minor
status: open
title: unittest.py modernization
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9479/unittest_modern.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 15:26:45 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Feb 2008 14:26:45 -0000
Subject: [issue2154] doc: better detection of python snippets for highliting
In-Reply-To: <1203604005.4.0.314961213183.issue2154@psf.upfronthosting.co.za>
Message-ID: <1203604005.4.0.314961213183.issue2154@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc:

The new doc framework highlights python code, and looks very nice.
However, some snippets are not parseable by the compiler, and are thus
left unhighlighted. For example:
http://docs.python.org/dev/whatsnew/2.6.html#the-contextlib-module

The vast majority of misses is because of lines containing "...", which
is not a valid expression (except in slices).
The attached patch tries to recognize some common patterns, and replaces
"..." by some valid identifier; "... continue processing ..." is also
transformed. 

Note that the replacements are done only to get a better answer to "is
this block a python code"; pygment still works on the original string.

I checked that all new highlighted blocks are actually python snippets.
(actually, except one in configfile.rst; but others similar blocks on
the same page were already wrongly given to the python lexer)

The patch also corrects some easy syntax errors in samples.

----------
components: Documentation, Documentation tools (Sphinx)
files: doc_highlight.patch
keywords: patch
messages: 62623
nosy: amaury.forgeotdarc, georg.brandl
severity: normal
status: open
title: doc: better detection of python snippets for highliting
versions: Python 2.6
Added file: http://bugs.python.org/file9480/doc_highlight.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2154>
__________________________________

From report at bugs.python.org  Thu Feb 21 16:34:58 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Thu, 21 Feb 2008 15:34:58 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203608098.03.0.63876710218.issue2149@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

Mine patch doesn't address the "hold the mutex before changing the
maxsize" guess it would then force a get()?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 16:48:01 2008
From: report at bugs.python.org (Michael Hoffman)
Date: Thu, 21 Feb 2008 15:48:01 -0000
Subject: [issue2155] optparse.OptionGroup with_statement context handling
In-Reply-To: <1203608881.22.0.564217354476.issue2155@psf.upfronthosting.co.za>
Message-ID: <1203608881.22.0.564217354476.issue2155@psf.upfronthosting.co.za>


New submission from Michael Hoffman:

Adding these four lines to optparse.OptionGroup makes using option
groups vastly easier:

    def __enter__(self):
        return self

    def __exit__(self, *exc_info):
        self.parser.add_option_group(self)

You can then do things like:

    with OptionGroup(parser, "Group name") as group:
        group.add_option(...)

----------
components: Library (Lib)
messages: 62625
nosy: hoffman
severity: normal
status: open
title: optparse.OptionGroup with_statement context handling
type: feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2155>
__________________________________

From report at bugs.python.org  Thu Feb 21 16:50:43 2008
From: report at bugs.python.org (Michael Hoffman)
Date: Thu, 21 Feb 2008 15:50:43 -0000
Subject: [issue2130] [feature-request] Please add bool data type to "optparse"
	module
In-Reply-To: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>
Message-ID: <1203609043.06.0.858647108704.issue2130@psf.upfronthosting.co.za>


Michael Hoffman added the comment:

As gpolo points out, this facility already exists. This RFE should be
closed.

----------
nosy: +hoffman

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2130>
__________________________________

From report at bugs.python.org  Thu Feb 21 17:11:36 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 16:11:36 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>


New submission from Virgil Dupras:

I've been using unittest for quite a while. One thing I got tired with is 
the code duplication for file management and mocking. A few months ago I 
created this nifty little TestCase subclass and I've been using it ever 
since. It works quite well.

Am I the only one to extensively use temporary files and mocking in my 
tests? If not, I would suggest integrating my little subclass to 
unittest.Testcase, or if people think these functionalities out-scope 
unittest.TestCase, maybe we could put it in a separate unit.

Here's the unit I have here.

----------
components: Tests
files: testcase.py
messages: 62627
nosy: vdupras
severity: minor
status: open
title: TestCase.tmpdir(), TestCase.mock()
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9481/testcase.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 17:29:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Feb 2008 16:29:57 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203611397.67.0.158637298273.issue2153@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

? propos modernizing unittest, may I suggest taking a look at #1034053. :)

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 17:58:54 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Feb 2008 16:58:54 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203613134.67.0.488117311991.issue2149@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It's probably best to close this as "won't fix".  Each of the patches 
limits the module or complicates it a bit.  I'm not sure there's even a 
real problem here.  My preference is to leave this code untouched.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 17:59:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 16:59:49 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203613189.64.0.065529764868.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Maybe, we should change change the constructor to use self.maxsize =
int(maxsize). Then we can provide a set_maxsize method that will acquire
the mutex and preform the change. This is will restrict the type of
maxsize and allow for easy dynamic changing.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 18:02:09 2008
From: report at bugs.python.org (Robert Bradshaw)
Date: Thu, 21 Feb 2008 17:02:09 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203613329.36.0.889012188699.issue1533@psf.upfronthosting.co.za>


Robert Bradshaw added the comment:

Yes, the error for xrange is more illustrative of the problem, but just
shows that xrange has this a too. Why should xrange be invalid for
non-word sized values (especially as range works)? Incidentally, just a
week ago I had to write my own iterator for a project because xrange
couldn't handle large values.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Thu Feb 21 18:05:07 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Feb 2008 17:05:07 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203613507.57.0.105677294092.issue2149@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Recommend closing this.  No need to muck-up a clean module to solve a 
non-problem.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 18:07:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 17:07:10 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203613630.67.0.560818621779.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Raymond, are you referring to the int checking, my new method, or both?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 18:10:49 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Feb 2008 17:10:49 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203613849.35.0.957806576212.issue2149@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Both.  There is no issue here worth adding a new method.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 18:13:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 17:13:44 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203614024.28.0.954525348865.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Ok. I agree that we shouldn't muddy the waters of Queue by checking for
int. (set_maxsize would be unneeded) Go ahead and close.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 18:18:26 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Feb 2008 17:18:26 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203614306.17.0.672556879695.issue2149@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Thu Feb 21 18:41:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 17:41:33 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203615693.64.0.00222869901539.issue2153@psf.upfronthosting.co.za>


Changes by Benjamin Peterson:


----------
nosy: +purcell

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 19:00:09 2008
From: report at bugs.python.org (Teajay)
Date: Thu, 21 Feb 2008 18:00:09 -0000
Subject: [issue1777134] minidom pretty xml output improvement
Message-ID: <1203616809.14.0.360416097665.issue1777134@psf.upfronthosting.co.za>


Teajay added the comment:

Thanks for the feedback. I looked at the issues you mentionned and tried
to sort that out. You might want to have a look it this new patch. I ran
the tests, added a new test case and hopefully managed to get the code
style right this time :-)

Let me know if there is anything else I need to improve.

Added file: http://bugs.python.org/file9482/minidom_output_improvement.patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1777134>
_____________________________________

From report at bugs.python.org  Thu Feb 21 19:10:23 2008
From: report at bugs.python.org (Russell Owen)
Date: Thu, 21 Feb 2008 18:10:23 -0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1203617423.06.0.120948600182.issue799428@psf.upfronthosting.co.za>


Russell Owen added the comment:

The bug still exists. Please assign this bug and patch to Martin Loewis if 
possible (I don't have privileges for that).

----------
nosy: +reowen
type:  -> behavior
versions: +Python 2.5 -Python 2.3
Added file: http://bugs.python.org/file9483/Tkinter_patch.txt

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
____________________________________

From report at bugs.python.org  Thu Feb 21 19:20:12 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 21 Feb 2008 18:20:12 -0000
Subject: [issue1292] libffi needs an update to support mips64,
	arm and armeabi on linux
In-Reply-To: <1192699386.49.0.555660775493.issue1292@psf.upfronthosting.co.za>
Message-ID: <1203618012.0.0.768555377527.issue1292@psf.upfronthosting.co.za>


Thomas Heller added the comment:

I'm reopening this.  libffi 3 has been released; I have created the
libffi3-branch for this work in Python svn.

----------
status: closed -> open

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1292>
__________________________________

From report at bugs.python.org  Thu Feb 21 19:45:13 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 18:45:13 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1203619513.5.0.0556959353276.issue2127@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

Shouldn't we apply this patch directly on pysqlite? Any change made to 
the sqlite3 module will be overwritten in the next "refresh", right? 
Anyway, I'm not 100% sure, but it might already be fixed:

http://www.initd.org/tracker/pysqlite/changeset/452

So, maybe create a ticket to use the latest version of pysqlite?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Thu Feb 21 19:57:03 2008
From: report at bugs.python.org (wrobell)
Date: Thu, 21 Feb 2008 18:57:03 -0000
Subject: [issue2157] sqlite numeric type conversion problems
In-Reply-To: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>
Message-ID: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>


New submission from wrobell:

Numeric type conversion does not always work when using SQLite module.

Let's assume schema:

    create table test_num(no numeric);

Fetching a `test_num.no` table gives float by default.

Now, let's register some converter

    sqlite3.register_converter('numeric', lambda d: Decimal(d))

Fetching `test_num.no` gives Decimal.

But change `test_num.no` type to `numeric(10, 2)`. Float is returned.
This can be fixed by

    sqlite3.register_converter('numeric(10,', lambda d: Decimal(d))

But above will fail for `test_num.no: numeric(10,2)', which works in
case of

    sqlite3.register_converter('numeric(10,2)', lambda d: Decimal(d))

SQLite module's cursor object type cast mechanism breaks declared
type after first space {i.e. "numeric(10, 2)" -> "numeric(10,"} and
then looks up registered type converter using the first "word".

The simple fix for above could be to perform the break after space
or "(" character. Patch attached.

----------
components: Library (Lib)
files: python-sqlite-numeric.patch
messages: 62640
nosy: wrobell
severity: normal
status: open
title: sqlite numeric type conversion problems
versions: Python 2.5
Added file: http://bugs.python.org/file9484/python-sqlite-numeric.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2157>
__________________________________

From report at bugs.python.org  Thu Feb 21 20:27:45 2008
From: report at bugs.python.org (Steve Purcell)
Date: Thu, 21 Feb 2008 19:27:45 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203622065.0.0.876316385306.issue2153@psf.upfronthosting.co.za>


Steve Purcell added the comment:

Hi Virgil; thanks for stepping up to this.  Backward compatibility was 
largely for the sake of compatibility with Jython, which was always 
lagging far behind CPython.  I doubt it's a concern these days, and the 
unittest.py in the Python source repository should probably always be 
implemented in the nicest, cleanest way possible with the latest 
CPython.

Your changes look good to me, except for the KeyboardInterrupt one -- 
unless the way Ctrl-C is handled by Python has changed in the last 
couple of years, changing this "except:" clause will stop the text-mode 
test runner from being interruptible.  Admittedly the TextTestRunner 
should somehow be given an opportunity to detect Ctrl-C in order to stop 
when asked, but this diff does not allow for that.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 20:43:25 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 19:43:25 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203623005.2.0.0468029673481.issue2153@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

Isn't it why KeyboardInterrupt is a subclass of BaseException instead of 
Exception (along with SystemExit)? so that "except Exception:" doesn't 
catch it?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 20:52:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 19:52:01 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203623521.74.0.82376300323.issue2156@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

First, is hs a company package? You'll most likely want to remove it.

Otherwise, this looks useful. I wonder if this is something we could use
in test.test_support. I'd like it for some of Python's regression tests.
Brett, what do you think about that?

----------
nosy: +benjamin.peterson, brett.cannon

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 20:54:45 2008
From: report at bugs.python.org (Geoffrey Irving)
Date: Thu, 21 Feb 2008 19:54:45 -0000
Subject: [issue2158] confusing exception when opening a filename with
	nonprintable characters
In-Reply-To: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>
Message-ID: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>


New submission from Geoffrey Irving:

On Mac OS X with python 2.5.1, I get

>>> open(chr(212),'w')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IOError: invalid mode: w

The error should be more like "filename contains nonprintable characters."

Thanks,
Geoffrey

----------
components: Macintosh
messages: 62644
nosy: irving
severity: normal
status: open
title: confusing exception when opening a filename with nonprintable characters
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Thu Feb 21 20:55:14 2008
From: report at bugs.python.org (Steve Purcell)
Date: Thu, 21 Feb 2008 19:55:14 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203623714.83.0.365328412031.issue2153@psf.upfronthosting.co.za>


Steve Purcell added the comment:

Yes indeed - you're exactly right; just checked now.  Then disregard my 
previous comment!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 20:56:36 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 19:56:36 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203623796.41.0.963199164668.issue2156@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

Well, yeah, but I'm the owner, it's not like if the copyright was a 
problem. I'd gladly release it (and the test unit that goes with it) under 
BSD.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:00:00 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 21 Feb 2008 20:00:00 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203624000.34.0.53872015947.issue2156@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

Oh, you meant hs.path? ah yeah, it's just for tmppath(), which is of no 
use except in my own stuff.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:00:23 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 21 Feb 2008 20:00:23 -0000
Subject: [issue2158] confusing exception when opening a filename with
	nonprintable characters
In-Reply-To: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>
Message-ID: <1203624023.85.0.167692608602.issue2158@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I've tried the example with Python 2.6 + 3.0 on Linux and Windows. No
errors here.

----------
nosy: +tiran
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:01:48 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 20:01:48 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203624108.1.0.960116749924.issue2156@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The Path class of hs.path is, I assume, a nice wrapper around a file or
directory. However, Python does not have something like this, so it's
probably more useful to just return the raw path.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:04:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 20:04:18 -0000
Subject: [issue2158] confusing exception when opening a filename with
	nonprintable characters
In-Reply-To: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>
Message-ID: <1203624257.97.0.762885125573.issue2158@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I can confirm on the trunk with Mac OSX 10.4.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:04:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 20:04:47 -0000
Subject: [issue2158] confusing exception when opening a filename with
	nonprintable characters
In-Reply-To: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>
Message-ID: <1203624287.05.0.699211071131.issue2158@psf.upfronthosting.co.za>


Changes by Benjamin Peterson:


----------
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:05:15 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 21 Feb 2008 20:05:15 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203624315.94.0.262313888816.issue2153@psf.upfronthosting.co.za>


Christian Heimes added the comment:

All changes are looking fine to me but I haven't looked at the patch so far.

"__metaclass__ = type" is easier to write than subclassing from object.
Both are equivalent. 

>>> __metaclass__ = type
>>> class Foo: pass
...
>>> Foo
<class '__main__.Foo'>
>>> Foo.__bases__
(<type 'object'>,)
>>> type(Foo)
<type 'type'>

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:05:24 2008
From: report at bugs.python.org (Geoffrey Irving)
Date: Thu, 21 Feb 2008 20:05:24 -0000
Subject: [issue2158] confusing exception when opening a filename with
	nonprintable characters
In-Reply-To: <1203624023.85.0.167692608602.issue2158@psf.upfronthosting.co.za>
Message-ID: <7f9d599f0802211205t7dd435c5ie65210034b878c91@mail.gmail.com>


Geoffrey Irving added the comment:

It works fine for me on Linux as well, and on FreeBSD.  I expect it's
a mac specific bug.

Geoffrey

On Thu, Feb 21, 2008 at 12:00 PM, Christian Heimes
<report at bugs.python.org> wrote:
> Christian Heimes added the comment:
>
>  I've tried the example with Python 2.6 + 3.0 on Linux and Windows. No
>  errors here.
>
>  ----------
>  nosy: +tiran
>  priority:  -> normal
>
>
>
>  __________________________________
>  Tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue2158>
>  __________________________________
>

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:05:28 2008
From: report at bugs.python.org (Christian Heimes)
Date: Thu, 21 Feb 2008 20:05:28 -0000
Subject: [issue2153] unittest.py modernization
In-Reply-To: <1203599894.08.0.0572757924214.issue2153@psf.upfronthosting.co.za>
Message-ID: <1203624328.77.0.298497927405.issue2153@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
keywords: +patch
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2153>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:11:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 21 Feb 2008 20:11:16 -0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1203624676.98.0.760141525708.issue799428@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
keywords: +patch

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
____________________________________

From report at bugs.python.org  Thu Feb 21 21:18:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Feb 2008 20:18:09 -0000
Subject: [issue2129] Link error of gethostbyaddr and gethostname in Python
	Manuals (the chm file)
In-Reply-To: <1203179561.47.0.405991627355.issue2129@psf.upfronthosting.co.za>
Message-ID: <1203625089.61.0.828517487533.issue2129@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I think you get two links in the CHM generated by Sphinx. Can somebody
with a working HTML Help Compiler check that?

----------
assignee:  -> georg.brandl
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2129>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:18:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 21 Feb 2008 20:18:22 -0000
Subject: [issue2158] confusing exception when opening a filename with
	nonprintable characters
In-Reply-To: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>
Message-ID: <1203625102.16.0.376467235111.issue2158@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

The problem appears to be that Mac's strerror doesn't return a good
error message. We could try to detect this sort of thing, but I'm not
sure how.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:19:18 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Feb 2008 20:19:18 -0000
Subject: [issue2150] Broken Link to New Style Classes Documentation
In-Reply-To: <1203585864.58.0.589732806546.issue2150@psf.upfronthosting.co.za>
Message-ID: <1203625158.43.0.875897110958.issue2150@psf.upfronthosting.co.za>


Georg Brandl added the comment:

This link has already been fixed in SVN.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2150>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:19:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Feb 2008 20:19:55 -0000
Subject: [issue2151] no way to get http result status from urllib
In-Reply-To: <1203587573.07.0.565348381729.issue2151@psf.upfronthosting.co.za>
Message-ID: <1203625195.53.0.22147367116.issue2151@psf.upfronthosting.co.za>


Georg Brandl added the comment:

I've committed a patch for this in the trunk, the addinfourl object has
a "code" attribute there.

----------
nosy: +georg.brandl
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2151>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:34:46 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Feb 2008 20:34:46 -0000
Subject: [issue2079] UserDict documentation typo
In-Reply-To: <1202833743.63.0.904549377666.issue2079@psf.upfronthosting.co.za>
Message-ID: <1203626086.0.0.424565623293.issue2079@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Committed in r60936, r60937. Thanks!

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2079>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:40:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 21 Feb 2008 20:40:14 -0000
Subject: [issue2154] doc: better detection of python snippets for highliting
In-Reply-To: <1203604005.4.0.314961213183.issue2154@psf.upfronthosting.co.za>
Message-ID: <1203626414.56.0.273478250855.issue2154@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Committed as r60938 (python) and r60939 (sphinx). Thanks for the nice patch!

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2154>
__________________________________

From report at bugs.python.org  Thu Feb 21 21:51:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 21 Feb 2008 20:51:04 -0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1203627063.98.0.9149097091.issue2128@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I dislike the double decoding, and would prefer if sys.argv would be
created directly from the wide command line.

In addition, I think the patch is incorrect: it ignores the arguments to
Py_Main, which is a documented API function.

One solution might be to declare all these functions (Py_Main,
SetProgramName, GetArgcArgv) to operate on Py_UNICODE*, and then
convert the POSIX callers of Py_Main to use mbstowcs when going
from the command line to Py_Main. WinMain could then become 
recompiled for Unicode directly, likewise Modules/python.c

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
__________________________________

From report at bugs.python.org  Thu Feb 21 22:34:18 2008
From: report at bugs.python.org (Giovanni Bajo)
Date: Thu, 21 Feb 2008 21:34:18 -0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1203629658.59.0.877435406075.issue2128@psf.upfronthosting.co.za>


Giovanni Bajo added the comment:

mbstowcs uses LC_CTYPE. Is that correct and consistent with the way
default encoding under UNIX is handled by Py3k?

Would a Py_MainW or similar wrapper be easier on the UNIX guys? I'm just
asking, I don't have a definite idea.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
__________________________________

From report at bugs.python.org  Thu Feb 21 22:37:49 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Feb 2008 21:37:49 -0000
Subject: [issue1038909] pydoc method documentation lookup enhancement
Message-ID: <1203629869.33.0.636782844692.issue1038909@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I agree this behaviour would definitely be useful.

----------
nosy: +pitrou

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1038909>
_____________________________________

From report at bugs.python.org  Thu Feb 21 22:38:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 21 Feb 2008 21:38:04 -0000
Subject: [issue1038909] pydoc method documentation lookup enhancement
Message-ID: <1203629884.72.0.527992076727.issue1038909@psf.upfronthosting.co.za>


Changes by Antoine Pitrou:


----------
type:  -> feature request
versions: +Python 2.6 -Python 2.4

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1038909>
_____________________________________

From report at bugs.python.org  Thu Feb 21 22:39:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 21 Feb 2008 21:39:32 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203629972.74.0.567714806769.issue2156@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

-1 on adding these to unittest. The module is already too complex.

Mock objects have been rejected previously and the rationale still
holds.  There is no standardized approach that meets everyone's needs.
It doesn't make sense to lock in one of the many ways of doing it.

The tmpdir() method also locks-in one of many approaches.

I recommend against both additions.

----------
assignee:  -> purcell
nosy: +purcell, rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 22:43:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 21 Feb 2008 21:43:37 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1203630217.32.0.292714230611.issue2127@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

> So, maybe create a ticket to use the latest version of pysqlite?
I don't think so. While the change you are pointing to does deal with
the same problem, the base versions seems to have substantial differences.
I still prefer my patch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Thu Feb 21 23:01:34 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 21 Feb 2008 22:01:34 -0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203629658.59.0.877435406075.issue2128@psf.upfronthosting.co.za>
Message-ID: <47BDF4BA.5030006@v.loewis.de>


Martin v. L?wis added the comment:

> mbstowcs uses LC_CTYPE. Is that correct and consistent with the way
> default encoding under UNIX is handled by Py3k?

It's correct, but it's not consistent with the default encoding - there
isn't really any default encoding in Py3k. More specifically,
PyUnicode_FromString uses UTF-8, but not as a (changeable) default,
but as part of its API specification.
Command line arguments are in the locale's charset, so the LC_CTYPE
must be used to convert them.

> Would a Py_MainW or similar wrapper be easier on the UNIX guys? I'm just
> asking, I don't have a definite idea.

See above. The current POSIX implementation is incorrect also. It should
use the locale's encoding, but doesn't.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2128>
__________________________________

From report at bugs.python.org  Thu Feb 21 23:29:37 2008
From: report at bugs.python.org (Ned Deily)
Date: Thu, 21 Feb 2008 22:29:37 -0000
Subject: [issue2158] confusing exception when opening a filename with
	nonprintable characters
In-Reply-To: <1203623685.35.0.327745267074.issue2158@psf.upfronthosting.co.za>
Message-ID: <1203632977.07.0.548671426929.issue2158@psf.upfronthosting.co.za>


Ned Deily added the comment:

I cannot reproduce the problem on Intel OSX 10.5.2 (Leopard) with either 
the built-in 2.5.1 or with the MacPython 2.5.1:
$ /usr/bin/python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> open(chr(212),'w')
<open file '?', mode 'w' at 0x7b2a8>

However, I can reproduce it on a 10.4.11 system (PPC) with the built-in 
2.3.5 or an earlier MacPython 2.4.4.

Further investigation with a simple C program shows similar behavior.

#include <stdio.h>
#include <fcntl.h>
#include <stdarg.h>
#include <stdlib.h>
#define PMODE 0644

int main(argc, argv)
int argc;
char *argv[];
{
    int f1;
    if ((f1 = creat(argv[1], PMODE))  == -1) {
        printf("can't create %s \n", argv[1]);
        exit(1);
    }
    printf("OK\n");
    exit(0);
}

On the 10.4.11 system, a creat fails with a similar file name:

$ cc --version
powerpc-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 
5367)
...
$ ./Testtest a
OK
pbg3:~ nad$ ./Testtest $'\xd4'
can't create ? 
pbg3:~ nad$

but on 10.5.2, it works:
$ cc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5465)
...
$ ./Testtest a
OK
fimt:d nad$ ./Testtest $'\xd4'
OK

So perhaps this issue should be closed?

----------
nosy: +nad

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2158>
__________________________________

From report at bugs.python.org  Thu Feb 21 23:50:25 2008
From: report at bugs.python.org (Steve Purcell)
Date: Thu, 21 Feb 2008 22:50:25 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203634225.49.0.669148223392.issue2156@psf.upfronthosting.co.za>


Steve Purcell added the comment:

I agree with Raymond: -1 from me.  There isn't a consensus on what "mock 
object" means*, and trying to provide a standardised mock object 
facility is a quagmire*, hence the prior rejections to which Raymond 
refers.

It's easy to roll your own simple mock objects as needed, e.g. for 
whichever Python regression tests might need them.


* Note, for instance, that mock object libraries variously provide 
support for record/playback of calls, partial replacement of methods in 
existing classes or instances, and subtle distinctions between "stubs" 
and "mocks".  I'm aware of at least three wildly different yet equally 
popular mock object libraries in the Java world, each with its own 
uniquely opinionated user base.

----------
resolution:  -> rejected

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Thu Feb 21 23:50:35 2008
From: report at bugs.python.org (Steve Purcell)
Date: Thu, 21 Feb 2008 22:50:35 -0000
Subject: [issue2156] TestCase.tmpdir(), TestCase.mock()
In-Reply-To: <1203610296.31.0.753914026052.issue2156@psf.upfronthosting.co.za>
Message-ID: <1203634235.31.0.428599287047.issue2156@psf.upfronthosting.co.za>


Changes by Steve Purcell:


----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2156>
__________________________________

From report at bugs.python.org  Fri Feb 22 01:39:22 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 22 Feb 2008 00:39:22 -0000
Subject: [issue1110705] list comprehension scope
Message-ID: <1203640762.67.0.411201107582.issue1110705@psf.upfronthosting.co.za>


Daniel Stutzbach added the comment:

The resolution on this bug reads, "In future versions of Python, Guido
would like to change the design to hide the induction variable.  So,
someday, you'll get your wish."

Can this bug be re-opened and the wart removed in 3.0?

----------
nosy: +stutzbach

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1110705>
_____________________________________

From report at bugs.python.org  Fri Feb 22 01:41:15 2008
From: report at bugs.python.org (johansen)
Date: Fri, 22 Feb 2008 00:41:15 -0000
Subject: [issue2159] dbmmodule inquiry function is performance prohibitive
In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>
Message-ID: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>


New submission from johansen:

We've been using Python 2.4 to build the new package management software
for OpenSolaris.  We use a ndbm database to hold keywords about
packages, and found that each time we added a new OpenSolaris build to
our package repository, the time to import would increase by about 1/3
of the previous time.

It turns out that we were continually invoking a function in the
dbmmodule that walked the entire database every time the function was
called.

Looking at dbmmodule.c, the source for dbm.so, is instructive:

This is dbm_length, the function that we're _always_ calling.

static int
dbm_length(dbmobject *dp)
{
        if (dp->di_dbm == NULL) {
                 PyErr_SetString(DbmError, "DBM object has already been
closed"); 
                 return -1; 
        }
        if ( dp->di_size < 0 ) {
                datum key;
                int size;

                size = 0;
                for ( key=dbm_firstkey(dp->di_dbm); key.dptr;
                      key = dbm_nextkey(dp->di_dbm))
                        size++;
                dp->di_size = size;
        }
        return dp->di_size;
}

It's a knock-off of function shown in ndbm(3C) that traverses the
database.  It looks like this function walks every record in the
database, and then returns that as its size.

Further examination of dbmmodule shows that dbm_length has been assigned
as the function for the inquiry operator:

static PyMappingMethods dbm_as_mapping = {
        (inquiry)dbm_length,            /*mp_length*/
        (binaryfunc)dbm_subscript,      /*mp_subscript*/
        (objobjargproc)dbm_ass_sub,     /*mp_ass_subscript*/
};


It looks like dbm_length stashes the size of the database, so it doesn't
always have to traverse it.  However, further examination of the source
shows that an insertion doesn't update the di_size counter.  Worse yet,
an update or a delete will cause the counter to be set to -1.  This
means that the next call to dbm_length will have to walk the entire
database all over again.  Ick.

One of the problem parts of the code is this line in catalog.py:
update_searchdb():

                if fmri_list:
                        if not self.searchdb:
                                self.searchdb = \
                                    dbm.open(self.searchdb_file, "c")

This if not triggers the PyObject_IsTrue that invokes the inquiry operator
for the dbm module.  Every time we run this code, we're going to walk
the entire database.  By changing this to:

                if fmri_list:
                        if self.searchdb is None:
                                self.searchdb = \
                                    dbm.open(self.searchdb_file, "c")

We were able to work around the problem by using the is None check,
instead of if not self.searchdb; however, this seems like it is really a
problem with the dbmmodule and should ultimately be resolved there.

----------
components: Extension Modules
messages: 62668
nosy: johansen
severity: normal
status: open
title: dbmmodule inquiry function is performance prohibitive
type: resource usage
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2159>
__________________________________

From report at bugs.python.org  Fri Feb 22 01:47:23 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 22 Feb 2008 00:47:23 -0000
Subject: [issue1110705] list comprehension scope
Message-ID: <1203641243.82.0.87352625104.issue1110705@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

It's already been implemented for Py3.0.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1110705>
_____________________________________

From report at bugs.python.org  Fri Feb 22 01:51:39 2008
From: report at bugs.python.org (Daniel Stutzbach)
Date: Fri, 22 Feb 2008 00:51:39 -0000
Subject: [issue1110705] list comprehension scope
Message-ID: <1203641499.56.0.346721866413.issue1110705@psf.upfronthosting.co.za>


Daniel Stutzbach added the comment:

Wonderful!

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1110705>
_____________________________________

From report at bugs.python.org  Fri Feb 22 02:02:58 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Feb 2008 01:02:58 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203642178.48.0.287035349797.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

> Okay.  I'll stop now :)

So I lied.  In a spirit of enquiry, I implemented math.gcd, and wrote a 
script (lehmer_gcd.py, attached) to produce some relative timings.  Here 
are the results, on my MacBook Pro (OS X 10.5):

An explanation of the table:  I'm computing gcd(a, b) for randomly 
chosen a and b with a_digits and b_digits decimal digits, respectively.   
The times in the 5th and 6th columns are in seconds; the last column 
gives the factor by which math.gcd is faster than the direct Euclidean 
Python implementation.

Even for quite small a and b, math.gcd(a, b) is around 10 times faster 
than its Python counterpart.  For large, roughly equal-sized, a and b, 
the C version runs over 30 times faster.

The smallest difference occurs when the two arguments are very different 
sizes;  then both versions of gcd essentially do one time-consuming 
divmod, followed by a handful of tiny operations, so they take 
essentially the same time.  For Fraction, the arguments will tend to be 
around equal size for many applications:  this assumes that the actual 
real number represented by the Fraction is within a sensible range, even 
when the numerator and denominator have grown huge.

For random a and b, gcd(a, b) tends to be very small.  So for the last 
few entries in the table, the gcds have been artifically inflated (by 
calling gcd(g*a, g*b) for some largish g).

On to the results.

a_digits b_digits g_digits  ntrials   C_Lehmer  Py_Euclid     Factor
-------- -------- --------  -------   --------  ---------     ------
       1        1        0   100000   0.066856   0.240867   3.602780
       2        2        0   100000   0.070256   0.314639   4.478466
       4        4        0   100000   0.075708   0.466596   6.163087
       7        7        0   100000   0.082714   0.681443   8.238537
      10       10        0    10000   0.022336   0.318501  14.259532
      20       20        0    10000   0.045209   0.752662  16.648436
      50       50        0    10000   0.128269   2.167890  16.901128
     100      100        0     1000   0.028053   0.511769  18.242906
    1000     1000        0     1000   0.709453  18.867336  26.594197
   10000    10000        0      100   4.215795 148.597223  35.247736

Lopsided gcds
-------------
      20      100        0      100   0.000889   0.007659   8.616953
     100       20        0      100   0.000887   0.007665   8.642473
    1000        3        0      100   0.000727   0.001387   1.908167
       3     1000        0      100   0.000754   0.001457   1.932027
   10000        1        0      100   0.004689   0.004948   1.055219
       1    10000        0      100   0.004691   0.005038   1.073948
     500      400        0      100   0.020289   0.388080  19.127665
     400      500        0      100   0.020271   0.389301  19.204768

Large gcd
---------
      10       10       10     1000   0.005235   0.043507   8.310880
      20       20       20     1000   0.008505   0.095732  11.256167
     100      100      100     1000   0.041734   0.812656  19.472284

Added file: http://bugs.python.org/file9485/lehmer_gcd.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Fri Feb 22 02:05:12 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 22 Feb 2008 01:05:12 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1203642312.53.0.577754056981.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

And here's the diff for math.gcd.  It's not production quality---it's just 
there to show what's possible.

Added file: http://bugs.python.org/file9486/lehmer_gcd.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Fri Feb 22 02:53:17 2008
From: report at bugs.python.org (Ilya Sandler)
Date: Fri, 22 Feb 2008 01:53:17 -0000
Subject: [issue2059] OptionMenu class is defined both in Tkinter and Tix
In-Reply-To: <1202658940.12.0.289973757596.issue2059@psf.upfronthosting.co.za>
Message-ID: <1203645197.43.0.103807687202.issue2059@psf.upfronthosting.co.za>


Ilya Sandler added the comment:

I understand your argument. Yet, I am not sure classes with the same
name are reasonable here. Tix is too intertwined with Tkinter:

E.g a Tix user user can just access Tkinter widgets via Tix:

>>> import Tix
>>> print Tix.Canvas   # This is TkInter's widget
Tkinter.Canvas

>> import Tix.ComboBox #whoops, we've got Tix's combobox
Tix.ComboBox

As a matter of fact, Tix docs seem to explicitly recommend accessing
Tkinter stuff through Tix:

"""The former imports the latter, so to use Tix with Tkinter, all you
need to do is to import one module. In general, you can just import Tix,
and replace the toplevel call to Tkinter.Tk with Tix.Tk"""

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2059>
__________________________________

From report at bugs.python.org  Fri Feb 22 04:53:04 2008
From: report at bugs.python.org (paul rubin)
Date: Fri, 22 Feb 2008 03:53:04 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203652384.36.0.0344820081237.issue2138@psf.upfronthosting.co.za>


paul rubin added the comment:

I like the idea of having some integer math functions like this in the
stdlib; whether in the math module or elsewhere doesn't matter much.  In
particular I remember having to implement xgcd on several separate
occasions for unrelated applications, each time requiring about the same
head scratching as before, and wishing it was in the stdlib so that
could be avoided.  This type of function is complicated enough to not
rattle immediately off the fingertips, but not complicated enough to be
worth looking up in a reference book.

http://bugs.python.org/issue457066 has some discussion of xgcd and
modular inverses.

----------
nosy: +phr

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Fri Feb 22 05:03:40 2008
From: report at bugs.python.org (paul rubin)
Date: Fri, 22 Feb 2008 04:03:40 -0000
Subject: [issue1742669] "%d" format handling for long values
Message-ID: <1203653020.28.0.0888656019742.issue1742669@psf.upfronthosting.co.za>


paul rubin added the comment:

I would prefer that %d signal an error 100% of the time if you give it a
float.  It should not accept 42.0.  It is for printing integers.

----------
nosy: +phr

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1742669>
_____________________________________

From report at bugs.python.org  Fri Feb 22 05:08:06 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 04:08:06 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203653286.28.0.98692051656.issue1877@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Actually, a very simple change restores python2.5 behavior:

===================================================================
--- Modules/main.c      (revision 60941)
+++ Modules/main.c      (working copy)
@@ -187,6 +187,7 @@
 
        if ((argv0 = PyString_FromString(filename)) && 
            (importer = PyImport_GetImporter(argv0)) &&
+           (importer != Py_None) &&
            (importer->ob_type != &PyNullImporter_Type))
        {
                 /* argv0 is usable as an import source, so

$ ./python.exe .   
./python.exe: '.' is a directory, cannot continue
$ ./python.exe abc
./python.exe: can't open file 'abc': [Errno 2] No such file or directory

I'm not sure, however that PyImport_GetImporter is behaving correctly in 
this case.  (For one, it should INCREF Py_None before returning it.)

I could not find any documentation for PyImport_GetImporter.  Can 
someone enlighten me what Py_None (instead of NULL) return from yImport_GetImporter signifies?

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Fri Feb 22 06:11:18 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 05:11:18 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203657078.16.0.573498542591.issue1877@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I have found relevant documentation in a comment preceding get_path_importer definition:

   ... traverse path_hooks until a hook is found 
   that can handle the path item. Return None if no hook could; 
   this tells our caller it should fall back to the builtin 
   import mechanism.

Therefore, Py_None return is legitimate and should be handled the way I 
suggested in my previous message.  The same comment explains that 
get_path_importer "Returns a borrowed reference," so my criticism of 
return Py_None was misplaced.

I will submit a documentation patch adding PyImport_GetImporter 
documentation.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Fri Feb 22 06:34:57 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 05:34:57 -0000
Subject: [issue2160] Document PyImport_GetImporter
In-Reply-To: <1203658497.27.0.656206451092.issue2160@psf.upfronthosting.co.za>
Message-ID: <1203658497.27.0.656206451092.issue2160@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

See attached patch.

----------
components: Documentation
files: doc-import.diff
messages: 62678
nosy: belopolsky
severity: normal
status: open
title: Document PyImport_GetImporter
versions: Python 2.6
Added file: http://bugs.python.org/file9487/doc-import.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2160>
__________________________________

From report at bugs.python.org  Fri Feb 22 07:37:29 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 06:37:29 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1203662249.84.0.812003500257.issue2051@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky:


Added file: http://bugs.python.org/file9488/issue2051.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Fri Feb 22 07:40:04 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 06:40:04 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1203662404.38.0.94875184042.issue2051@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky:


----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Fri Feb 22 08:26:50 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 07:26:50 -0000
Subject: [issue1481296] long(float('nan'))!=0L
Message-ID: <1203665210.19.0.237402987974.issue1481296@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

FYI: IEEE Standard 754 requires an invalid operation exception when 
inf/nan conversion to integer is attempted.

----------
nosy: +belopolsky

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481296>
_____________________________________

From report at bugs.python.org  Fri Feb 22 09:39:52 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Feb 2008 08:39:52 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203669591.99.0.807437550136.issue1877@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

We don't want to restore Python 2.5 behaviour - directories containing a
__main__.py file are meant to be executable in 2.6. With your proposed
change test_cmd_line_script will fail its directory execution tests
(since those rely on the default importer to find the code for __main__).

Georg is rightly complaining about the way that the implementation
details leak through in the error message when __main__ isn't found. It
makes perfect sense to me, but anyone that isn't intimately familiar
with the import system is going to be left scratching their heads and
wondering what is going on.

I'm currently pondering an approach that involves trapping the
ImportError in _run_module_as_main and displaying different error
messages based on whether or not the module being looked for is called
__main__, and whether or not sys.argv[0] is a directory.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Fri Feb 22 10:03:28 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 22 Feb 2008 09:03:28 -0000
Subject: [issue1742669] "%d" format handling for long values
Message-ID: <1203671008.05.0.324154072855.issue1742669@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc added the comment:

I am of the opposite side:
%d should accept floats and anything that can be converted to an integer.
It is for printing objects with a decimal format.
(likewise %s is for printing objects that can be converted to a string)

----------
nosy: +amaury.forgeotdarc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1742669>
_____________________________________

From report at bugs.python.org  Fri Feb 22 10:55:28 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 22 Feb 2008 09:55:28 -0000
Subject: [issue2160] Document PyImport_GetImporter
In-Reply-To: <1203658497.27.0.656206451092.issue2160@psf.upfronthosting.co.za>
Message-ID: <1203674128.64.0.600157001.issue2160@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks :)

----------
assignee:  -> georg.brandl
keywords: +patch
nosy: +georg.brandl, tiran
priority:  -> low

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2160>
__________________________________

From report at bugs.python.org  Fri Feb 22 12:01:16 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 22 Feb 2008 11:01:16 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203678076.55.0.434745833262.issue1877@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

I've checked in friendlier error messages as r60955

Examples (paths somewhat redacted):

$ ./python bob
./python: can't open file 'bob': [Errno 2] No such file or directory
$ ./python .
/devel/python/python: can't find '__main__.py' in '.'
$ ./python Lib
/devel/python/python: can't find '__main__.py' in 'Lib'
$ ./python -m bob
/devel/python/python: No module named bob
$ ./python -m sys
/devel/python/python: No code object available for sys
$ ./python -m __main__
/devel/python/python: No code object available for __main__

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Fri Feb 22 12:54:31 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 22 Feb 2008 11:54:31 -0000
Subject: [issue1742669] "%d" format handling for long values
Message-ID: <1203681271.14.0.0245582918247.issue1742669@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Paul, %d will accept large floats, I need to review Gabriel's patch;
your proposition will break too much code.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1742669>
_____________________________________

From report at bugs.python.org  Fri Feb 22 14:25:52 2008
From: report at bugs.python.org (=?utf-8?q?Peter_Tr=C3=B6ger?=)
Date: Fri, 22 Feb 2008 13:25:52 -0000
Subject: [issue2161] STORE_LOCAL byte code is not documented
In-Reply-To: <1203686752.82.0.84631726653.issue2161@psf.upfronthosting.co.za>
Message-ID: <1203686752.82.0.84631726653.issue2161@psf.upfronthosting.co.za>


New submission from Peter Tr?ger:

The byte code STORE_LOCAL is referenced in the description of
STORE_NAME, but has no own entry in the list. See here:

http://docs.python.org/lib/bytecodes.html

----------
components: Documentation
messages: 62685
nosy: troeger
severity: minor
status: open
title: STORE_LOCAL byte code is not documented
type: feature request
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2161>
__________________________________

From report at bugs.python.org  Fri Feb 22 15:33:28 2008
From: report at bugs.python.org (Paul Winkler)
Date: Fri, 22 Feb 2008 14:33:28 -0000
Subject: [issue2162] unittest.findTestCases undocumented
Message-ID: <1203690808.72.0.106902212452.issue2162@psf.upfronthosting.co.za>


Changes by Paul Winkler:


----------
components: Documentation
nosy: slinkp
severity: normal
status: open
title: unittest.findTestCases undocumented
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2162>
__________________________________

From report at bugs.python.org  Fri Feb 22 15:35:21 2008
From: report at bugs.python.org (Paul Winkler)
Date: Fri, 22 Feb 2008 14:35:21 -0000
Subject: [issue2162] unittest.findTestCases undocumented
In-Reply-To: <1203690921.5.0.9443371245.issue2162@psf.upfronthosting.co.za>
Message-ID: <1203690921.5.0.9443371245.issue2162@psf.upfronthosting.co.za>


New submission from Paul Winkler:

I cannot find anything about findTestCases on any of the library doc
pages, certainly not at http://docs.python.org/lib/unittest-contents.html
where I'd expect it to be.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2162>
__________________________________

From report at bugs.python.org  Fri Feb 22 15:46:43 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 22 Feb 2008 14:46:43 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203691603.42.0.154628716281.issue1858@psf.upfronthosting.co.za>


Changes by Tarek Ziad?:


Added file: http://bugs.python.org/file9489/distutils.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Fri Feb 22 15:47:30 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 22 Feb 2008 14:47:30 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203691650.0.0.564366225604.issue1858@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

please could you remove the deprecated patch.diff ? thanks :)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Fri Feb 22 16:20:19 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 22 Feb 2008 15:20:19 -0000
Subject: [issue2162] unittest.findTestCases undocumented
In-Reply-To: <1203690921.5.0.9443371245.issue2162@psf.upfronthosting.co.za>
Message-ID: <1203693619.12.0.611138841817.issue2162@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

findTestCases is an obsolete function. From the code:

# Expose obsolete functions for backwards compatibility
__all__.extend(['getTestCaseNames', 'makeSuite', 'findTestCases'])

----------
nosy: +vdupras

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2162>
__________________________________

From report at bugs.python.org  Fri Feb 22 16:30:05 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 22 Feb 2008 15:30:05 -0000
Subject: [issue896199] Some Carbon modules missing
Message-ID: <1203694205.16.0.198286633877.issue896199@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven added the comment:

Is this not solved with the new documentation interface? It groups all 
Carbon modules under a collapsable tree element.

See http://docs.python.org/dev/modindex.html under Carbon

----------
nosy: +asmodai, georg.brandl

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue896199>
____________________________________

From report at bugs.python.org  Fri Feb 22 16:39:08 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 15:39:08 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203694748.87.0.377776925853.issue1877@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Nick,

I understand the __main__.py issue now, but I still don't like your 
approach.  Allowing RunMainFromImporter to call exit and never return 
does not feel right. (A minor problem is that objects on the C stack do 
not get deleted.)  Without a check for Py_None return, the comment 
"argv0 is usable as an import source" is misleading.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Fri Feb 22 16:47:07 2008
From: report at bugs.python.org (ajaksu)
Date: Fri, 22 Feb 2008 15:47:07 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203695227.02.0.118190537374.issue2138@psf.upfronthosting.co.za>


ajaksu added the comment:

Would it be implemented in C? How about using Luschny's Prime Swing
(http://www.luschny.de/math/factorial/FastFactorialFunctions.htm and
http://www.luschny.de/math/factorial/Benchmark.html )?

----------
nosy: +ajaksu2

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Fri Feb 22 16:47:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 22 Feb 2008 15:47:52 -0000
Subject: [issue896199] Some Carbon modules missing
Message-ID: <1203695272.96.0.739712196712.issue896199@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Still, I don't see File, Files or Folders under that heading.

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue896199>
____________________________________

From report at bugs.python.org  Fri Feb 22 18:03:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 22 Feb 2008 17:03:02 -0000
Subject: [issue2163] test_socket is flakey
In-Reply-To: <1203699782.31.0.112043665965.issue2163@psf.upfronthosting.co.za>
Message-ID: <1203699782.31.0.112043665965.issue2163@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

I find that test_socket fails regularly (but not always) when run via
"regrtest.py -uall". The message is always "socket is not connected" but
it's unclear from which test it comes -- all I know is that it comes
from tearDown() on line 123.

(This may be a problem with 2.6 as well -- or not.)

----------
components: Tests
keywords: easy
messages: 62693
nosy: gvanrossum
priority: normal
severity: normal
status: open
title: test_socket is flakey
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2163>
__________________________________

From report at bugs.python.org  Fri Feb 22 18:38:04 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 17:38:04 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203701884.49.0.982489352915.issue1877@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I think a more elegant solution will be possible if issue2135 patch is 
accepted.  I suggest to reopen this issue for Py3k pending resolution of issue2135.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Fri Feb 22 21:22:21 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 22 Feb 2008 20:22:21 -0000
Subject: [issue839159] iterators broken for weak dicts
Message-ID: <1203711741.37.0.105361751097.issue839159@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
title: interators broken for weak dicts -> iterators broken for weak dicts

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue839159>
____________________________________

From report at bugs.python.org  Fri Feb 22 21:27:46 2008
From: report at bugs.python.org (Bill Nottingham)
Date: Fri, 22 Feb 2008 20:27:46 -0000
Subject: [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>
Message-ID: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>


New submission from Bill Nottingham:

SystemError: module dl requires sizeof(int) == sizeof(long) == sizeof(char*)

That's just unspeakably lame. I realize this is longstanding, and it's
even documented, but just... FAIL.

----------
components: Library (Lib)
messages: 62695
nosy: notting
severity: normal
status: open
title: dl broken on non-ILP32 platforms
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Fri Feb 22 21:31:58 2008
From: report at bugs.python.org (Bill Nottingham)
Date: Fri, 22 Feb 2008 20:31:58 -0000
Subject: [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>
Message-ID: <1203712318.6.0.658113538945.issue2164@psf.upfronthosting.co.za>


Bill Nottingham added the comment:

Moreover, eliding the check and subsequent error from the code yields a
module that appears to work in (very) brief testing on x86_64.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Fri Feb 22 21:38:17 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 20:38:17 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203712697.7.0.699382769509.issue2135@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I've noticed that the proposed patch adds const qualifier to many C-API 
functions' arguments.  While at the first glance these changes are 
reasonable, they add clutter to the already massive patch.

I would recommend to separate const qualifier changes into a separate 
patch that can be reviewed separately from the substantive changes.

I promise, I will make substantive comments soon. :-)

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Fri Feb 22 21:47:21 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 20:47:21 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203713241.62.0.468557348329.issue2135@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

The patch breaks test_import on Mac OS 10.4:

$ ./python.exe -E -tt -bb ./Lib/test/regrtest.py test_import
test_import
test test_import failed -- Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 1199, in <module>
    main()
  File "./Lib/test/regrtest.py", line 405, in main
    huntrleaks)
  File "./Lib/test/regrtest.py", line 562, in runtest
    huntrleaks, debug)
  File "./Lib/test/regrtest.py", line 614, in runtest_inner
    print("test", test, "failed --", msg)
  File "/Users/sasha/Work/python-svn/py3k/Lib/io.py", line 1247, in 
write
    b = encoder.encode(s)
  File "/Users/sasha/Work/python-svn/py3k/Lib/encodings/ascii.py", line 
22, in encode
    return codecs.ascii_encode(input, self.errors)[0]
UnicodeEncodeError: 'ascii' codec can't encode characters in position 
211-214: ordinal not in range(128)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Fri Feb 22 21:54:04 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 22 Feb 2008 20:54:04 -0000
Subject: [issue2054] add ftp-tls support to ftplib - RFC 4217
In-Reply-To: <1202523366.93.0.605901116561.issue2054@psf.upfronthosting.co.za>
Message-ID: <1203713644.92.0.218357277754.issue2054@psf.upfronthosting.co.za>


Bill Janssen added the comment:

This is a straightforward implementation of client-side use of SSL, but
it's missing a test case for evaluation.  It should include a patch to
test_ftplib to test it.

Another thing to look at is what the useful arguments are to pass in for
TLS usage over FTP.  If, for example, the client needs to validate the
server's certificate or identity, provision should be made for a file of
cacerts to be passed to the FTP_TLS instance.  Passing in a keyfile and
certfile is usually only necessary when the client uses them to identify
itself to the server.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2054>
__________________________________

From report at bugs.python.org  Fri Feb 22 21:54:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 22 Feb 2008 20:54:31 -0000
Subject: [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>
Message-ID: <1203713670.98.0.325796007127.issue2164@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

The limitation is genuine; it's not possible to implement dl_call
correctly if sizeof(long) != sizeof(void*), say. Otherwise, it would
have been fixed long ago. Use ctypes instead, if that is supported for
your hardware. (More generally, it's not possible to implement this at
all in portable C, that's why ctypes uses assembler code. That dl works
on most "pure" 32-bit systems is by sheer luck)

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Fri Feb 22 22:04:18 2008
From: report at bugs.python.org (Bill Nottingham)
Date: Fri, 22 Feb 2008 21:04:18 -0000
Subject: [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>
Message-ID: <1203714258.01.0.620586081216.issue2164@psf.upfronthosting.co.za>


Bill Nottingham added the comment:

sizeof(long) != sizeof(void *) isn't the epic fail here. It's the
complaint about sizeof(int) != sizeof(long).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Fri Feb 22 22:09:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 22 Feb 2008 21:09:39 -0000
Subject: [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203714258.01.0.620586081216.issue2164@psf.upfronthosting.co.za>
Message-ID: <47BF3A10.80906@v.loewis.de>


Martin v. L?wis added the comment:

> sizeof(long) != sizeof(void *) isn't the epic fail here. It's the
> complaint about sizeof(int) != sizeof(long).

Same story.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Fri Feb 22 22:17:35 2008
From: report at bugs.python.org (Bill Nottingham)
Date: Fri, 22 Feb 2008 21:17:35 -0000
Subject: [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>
Message-ID: <1203715055.68.0.750540176447.issue2164@psf.upfronthosting.co.za>


Bill Nottingham added the comment:

If it's not possible to implement at all, why does it work without the
test?  What specific cases do you think will fail?

Heck, if you don't think it's functional on 90% of hardware sold these
days, just remove it, it makes python look less silly. (Portability is
hard, let's punt.)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Fri Feb 22 22:23:45 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 21:23:45 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203715425.34.0.659519713708.issue2135@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Sorry I have not commented on this sooner; been swamped.

First, the error Alexander is seeing is probably caused by a source file
that has an encoding other than ASCII (which is fine as the default
encoding in Python 3.0 is UTF-8). But chances are the file has an
encoding marker at the top and that is not being picked up by Douglas'
code. Look at PyTokenizer_FindEncoding() for a way to find out the encoding.

Second, I am the wrong person to be reviewing this as I have something
under development that competes with this. =) I am trying to get my pure
Python implementation bootstrapped into Python 3.0 to completely replace
the C code. But I don't know if I will pull this off in time so this
work could still be useful. But if I have to choose time between this
patch and my stuff, I am going to be biased. =)

----------
assignee: brett.cannon -> 

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Fri Feb 22 22:25:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 22 Feb 2008 21:25:33 -0000
Subject: [issue2164] dl broken on non-ILP32 platforms
In-Reply-To: <1203712066.33.0.0443821372492.issue2164@psf.upfronthosting.co.za>
Message-ID: <1203715533.9.0.125617921321.issue2164@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

It fails if the function being called has parameters which are not
sizeof(long), and the platform has a calling convention where such
parameters are passed on the stack, and consume a size different from
sizeof(long) on the stack.

I disagree that it won't run on 90% of the hardware sold today - you
just have to operate that hardware properly to make it work. In any
case, removal of the dl module in favor of ctypes seems reasonable.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2164>
__________________________________

From report at bugs.python.org  Fri Feb 22 22:46:07 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 22 Feb 2008 21:46:07 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203716767.23.0.888741062783.issue2135@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

First, let me state that I like the idea of a uniform approach to 
importing, but given the complexity of the task, Brett's approach (which 
I understand as implementing the builtin importer classes in Python) 
would make sense (as long as he can solve the chicken and egg problem).

This said, here is my first question:

Is there a reason why new importer classes are not subclassable while 
zipimporter is?

>>> class x(imp.BuiltinImporter):pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type 'imp.BuiltinImporter' is not an acceptable base type

>>> class x(imp.DirectoryImporter): pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>

>>> class x(zipimport.zipimporter): pass
... 


Users might want to overload find_module while reusing load_module from 
a built-in importer class.

In fact, I see a great deal of code duplication between the new importer 
classes that can be reduced by deriving from a common base class.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Sat Feb 23 00:20:59 2008
From: report at bugs.python.org (Anders Valind)
Date: Fri, 22 Feb 2008 23:20:59 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203722459.68.0.628923975147.issue2138@psf.upfronthosting.co.za>


Anders Valind added the comment:

IMHO, The best place to put functions such as xgcd, factorial, etc,
would be a new imath module, an integer equivalent of cmath.

Not only would it keep the standard math module clean, it would also
make clear that these functions are for integers only.

----------
nosy: +avalind

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Sat Feb 23 00:36:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:36:26 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723386.15.0.168978832239.issue1631171@psf.upfronthosting.co.za>


Brett Cannon added the comment:

Patch that has been brought up-to-date with r60968. No new work, though.

Added file: http://bugs.python.org/file9490/c_warnings.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:36:34 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:36:34 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723394.17.0.93739328908.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file7708/c-warnings.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:30 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723450.4.0.386173249328.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file7709/_warnings.c

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:33 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:33 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723453.42.0.760329982292.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8495/_warnings.c

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:36 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723456.75.0.179617337136.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8496/c_warnings.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:39 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723459.79.0.681092041338.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8557/_warnings.c

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:43 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:43 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723463.94.0.797225800176.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8565/_warnings.c

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:47 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:47 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723467.02.0.885777907849.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8772/test_warnings.py

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:51 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:51 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723471.06.0.814091833255.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8783/warnings.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 00:37:54 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 22 Feb 2008 23:37:54 -0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1203723474.2.0.157216236033.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon:


Removed file: http://bugs.python.org/file8858/_warnings.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sat Feb 23 01:41:39 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 00:41:39 -0000
Subject: [issue1089358] need siginterrupt() on Linux - impossible to do
	timeouts
Message-ID: <1203727299.08.0.529451669554.issue1089358@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

I've attached a new patch against current trunk, which now also contains
unit tests.

----------
type:  -> feature request
versions:  -Python 2.5
Added file: http://bugs.python.org/file9491/siginterrupt+tests.txt

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1089358>
_____________________________________

From report at bugs.python.org  Sat Feb 23 02:21:34 2008
From: report at bugs.python.org (Douglas Greiman)
Date: Sat, 23 Feb 2008 01:21:34 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203729694.93.0.74416273582.issue2135@psf.upfronthosting.co.za>


Douglas Greiman added the comment:

Brett,

I wrote my patch thinking that the next step would be to rewrite
DirectoryImporter in Python.  If you're already working on that and
just want to skip straight from point A to point C and skip this point
B, I'm fine with that.  Basically, tell me if you want me to pursue
this further or drop it.  Are you also reimplementing the code for
builtin and frozen modules in Python?

Alexander,

The const thing: I went on a bit of a const rampage after an
especially irritating debugging session involving function side
effects.  They could be removed.

The non-subclassable aspect was an oversight.  I thought about having
a common base class but ended up creating the ModuleInfo helper class
instead.  There's still a few bits of code duplication between the two
importer classes.  16x2 lines in  *_find_module() could be pulled into
a common place, 4x2 lines of *_require_module(), and a few lines in
the various methods.  I wanted to err on the side of introducing as
few new classes as possible to minimize the general scariness of this
patch.

I don't have a Mac setup, but I think the error you're seeing is
actually an error in my test code.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Sat Feb 23 02:25:34 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Feb 2008 01:25:34 -0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1203729934.9.0.825472755507.issue1540617@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

issue1546078 presents a much more ambitious patch - supporting arbitrary 
longs in range.  It looks like that patch was applied to py3k branch 
where performance issues are not yet a concern.

Unless there are plans to backport 1546078, I would like to see this 
patch  make it in 2.6.  (On 64-bit platforms, it is probably as good as 
supporting arbitrary longs and thus will make 2.6 closer to 3.0.)

The patch is still valid for the trunk.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540617>
_____________________________________

From report at bugs.python.org  Sat Feb 23 02:29:19 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Feb 2008 01:29:19 -0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1203730158.99.0.336090010363.issue1540617@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, the current Py2.6 code for enumerate() and itertools.count() both
show how to support arbitrary longs without killing the performance of
common cases.

----------
nosy: +rhettinger

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540617>
_____________________________________

From report at bugs.python.org  Sat Feb 23 02:35:40 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 01:35:40 -0000
Subject: [issue1957] [patch] syslogmodule: Release GIL when calling syslog(3)
In-Reply-To: <1201534314.07.0.339732897675.issue1957@psf.upfronthosting.co.za>
Message-ID: <1203730540.97.0.950757413355.issue1957@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +easy

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1957>
__________________________________

From report at bugs.python.org  Sat Feb 23 03:12:34 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Feb 2008 02:12:34 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203732754.6.0.469239039403.issue1877@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

If main.c doesn't handle sys.exit() correctly for code run via
RunMainFromImporter, then that's a problem with the main function - it
will happen regardless of whether it is runpy.py or application code
that calls sys.exit. But as far as I can tell, it handles it just fine -
the SystemExit exception is converted to an error return from
PyObject_Call, which then flows back up the C stack as an error return
from each relevant function call in main.c (until it gets back to the
shell with a non-zero return code from the main function).

And I don't understand your complaint about the Py_None return
conflicting with the comment on that if statement: PyImport_GetImporter
will return Py_None for a directory name, as directories are handled by
the builtin machinery. If PyImport_GetImporter fails completely it will
return NULL - if the function returns anything else, then PyImport
thinks the passed in string is a legitimate sys.path entry (i.e. usable
as an import source).

The *only* difference issue3125 (or Brett's import_in_py branch) would
make to any of this is that PyImport_GetImporter won't return Py_None
anymore. In either case, the additional try/except in runpy would still
be necessary in order to intercept the ImportError when looking for the
module to be executed and convert it to something a bit more explicit.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Sat Feb 23 03:16:25 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 23 Feb 2008 02:16:25 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203729694.93.0.74416273582.issue2135@psf.upfronthosting.co.za>
Message-ID: <bbaeab100802221816s21d29c2eh4cd51517f3e32c45@mail.gmail.com>


Brett Cannon added the comment:

On Fri, Feb 22, 2008 at 5:21 PM, Douglas Greiman <report at bugs.python.org> wrote:
>
>  Douglas Greiman added the comment:
>
>  Brett,
>
>  I wrote my patch thinking that the next step would be to rewrite
>  DirectoryImporter in Python.  If you're already working on that and
>  just want to skip straight from point A to point C and skip this point
>  B, I'm fine with that.  Basically, tell me if you want me to pursue
>  this further or drop it.

You can drop it if you want, but I just don't know how long it will
take for me to finish the bootstrap work (for instance I am having to
rewrite the warnings module in C). So there is a chance it might still
be useful, but I can't guarantee it.

>  Are you also reimplementing the code for
>  builtin and frozen modules in Python?
>

I use the imp module to handle the actual loading, but the importers
and loaders are all in Python. You can see the implementation in the
sandbox under import_in_py.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Sat Feb 23 03:23:00 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Feb 2008 02:23:00 -0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1203733380.84.0.535272464127.issue1540617@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Yes, index/longindex optimization is nice and can be applied to xrange.  
However, I don't think python-dev will be happy with the 1546078-style 
changes going to 2.6 and optimization patches are probably premature for 
3.0.

The ssize_t approach has a nice property of not affecting 32-bit 
platforms where objects with offsets >2**31 cannot exist and will 
satisfy most of the needs on 64-bit platforms.

I cannot think of a use case for xrange output that cannot be used as 
index.  On the other hand, such functionality would be trivial to 
implement if needed by an application:

def range(start, stop, step): 
    i = start 
    while i < stop: 
        yield i 
        i += step


Maybe you could mark this issue as "easy" and see if the patch can be 
reviewed in one of the bugs days?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540617>
_____________________________________

From report at bugs.python.org  Sat Feb 23 03:23:51 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Feb 2008 02:23:51 -0000
Subject: [issue2135] Restructure import.c into PEP 302 importer objects
In-Reply-To: <1203289879.4.0.29225339307.issue2135@psf.upfronthosting.co.za>
Message-ID: <1203733431.46.0.590849882378.issue2135@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Interesting - I'll try to find the time to take a look at this. (I also
added PJE to the nosy list - hopefully he will get a chance to look at it)

----------
nosy: +ncoghlan, pje

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Sat Feb 23 04:07:28 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Feb 2008 03:07:28 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203736048.31.0.626157991813.issue1877@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Nick, you are right about sys.exit().  I did to much C programming 
lately and forgot that sys.exit() does not exit. :-)

I understood your comment as saying that 'importer' points to a valid 
importer.  Now I understand that with the present state of the code, 
that would only be the case when running a zip file.  Now it all makes 
sense.

I still wonder if the case of a bona fide importer could be handled 
without a sys.path mutating trick by simply calling importer-
>find_module.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Sat Feb 23 06:49:08 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Feb 2008 05:49:08 -0000
Subject: [issue1877] unhelpful error when calling "python <dirname>"
In-Reply-To: <1200840488.22.0.553950533734.issue1877@psf.upfronthosting.co.za>
Message-ID: <1203745748.59.0.68584601973.issue1877@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The mutation of sys.path is deliberate - the use case is to allow the
interpreter to execute a zipfile directly and have access to all of the
Python modules and packages bundled along with __main__.py. Supporting
execution of directories as well makes it much easier to test your
application before bundling it that way (since you can test with the
directory till it works, zip the directory, test with the zipfile, then
distribute it).

You can find more details on this feature in issue 1739468

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1877>
__________________________________

From report at bugs.python.org  Sat Feb 23 06:54:24 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Feb 2008 05:54:24 -0000
Subject: [issue1739468] Allow interpreter to execute a zip file
Message-ID: <1203746064.46.0.555044757357.issue1739468@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Updated issue title to reflect what was actually implemented

----------
title: Add a -z interpreter flag to execute a zip file -> Allow interpreter to execute a zip file

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739468>
_____________________________________

From report at bugs.python.org  Sat Feb 23 06:56:24 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 23 Feb 2008 05:56:24 -0000
Subject: [issue1739468] Allow interpreter to execute a zip file
Message-ID: <1203746184.88.0.0892530229014.issue1739468@psf.upfronthosting.co.za>


Changes by Nick Coghlan:


Removed file: http://bugs.python.org/file8767/runmain_with_tests.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1739468>
_____________________________________

From report at bugs.python.org  Sat Feb 23 13:03:19 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 12:03:19 -0000
Subject: [issue1881] increase parser stack limit
In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za>
Message-ID: <1203768199.57.0.65439081435.issue1881@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r60974.

Maciek, please push that alternative way of handling this limit on
python-dev, that could lead to a better handling in the future.

But, so far, we have a limit a little upper, and tested.

Thank you all!

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1881>
__________________________________

From report at bugs.python.org  Sat Feb 23 13:28:35 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 12:28:35 -0000
Subject: [issue1776581] Minor corrections to smtplib
Message-ID: <1203769715.18.0.146271450675.issue1776581@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r60975. Thanks!

----------
resolution:  -> accepted
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1776581>
_____________________________________

From report at bugs.python.org  Sat Feb 23 13:29:21 2008
From: report at bugs.python.org (Manuel Kaufmann)
Date: Sat, 23 Feb 2008 12:29:21 -0000
Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate
	sections.
In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za>
Message-ID: <1203769761.05.0.728167763517.issue1781@psf.upfronthosting.co.za>


Manuel Kaufmann added the comment:

I tested the patch and works very well. I modified "Misc/NEWS" file 
beacuse the change wasn't reported and I uploaded diff file 
(NEWS.diff).

----------
nosy: +humitos
Added file: http://bugs.python.org/file9492/NEWS.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1781>
__________________________________

From report at bugs.python.org  Sat Feb 23 13:33:00 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 12:33:00 -0000
Subject: [issue1964] Slight adjustment to sphinx print-media stylesheet
In-Reply-To: <1201623353.06.0.378481748773.issue1964@psf.upfronthosting.co.za>
Message-ID: <1203769980.12.0.730553330903.issue1964@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thank you for the patch, applied in my sandbox (will be part of a larger
commit).

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1964>
__________________________________

From report at bugs.python.org  Sat Feb 23 13:47:04 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 12:47:04 -0000
Subject: [issue1781] ConfigParser: add_section('DEFAULT') causes duplicate
	sections.
In-Reply-To: <1199932970.3.0.196882211496.issue1781@psf.upfronthosting.co.za>
Message-ID: <1203770824.87.0.501348203414.issue1781@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r60976. Thank you all!

----------
nosy: +facundobatista
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1781>
__________________________________

From report at bugs.python.org  Sat Feb 23 14:05:53 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 13:05:53 -0000
Subject: [issue2130] [feature-request] Please add bool data type to "optparse"
	module
In-Reply-To: <1203196509.43.0.43785480253.issue2130@psf.upfronthosting.co.za>
Message-ID: <1203771953.23.0.427611032481.issue2130@psf.upfronthosting.co.za>


Facundo Batista added the comment:

The functionality already exists.

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2130>
__________________________________

From report at bugs.python.org  Sat Feb 23 14:19:01 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 13:19:01 -0000
Subject: [issue1881] increase parser stack limit
In-Reply-To: <1200910200.4.0.263780929167.issue1881@psf.upfronthosting.co.za>
Message-ID: <1203772741.95.0.175142769561.issue1881@psf.upfronthosting.co.za>


Christian Heimes added the comment:

For the record:
I had to decrease the level to 93. The test in test_parser didn't pass
with 99 levels.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1881>
__________________________________

From report at bugs.python.org  Sat Feb 23 14:23:16 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 13:23:16 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203772996.33.0.712412708681.issue1858@psf.upfronthosting.co.za>


Changes by Facundo Batista:


Removed file: http://bugs.python.org/file9191/patch.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Sat Feb 23 14:47:51 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sat, 23 Feb 2008 13:47:51 -0000
Subject: [issue2165] Fix for test_logging
In-Reply-To: <1203774471.36.0.964101326063.issue2165@psf.upfronthosting.co.za>
Message-ID: <1203774471.36.0.964101326063.issue2165@psf.upfronthosting.co.za>


New submission from Thomas Herve:

The attached patch fixes the test_logging failure on my machine. Please
review.

----------
components: Tests
files: test_logging.diff
messages: 62727
nosy: therve
severity: normal
status: open
title: Fix for test_logging
versions: Python 2.6
Added file: http://bugs.python.org/file9493/test_logging.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2165>
__________________________________

From report at bugs.python.org  Sat Feb 23 14:51:32 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 13:51:32 -0000
Subject: [issue1531505] distutils 'register' command and windows home
	directories
Message-ID: <1203774692.93.0.283766511471.issue1531505@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

The patch of #1858 fixes this issue as well

----------
nosy: +tarek

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1531505>
_____________________________________

From report at bugs.python.org  Sat Feb 23 14:58:28 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 23 Feb 2008 13:58:28 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203775108.39.0.920878467417.issue2138@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

The trouble is that this comes at a time when people are trying to trim 
the standard library down rather than enlarge it.

Perhaps the solution is a high-quality third party 'imath' module?  
If/when it gets to a stage where lots of people are using it, it could 
be considered for inclusion in the std. lib.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:09:25 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 14:09:25 -0000
Subject: [issue1741] .pypirc not found on windows
In-Reply-To: <1199616321.65.0.452980154178.issue1741@psf.upfronthosting.co.za>
Message-ID: <1203775765.21.0.501933053922.issue1741@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

Fixed by #1858 patch

----------
nosy: +tarek

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1741>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:17:05 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 14:17:05 -0000
Subject: [issue2166] pydistutils.cfg won't be found on Windows
In-Reply-To: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za>
Message-ID: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za>


New submission from Tarek Ziad?:

Related to #1741: dist.py looks for the HOME environment variable
to try to find the user's pydistutils.cfg. 

user_file = os.path.join(os.environ.get('HOME'), user_filename)

It should look form HOMEDRIVE+HOMEPATH as well.

----------
messages: 62731
nosy: tarek
severity: normal
status: open
title: pydistutils.cfg won't be found on Windows
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2166>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:17:09 2008
From: report at bugs.python.org (Bruno Gola)
Date: Sat, 23 Feb 2008 14:17:09 -0000
Subject: [issue2101] xml.dom documentation doesn't match implementation
In-Reply-To: <1202913434.5.0.501643425154.issue2101@psf.upfronthosting.co.za>
Message-ID: <1203776229.89.0.846183043139.issue2101@psf.upfronthosting.co.za>


Bruno Gola added the comment:

This seems to be a documentation bug. Patch attached.

----------
nosy: +brunogola
Added file: http://bugs.python.org/file9494/issue_2101_doc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2101>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:22:10 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 14:22:10 -0000
Subject: [issue2166] pydistutils.cfg won't be found on Windows
In-Reply-To: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za>
Message-ID: <1203776530.2.0.396461887463.issue2166@psf.upfronthosting.co.za>


Changes by Tarek Ziad?:


----------
components: +Distutils
versions: +Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2166>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:31:08 2008
From: report at bugs.python.org (ajaksu)
Date: Sat, 23 Feb 2008 14:31:08 -0000
Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages
In-Reply-To: <1195823047.2.0.185836867459.issue1492@psf.upfronthosting.co.za>
Message-ID: <1203777068.12.0.889283245213.issue1492@psf.upfronthosting.co.za>


ajaksu added the comment:

Here's my attempted patch against trunk. The doc is poor (but what else
should it contain?)  and the attribute name could be better. 

I'm worried about lack of testing for this change as the module has
virtually no tests. Should we start adding naive (regarding buildbots)
tests?

----------
nosy: +ajaksu2
Added file: http://bugs.python.org/file9495/BaseHTTP_error_content_type.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:31:22 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Sat, 23 Feb 2008 14:31:22 -0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1203777082.86.0.0917684633345.issue2118@psf.upfronthosting.co.za>


Changes by Rafael Zanella:


----------
nosy: +zanella

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:38:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 14:38:53 -0000
Subject: [issue1759] Backport of PEP 3129 "class decorators"
In-Reply-To: <1199763869.09.0.792337356327.issue1759@psf.upfronthosting.co.za>
Message-ID: <1203777533.61.0.724114021386.issue1759@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Attaching new diff that fixes these issues.

----------
nosy: +georg.brandl
Added file: http://bugs.python.org/file9496/classdec_2.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759>
__________________________________

From report at bugs.python.org  Sat Feb 23 15:57:43 2008
From: report at bugs.python.org (rbp)
Date: Sat, 23 Feb 2008 14:57:43 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203778663.25.0.305914319696.issue2149@psf.upfronthosting.co.za>


rbp added the comment:

For what it's worth, I do think this is an issue. As it currently
stands, not only does the module silently accept invalid values, but the
mutex issue exists (and is also silently ignored) if an object returning
dynamic values is passed as maxsize. IMHO, the waters are already muddy,
it's just that the mud is blue so everything seems alright :)

I think zanella's patch is the way to go, even if it requires adding a
setter method.

----------
nosy: +rbp

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:02:24 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 15:02:24 -0000
Subject: [issue1759] Backport of PEP 3129 "class decorators"
In-Reply-To: <1199763869.09.0.792337356327.issue1759@psf.upfronthosting.co.za>
Message-ID: <1203778944.3.0.0146528288285.issue1759@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Applied in r60978

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:02:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 15:02:44 -0000
Subject: [issue1492] BaseHTTPServer hard-codes Content-Type for error messages
In-Reply-To: <1195823047.2.0.185836867459.issue1492@psf.upfronthosting.co.za>
Message-ID: <1203778963.96.0.955642772497.issue1492@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Reviewed and committed in r60980. Thanks!

----------
assignee:  -> georg.brandl
nosy: +georg.brandl
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1492>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:07:00 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 15:07:00 -0000
Subject: [issue2165] Fix for test_logging
In-Reply-To: <1203774471.36.0.964101326063.issue2165@psf.upfronthosting.co.za>
Message-ID: <1203779220.32.0.302090237593.issue2165@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Committed r60982.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2165>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:09:13 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 15:09:13 -0000
Subject: [issue1089358] need siginterrupt() on Linux - impossible to do
	timeouts
Message-ID: <1203779353.09.0.795783661888.issue1089358@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r60983. Thank you all!

----------
nosy: +facundobatista
resolution:  -> accepted
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1089358>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:11:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 15:11:25 -0000
Subject: [issue2067] file.__exit__ does not call subclass' close method
In-Reply-To: <1202742715.17.0.365952775258.issue2067@psf.upfronthosting.co.za>
Message-ID: <1203779485.56.0.339514406838.issue2067@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Committed r60984.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2067>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:13:09 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 23 Feb 2008 15:13:09 -0000
Subject: [issue2161] STORE_LOCAL byte code is not documented
In-Reply-To: <1203686752.82.0.84631726653.issue2161@psf.upfronthosting.co.za>
Message-ID: <1203779589.48.0.794364000844.issue2161@psf.upfronthosting.co.za>


Guilherme Polo added the comment:

I believe it should say "STORE_FAST or STORE_GLOBAL" instead.

----------
nosy: +gpolo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2161>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:14:32 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 15:14:32 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203779672.0.0.813536289647.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

I'm attaching a test script (test_times.py) that forks a child which
runs for 5 seconds, waits for the child, then prints the time taken by
the child according to os.times().

I have a machine where os.times() reproducably reports that 8.33 seconds
have been spent, although indeed only 5 seconds pass:

======================================
# time python test_times.py
8.33333333333

real    0m5.018s
user    0m5.008s
sys     0m0.008s
======================================

I don't know which characteristics of the machine are causing this.

----------
nosy: +maltehelmert
Added file: http://bugs.python.org/file9497/test_times.py

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:15:50 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 15:15:50 -0000
Subject: [issue2166] pydistutils.cfg won't be found on Windows
In-Reply-To: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za>
Message-ID: <1203779750.74.0.0799064157736.issue2166@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Please use os.path.expanduser(os.path.join("~", user_filename))

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2166>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:16:14 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 15:16:14 -0000
Subject: [issue2067] file.__exit__ does not call subclass' close method
In-Reply-To: <1202742715.17.0.365952775258.issue2067@psf.upfronthosting.co.za>
Message-ID: <1203779774.34.0.134022414129.issue2067@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

Isn't this a candidate for backporting to 2.5?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2067>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:19:37 2008
From: report at bugs.python.org (Pavel Vinogradov)
Date: Sat, 23 Feb 2008 15:19:37 -0000
Subject: [issue1949] test_ntpath.py converted to unittest
In-Reply-To: <1201472386.07.0.26140471271.issue1949@psf.upfronthosting.co.za>
Message-ID: <1203779977.0.0.892555765434.issue1949@psf.upfronthosting.co.za>


Pavel Vinogradov added the comment:

This patch also looks good for me. It convert all test cases and run
successfully on latest python trunk (on Linux).

----------
nosy: +pavel.vinogradov

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1949>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:22:18 2008
From: report at bugs.python.org (Wummel)
Date: Sat, 23 Feb 2008 15:22:18 -0000
Subject: [issue2167] Remove unused imports
In-Reply-To: <1203780138.17.0.0226690463591.issue2167@psf.upfronthosting.co.za>
Message-ID: <1203780138.17.0.0226690463591.issue2167@psf.upfronthosting.co.za>


New submission from Wummel:

I ran the pyflakes checker over the Python source repository and removed
some unused imports. Only obvious (from what I can see) unused imports
were removed, with most offenders being "import os, sys, string".
The diff is against current SVN (I am using git-svn, hence the --git diff).

----------
files: python-remove-unused-imports.diff
messages: 62746
nosy: calvin
severity: normal
status: open
title: Remove unused imports
Added file: http://bugs.python.org/file9498/python-remove-unused-imports.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2167>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:23:14 2008
From: report at bugs.python.org (Pedro Werneck)
Date: Sat, 23 Feb 2008 15:23:14 -0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1203780194.93.0.402947360784.issue2118@psf.upfronthosting.co.za>


Pedro Werneck added the comment:

It seems the right thing to do would be to have it raise a base
exception, but SMTPConnectError docstring states "Error during
connection establishment.", so I chosen to use it with the errno and
message from socket.error, even if it's supposed to happen only after
connection is already stablished, since it's a subclass of
SMTPResponseException.

As a bonus I removed a explicit raise socket.error from line 290, when
an user pass a non-integer port.

----------
nosy: +werneck
Added file: http://bugs.python.org/file9499/issue_2118_smtplib.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:26:00 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 15:26:00 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203780360.61.0.881287699687.issue1040026@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Well, 8.3333/5 equals 100/60. Go figure.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:26:07 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sat, 23 Feb 2008 15:26:07 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>


New submission from Thomas Herve:

A recent change in shelve (r60927) raises the need for gdbm objects to
be iterable. We can see it by running test_shelve on a machine with
gdbm. I'll try to fix this.

The same thing should be done with the dbm module I think.

----------
components: Library (Lib)
messages: 62749
nosy: therve
severity: normal
status: open
title: gdbm needs to be iterable
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:30:17 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 23 Feb 2008 15:30:17 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203780617.29.0.580207277631.issue1040026@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

test_times.py produces the correct value on Linux for me, but I see the
same bogus value as Malte on OSX.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:34:01 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 15:34:01 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203780841.95.0.480767752655.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Here's three tests with different pythons on the same machine:
# ./python ../test_times.py
8.33333333333
# python ../test_times.py
8.33333333333
# python2.5 ../test_times.py
5.0

The first Python is current trunk, built just now.
The second Python is the vendor-installed (SuSE) Python 2.5.
The third Python is a Python 2.5 I installed manually from source some
time ago. Strange that it would differ from the second; it appears to be
the same revision as the second from the greeting message.

Anyway, I can reproduce the error in the trunk, which is good.
This is a 64-bit SuSE Linux machine (Xeon X5355 @ 2.66GHz).

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:36:44 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 15:36:44 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203781004.53.0.102259535417.issue1858@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

The last patch also fixes the HOME issues under Windows: #1531505,
#1741, #2166 where .pypirc and .pydistutils.cfg were not found. It is
not using os.path.expanduser to simplify the code usage (~\/ is rather
unreadable) (see the get_home() function in util.py)

Added file: http://bugs.python.org/file9500/bugday-distutils.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:42:29 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 15:42:29 -0000
Subject: [issue2072] SimpleXMLRPCServer documentation about rpc_paths might be
	wrong
In-Reply-To: <1202756969.25.0.603492596378.issue2072@psf.upfronthosting.co.za>
Message-ID: <1203781349.6.0.115569194735.issue2072@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Thanks for pointing out this error.  Corrected in rev. 60987.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2072>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:44:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 15:44:02 -0000
Subject: [issue2161] STORE_LOCAL byte code is not documented
In-Reply-To: <1203686752.82.0.84631726653.issue2161@psf.upfronthosting.co.za>
Message-ID: <1203781442.62.0.619660202952.issue2161@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Indeed. Fixed in r60988.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2161>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:49:55 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 15:49:55 -0000
Subject: [issue1119331] curses.initscr - initscr exit w/o env(TERM) set
Message-ID: <1203781795.29.0.165158063508.issue1119331@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Patch #2 applied to 2.6-trunk in rev. 60989.

----------
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1119331>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:55:27 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 15:55:27 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203782127.62.0.918622553655.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

I'm attaching a patch against trunk that fixes the problem for me
(os_times.PATCH).

This uses the sysconf values when HAVE_SYSCONF is defined, and otherwise
falls back on the old behaviour (use HZ if that is defined, 60 
otherwise).

I'm not sure if this is stylistically ok (#ifdefs inside a function,
etc.), so I'd appreciate comments.

Should I add a test case for the test suite?

Added file: http://bugs.python.org/file9501/os_times.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:55:41 2008
From: report at bugs.python.org (Lauro Moura)
Date: Sat, 23 Feb 2008 15:55:41 -0000
Subject: [issue1911] webbrowser.open firefox 3 issues
In-Reply-To: <1201051771.85.0.184797349871.issue1911@psf.upfronthosting.co.za>
Message-ID: <1203782141.69.0.744904444913.issue1911@psf.upfronthosting.co.za>


Lauro Moura added the comment:

Adding patch with backport from trunk to branches/release25-maint.
Tested with firefox(2 and 3a3), epiphany and elinks on GNOME 2.20,
altough I coulnd't reproduce the error before from python, even changing
the gconf setting manually.

----------
nosy: +lauromoura
Added file: http://bugs.python.org/file9502/webbrowser-nogconf-backport.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1911>
__________________________________

From report at bugs.python.org  Sat Feb 23 16:58:29 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 15:58:29 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203782309.86.0.503834517552.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Another comment: Since the fallback value of 60 was wrong in the past,
it may likely be wrong in the future. Should that fallback be removed
and replaced by a compile-time error? And is the "HZ" fallback necessary
at all? I don't know enough about Posix to know whether or not
HAVE_SYSCONF should be implied by HAVE_TIMES.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 16:59:34 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 15:59:34 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203782374.6.0.751682974791.issue1858@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

I have changed the patch so it uses expanduser (took back tiran's
example from #2166)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Sat Feb 23 17:00:05 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 16:00:05 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203782405.12.0.832103474641.issue1858@psf.upfronthosting.co.za>


Changes by Tarek Ziad?:


Added file: http://bugs.python.org/file9503/bugday.distutils.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Sat Feb 23 17:04:18 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sat, 23 Feb 2008 16:04:18 -0000
Subject: [issue2166] pydistutils.cfg won't be found on Windows
In-Reply-To: <1203776225.5.0.753260751144.issue2166@psf.upfronthosting.co.za>
Message-ID: <1203782658.89.0.659764717305.issue2166@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

ok, done in #1858

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2166>
__________________________________

From report at bugs.python.org  Sat Feb 23 17:06:40 2008
From: report at bugs.python.org (Anders Valind)
Date: Sat, 23 Feb 2008 16:06:40 -0000
Subject: [issue2138] Factorial
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1203782800.37.0.202619241653.issue2138@psf.upfronthosting.co.za>


Anders Valind added the comment:

Yeah, I like the idea of a third party module and letting the popularity 
and quality decide when/if it will be included.

This would also make it easier to see what kind of functionality people 
would want.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2138>
__________________________________

From report at bugs.python.org  Sat Feb 23 17:12:37 2008
From: report at bugs.python.org (ajaksu)
Date: Sat, 23 Feb 2008 16:12:37 -0000
Subject: [issue1597000] Use \r\n, not \n for HTTP headers
Message-ID: <1203783157.89.0.293086470031.issue1597000@psf.upfronthosting.co.za>


ajaksu added the comment:

he specific issue mentioned might arise from UAs interpreting the
snippet as a header, but the whole thing is so oblivious to standards
that it doesn't matter: 

 def reset():
    """Return a string that resets the CGI and browser to a known state."""
    return '''<!--: spam
Content-Type: text/html

<body bgcolor="#f0f0f8"><font color="#f0f0f8" size="-5"> -->
<body bgcolor="#f0f0f8"><font color="#f0f0f8" size="-5"> --> -->
</font> </font> </font> </script> </object> </blockquote> </pre>
</table> </table> </table> </table> </table> </font> </font> </font>'''


In a search over the stdlib, there are many hits for, e.g., "print
'Content-Type:','X'", but most (if not all) of these are printing to
stdout and also sending the headers correctly terminated over the network.

Other instances are due to local handling of files (like in
urllib2.FTPHandler.ftp_open), and in these we could change the explicit
"\n" to "\r\n", but there would be no gain IMHO.

I suggest closing this bug (at least until concrete examples of sending
non-CRLF terminated headers are provided).

----------
nosy: +ajaksu2

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1597000>
_____________________________________

From report at bugs.python.org  Sat Feb 23 17:13:22 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 16:13:22 -0000
Subject: [issue1330538] datetime/xmlrpclib.DateTime comparison
Message-ID: <1203783202.94.0.700297818087.issue1330538@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The patch looks OK.

The python-dev discussion starts at 
http://mail.python.org/pipermail/python-dev/2005-October/057514.html.

I'm nervous about removing the ability to pass a date or time to
the constructor, but the consensus was that this conversion was a bad
idea, so I'll apply the patch as-is, and update the docs.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1330538>
_____________________________________

From report at bugs.python.org  Sat Feb 23 17:22:36 2008
From: report at bugs.python.org (Pavel Vinogradov)
Date: Sat, 23 Feb 2008 16:22:36 -0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1203783756.9.0.333718961873.issue1322@psf.upfronthosting.co.za>


Pavel Vinogradov added the comment:

I'm work on this issue in
GHOP(http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216&can=1&colspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summary)
I'm attach updated patch for python trunk. This patch fixes issue and
add additional test for some other Linux distributions.

----------
nosy: +pavel.vinogradov
Added file: http://bugs.python.org/file9504/test_platform_py26.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
__________________________________

From report at bugs.python.org  Sat Feb 23 17:23:37 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 16:23:37 -0000
Subject: [issue1330538] datetime/xmlrpclib.DateTime comparison
Message-ID: <1203783817.8.0.205285187188.issue1330538@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Committed to 2.6 trunk in rev. 60991.

----------
resolution:  -> accepted
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1330538>
_____________________________________

From report at bugs.python.org  Sat Feb 23 17:26:11 2008
From: report at bugs.python.org (Manuel Kaufmann)
Date: Sat, 23 Feb 2008 16:26:11 -0000
Subject: [issue1746071] class mutex doesn't do anything atomically
Message-ID: <1203783971.78.0.476209223847.issue1746071@psf.upfronthosting.co.za>


Manuel Kaufmann added the comment:

I tested the patch and I found an error. It was missing a line "if 
call:" in the unlock function. I added it, and tested again with the 
ex.py example and it didn't found any threads locked at the same time.

----------
nosy: +humitos
Added file: http://bugs.python.org/file9505/mutex.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746071>
_____________________________________

From report at bugs.python.org  Sat Feb 23 17:26:15 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 16:26:15 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203783975.25.0.113268201004.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Here is a patch that adds a test case to test_posix.py. This is ignored
on Windows, as it requires fork.

There is a trade-off: If WAIT_TIME isn't large enough, small
irregularities in the process scheduler might cause this to fail. If it
is too large, the unit tests will take long for everyone.

Currently, WAIT_TIME is 0.1 seconds and the tolerance in the assertion
is about 5%, which works well for me. Not sure how this behaves on very
busy machines.

Added file: http://bugs.python.org/file9506/test_posix.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 17:28:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Feb 2008 16:28:09 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203784089.52.0.863031451102.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Many places in the stdlib accept values which are not valid. I believe
this is because the library trusts you to do the right thing in the name
of performance and cleaner, simpler code. IMO, adding a set_maxsize
method wouldn't be a sin, but Raymond (who is I'm sure wiser than me)
disagrees.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Sat Feb 23 17:35:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Feb 2008 16:35:42 -0000
Subject: [issue1746071] class mutex doesn't do anything atomically
Message-ID: <1203784542.63.0.35035666.issue1746071@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Is this module still of any use to anyone? It seems if you wanted a fake
mutex, you could just import LockType from dummy_thread.

----------
nosy: +benjamin.peterson

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746071>
_____________________________________

From report at bugs.python.org  Sat Feb 23 17:40:17 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 16:40:17 -0000
Subject: [issue835521] More obvious indication of __reduce__ documentation.
Message-ID: <1203784817.82.0.795583497463.issue835521@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Thanks for the suggestion. I've added index entries for __reduce__,
as well as __reduce_ex__ and a few others in rev. 60994

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue835521>
____________________________________

From report at bugs.python.org  Sat Feb 23 17:40:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 23 Feb 2008 16:40:41 -0000
Subject: [issue2167] Remove unused imports
In-Reply-To: <1203780138.17.0.0226690463591.issue2167@psf.upfronthosting.co.za>
Message-ID: <1203784841.45.0.533659832863.issue2167@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2167>
__________________________________

From report at bugs.python.org  Sat Feb 23 17:50:45 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 16:50:45 -0000
Subject: [issue800929] Module-specific PDFs
Message-ID: <1203785445.66.0.82946394756.issue800929@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Given that we now have a print-specific stylesheet 
for the documentation, a printed version of the HTML page for a module
seems acceptable.  I just looked at a print-preview of the pickle docs,
the output looks good, so IMHO we don't need to do anything special 
to start building individual PDF files on python.org.

----------
nosy: +akuchling
resolution:  -> works for me
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue800929>
____________________________________

From report at bugs.python.org  Sat Feb 23 17:53:06 2008
From: report at bugs.python.org (Alexandre Fiori)
Date: Sat, 23 Feb 2008 16:53:06 -0000
Subject: [issue1817] module-cgi: handling GET and POST together
In-Reply-To: <1200189536.91.0.809582793643.issue1817@psf.upfronthosting.co.za>
Message-ID: <1203785586.15.0.469900866839.issue1817@psf.upfronthosting.co.za>


Alexandre Fiori added the comment:

Here's the unit test for patched cgi module.
There are three tests: one for HTML POST forms that are urlencoded, and
two for multipart/form-data - with and without file upload.

Added file: http://bugs.python.org/file9507/cgitest.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1817>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:02:40 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 17:02:40 -0000
Subject: [issue1174614] site enhancements
Message-ID: <1203786159.99.0.18037500278.issue1174614@psf.upfronthosting.co.za>


Christian Heimes added the comment:

The feature request is superseded by my PEP 370
(http://www.python.org/dev/peps/pep-0370/). As far as I understand your
proposal the PEP covers your use cases.

----------
resolution:  -> out of date

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1174614>
_____________________________________

From report at bugs.python.org  Sat Feb 23 18:04:41 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 17:04:41 -0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1203786281.56.0.913678770545.issue1322@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Thanks Pavel!
First I need confirmation from the GHOP project and Georg that you have
submitted the contributor form. Then I'm going to merge your patch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:06:32 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 17:06:32 -0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1203786392.2.0.754569584295.issue1322@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee: tiran -> georg.brandl
keywords: +patch
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:13:59 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2008 17:13:59 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203786839.82.0.0811096968965.issue1040026@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Well first I can't reproduce the bug on my machine :)
However the two patches do not produce any regression either.
I have some questions:
1. isn't 0.1 for WAIT_TIME a bit too low? 1.0 would probably be less
fragile IMHO
2. why do you fork() in test_times, rather than simply compute the
increase in the first and second return values of os.times()?

----------
nosy: +pitrou

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 18:18:22 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 17:18:22 -0000
Subject: [issue2167] Remove unused imports
In-Reply-To: <1203780138.17.0.0226690463591.issue2167@psf.upfronthosting.co.za>
Message-ID: <1203787102.03.0.0444261945081.issue2167@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm going to check the patch now.

----------
nosy: +tiran
priority:  -> normal
type:  -> behavior
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2167>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:21:24 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 17:21:24 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203787284.06.0.853934725202.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Using 1.0 would certainly be more robust. I wasn't sure if a slow-down
of "make test" by 1 second just for this one bug would be acceptable.

Regarding the fork, when I first encountered this bug, it was in the
context of measuring the runtime of child processes, so that's what I
tried to reproduce. But looking at the code, the bug should occur just
as well with the running process itself. So you're right; one could just
busy-wait for a second and then look at times()[0] and times()[1].

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 18:22:43 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 17:22:43 -0000
Subject: [issue1433694] normalize function in minidom unlinks empty child nodes
Message-ID: <1203787363.24.0.915967658951.issue1433694@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Patch applied to 2.6 in rev. 60995, and to 2.5-maint in rev. 60998.
Thanks for reporting the problem, and for finding the bugfix!

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1433694>
_____________________________________

From report at bugs.python.org  Sat Feb 23 18:27:34 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 17:27:34 -0000
Subject: [issue781445] Applets don't work on 10.1
Message-ID: <1203787654.85.0.132050858727.issue781445@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Presumably this was fixed in 10.1 or 10.2 at some point, because
MacPython 2.3 comes as an installer.  Closing as 'fixed'; Jack, please
re-open
if this is still relevant.

----------
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue781445>
____________________________________

From report at bugs.python.org  Sat Feb 23 18:28:05 2008
From: report at bugs.python.org (ajaksu)
Date: Sat, 23 Feb 2008 17:28:05 -0000
Subject: [issue2169] Adding DOCTYPE and "html", "body" tags to SimpleHTTPServer
In-Reply-To: <1203787685.42.0.819164609071.issue2169@psf.upfronthosting.co.za>
Message-ID: <1203787685.42.0.819164609071.issue2169@psf.upfronthosting.co.za>


New submission from ajaksu:

This small patch adds a HTML 3.2 doctype, a <html> and a <body> tags.
Should work on py3k.

This patch only accomplishes a "Tentatively Valid HTML 3.2" result.
Adding information on  encoding would make that more conclusive, but
IMHO wrong too.

----------
components: Library (Lib)
files: SimpleHTTP_doctype_tags.diff
messages: 62780
nosy: ajaksu2
severity: minor
status: open
title: Adding DOCTYPE and "html", "body" tags to SimpleHTTPServer
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9508/SimpleHTTP_doctype_tags.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2169>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:29:32 2008
From: report at bugs.python.org (David Chrsitian)
Date: Sat, 23 Feb 2008 17:29:32 -0000
Subject: [issue1174606] Reading /dev/zero causes SystemError
Message-ID: <1203787772.01.0.932778131905.issue1174606@psf.upfronthosting.co.za>


David Chrsitian added the comment:

I don't see any change to the return value of new_buffersize that could
alleviate this problem - the problem being that because linux is
extremely efficient at reading bytes from /dev/zero, some other code
incosistencies are exposed.

The problem that is being hit is that the new_buffersize value is
allowed to grow without bounds and is never rechecked for sanity, then
is passed in to PyString_Resize where it is converted from unsigned int
to signed int.

I suggest adding a check of new_buffersize against PY_SSIZE_T_MAX.  If
it exceeded, we could raise an OverflowError - "unbounded read consumed
more bytes than a Python string can hold"

----------
nosy: +dugan

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1174606>
_____________________________________

From report at bugs.python.org  Sat Feb 23 18:32:48 2008
From: report at bugs.python.org (Pavel Vinogradov)
Date: Sat, 23 Feb 2008 17:32:48 -0000
Subject: [issue1322] platform.dist() has unpredictable result under Linux
In-Reply-To: <1193246464.1.0.269134020057.issue1322@psf.upfronthosting.co.za>
Message-ID: <1203787968.64.0.937329509861.issue1322@psf.upfronthosting.co.za>


Pavel Vinogradov added the comment:

You can see confirmation from Georg on thread in GHOP:
http://code.google.com/p/google-highly-open-participation-psf/issues/detail?id=216&can=1&colspec=ID%20Status%20ClaimedBy%20Due%20NeedsReview%20Summary#c20

I can update patch for 3.0 (it don't applies now) if you are ready to
commit them.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:42:04 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 17:42:04 -0000
Subject: [issue2167] Remove unused imports
In-Reply-To: <1203780138.17.0.0226690463591.issue2167@psf.upfronthosting.co.za>
Message-ID: <1203788524.42.0.0463203276737.issue2167@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Applied in r61000

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2167>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:43:27 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 17:43:27 -0000
Subject: [issue1957] [patch] syslogmodule: Release GIL when calling syslog(3)
In-Reply-To: <1201534314.07.0.339732897675.issue1957@psf.upfronthosting.co.za>
Message-ID: <1203788607.61.0.601412986852.issue1957@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Applied in r61001
Thanks for the patch! :)

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1957>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:50:27 2008
From: report at bugs.python.org (Pedro Werneck)
Date: Sat, 23 Feb 2008 17:50:27 -0000
Subject: [issue2118] smtplib.SMTP() raises socket.error rather than
	SMTPConnectError
In-Reply-To: <1203027793.14.0.279031432545.issue2118@psf.upfronthosting.co.za>
Message-ID: <1203789027.43.0.829368861456.issue2118@psf.upfronthosting.co.za>


Pedro Werneck added the comment:

Previous patch didn't passed the tests right. This patch fixes both the
code, unindenting port number conversion to integer and the test.

Added file: http://bugs.python.org/file9509/issue_2118_fixed.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2118>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:52:33 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 23 Feb 2008 17:52:33 -0000
Subject: [issue2051] PYO file permission problem
In-Reply-To: <1202498912.62.0.957005802385.issue2051@psf.upfronthosting.co.za>
Message-ID: <1203789153.39.0.711169204203.issue2051@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Fixed in r61002

Thanks for your patch Alexander! Good work.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2051>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:52:58 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 17:52:58 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203789177.99.0.871499052555.issue2124@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The solution of adding caching, If-Modified-Since, etc. is a good one,
but I quail in fear at the prospect of expanding the saxutils resolver
into a fully caching HTML agent that uses a cache across processes.  We
should really be encouraging people to use more capable libraries such
as httplib2 (http://code.google.com/p/httplib2/), but this is slightly
at war 
with the batteries-included philosophy.

So, I propose we:

* add warnings to the urllib, urllib2, saxutil module docs that parsing
can retrieve arbitrary resources over the network, and encourage the
user to use a smarter library such as httplib2.
* update the urllib2 HOWTO to mention this.

I'm willing to do the necessary writing.

----------
assignee:  -> akuchling
priority: urgent -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sat Feb 23 18:57:35 2008
From: report at bugs.python.org (ajaksu)
Date: Sat, 23 Feb 2008 17:57:35 -0000
Subject: [issue1207466] installer ignores changed installation directory
Message-ID: <1203789455.27.0.969165428079.issue1207466@psf.upfronthosting.co.za>


ajaksu added the comment:

If the fix was applied, this should be closed. If not, seems pretty easy
to do (worst case: add as Known Issue, Won't Fix).

----------
nosy: +ajaksu2

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1207466>
_____________________________________

From report at bugs.python.org  Sat Feb 23 19:17:15 2008
From: report at bugs.python.org (Pedro Werneck)
Date: Sat, 23 Feb 2008 18:17:15 -0000
Subject: [issue1375] hotshot IndexError when loading stats
In-Reply-To: <1194031021.72.0.351195403989.issue1375@psf.upfronthosting.co.za>
Message-ID: <1203790635.94.0.173366270293.issue1375@psf.upfronthosting.co.za>


Pedro Werneck added the comment:

Fixed by raising StopIteration when the stack is empty.

----------
nosy: +werneck
Added file: http://bugs.python.org/file9510/issue_1375_hotshot.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1375>
__________________________________

From report at bugs.python.org  Sat Feb 23 19:20:50 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 23 Feb 2008 18:20:50 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203790850.4.0.835677314693.issue2124@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I may have lost track somewhere: what does have urllib* to do with this
issue?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Sat Feb 23 19:23:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 23 Feb 2008 18:23:00 -0000
Subject: [issue1207466] installer ignores changed installation directory
Message-ID: <1203790980.74.0.461764592564.issue1207466@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

It was not fixed yet, but I will fix it eventually (this year, or later).

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1207466>
_____________________________________

From report at bugs.python.org  Sat Feb 23 19:24:08 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 18:24:08 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203791048.76.0.713950717747.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Note: My original unit test fails to take account that previous unit
tests may have spawned child processes. The correct behaviour is of
course to call os.times() before and after the fork and compute the
difference.

I'm not uploading a modified patch because from previous comments it
looks like a different test will be used anyway.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 19:26:37 2008
From: report at bugs.python.org (David Christian)
Date: Sat, 23 Feb 2008 18:26:37 -0000
Subject: [issue1174606] Reading /dev/zero causes SystemError
Message-ID: <1203791197.55.0.253325632416.issue1174606@psf.upfronthosting.co.za>


David Christian added the comment:

Raise OverflowError if unbounded read() exceeds PY_SSIZE_T_MAX bytes.

Added file: http://bugs.python.org/file9511/issue1174606.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1174606>
_____________________________________

From report at bugs.python.org  Sat Feb 23 19:40:21 2008
From: report at bugs.python.org (David Christian)
Date: Sat, 23 Feb 2008 18:40:21 -0000
Subject: [issue1174606] Reading /dev/zero causes SystemError
Message-ID: <1203792021.22.0.324816345121.issue1174606@psf.upfronthosting.co.za>


Changes by David Christian:


Added file: http://bugs.python.org/file9512/issue1174606.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1174606>
_____________________________________

From report at bugs.python.org  Sat Feb 23 19:52:09 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 18:52:09 -0000
Subject: [issue1389051] imaplib causes excessive fragmentation for large
	documents
Message-ID: <1203792729.43.0.145517686167.issue1389051@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
assignee:  -> akuchling
nosy: +akuchling

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1389051>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:01:07 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 19:01:07 -0000
Subject: [issue2170] rewrite of minidom.Node.normalize
In-Reply-To: <1203793267.02.0.633185244836.issue2170@psf.upfronthosting.co.za>
Message-ID: <1203793267.02.0.633185244836.issue2170@psf.upfronthosting.co.za>


New submission from Malte Helmert:

In the discussion of #1433694 on the #python-dev channel, it was
observed that the normalize method of minidom.Node could take some
refactoring. A patch is attached.

----------
components: XML
files: minidom.diff
messages: 62794
nosy: maltehelmert
severity: normal
status: open
title: rewrite of minidom.Node.normalize
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9513/minidom.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2170>
__________________________________

From report at bugs.python.org  Sat Feb 23 20:07:46 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 19:07:46 -0000
Subject: [issue1389051] imaplib causes excessive fragmentation for large
	documents
Message-ID: <1203793666.0.0.790640327762.issue1389051@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Fredrik's suggested fix for SSL IMAP committed as rev. 61006, and to
2.5-maint in rev. 61007.

There still seems to be a problem with the non-SSL version.  I'm looking
into that next.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1389051>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:18:40 2008
From: report at bugs.python.org (rbp)
Date: Sat, 23 Feb 2008 19:18:40 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203794320.64.0.940146241737.issue1040026@psf.upfronthosting.co.za>


rbp added the comment:

Malte, Antoine and I discussed this a bit on #python-dev and concluded
that the correct behaviour should be trying sysconf first, then HZ, or
raise an exception if not even HZ is available (since whichever static
value we chose would be misleading anyway).

I'm attaching a patch (modified from Malte's) which implements that.

----------
nosy: +rbp
versions: +Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9514/os_times2.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:31:26 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 19:31:26 -0000
Subject: [issue1092502] Memory leak in socket.py on Mac OS X
Message-ID: <1203795086.2.0.373466945248.issue1092502@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Andreas Lauer's suggested fix is correct.  Applied to 2.6 trunk in rev.
61008 and to 2.5-maint in rev. 61009.

----------
nosy: +akuchling
resolution: out of date -> fixed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092502>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:32:11 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 19:32:11 -0000
Subject: [issue1389051] imaplib causes excessive fragmentation for large
	documents
Message-ID: <1203795131.62.0.82750122175.issue1389051@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Andreas Lauer's suggested fix on #1092502 is correct, and fixes the
problem for the non-SSL IMAP class.  Applied to 2.6 trunk in rev. 61008
and to 2.5-maint in rev. 61009.

----------
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1389051>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:33:01 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 19:33:01 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203795181.1.0.72352046862.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Attaching a new test (test_posix2.PATCH) that doesn't fork and fixes the
problem with the previous test not taking previously elapsed time into
account. This supersedes test_posix.PATCH.

I left the wait time at 0.1; if we stay within the same process, this
should be large enough. A busy wait loop for 0.1 seconds should easily
get the 5% precision required by the assertAlmostEqual.

Added file: http://bugs.python.org/file9515/test_posix2.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:39:46 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Sat, 23 Feb 2008 19:39:46 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203795586.8.0.276404509385.issue2149@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

Just to exemplify:
"""
from threading import Thread
import time
import Queue

class C:
  def __int__(self):
    return 3
  
  #def __del__(self): print "collected..." # won't happen since q holds
a reference to it

c = C()
q = Queue.Queue(c)

# Not dynamic
print "maxsize: ", q.maxsize

# Not full() with instance
print c > 0
print len(q.queue) == q.maxsize

class T(Thread):
  def __init__(self, q):
    self._q = q
    Thread.__init__(self)
  
  def run(self):
    #For sme bizarre motive
    self._q.maxsize = 5

#Ends up being infinite most of the times
t = T(q)

for i in xrange(1000):
  q.put_nowait(i)
  if i == 1: # otherwise the "and len(self.queue) == self.maxsize" will fail
    t.start()
    time.sleep(1)

t.join()
"""

I guess rhettinger is right, there's no issue here, anyone that decides
to change the maxsize afterwards should know what is doing.

The only "possible" problem I'm able to see is someone passing an object
wich has __int__() and expecting it to be used.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Sat Feb 23 20:40:10 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 19:40:10 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203795609.99.0.867554731328.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

I was wrong -- 0.1 isn't enough, because os.times() typically has 0.01s
resolution, so we can easily get 0.1 vs. 0.11 which will fail the
assertion. Cranked up the WAIT_TIME to 0.3 in the attached patch
(test_posix3.PATCH). Sorry for the noise.

Added file: http://bugs.python.org/file9516/test_posix3.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:43:36 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sat, 23 Feb 2008 19:43:36 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203795816.55.0.664194019314.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Sorry, but the test was still wrong because I misunderstood how
assertAlmostEqual works. Attaching a fourth (final?) test.

Added file: http://bugs.python.org/file9517/test_posix4.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 20:45:41 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 19:45:41 -0000
Subject: [issue2170] rewrite of minidom.Node.normalize
In-Reply-To: <1203793267.02.0.633185244836.issue2170@psf.upfronthosting.co.za>
Message-ID: <1203795941.03.0.246837383963.issue2170@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
assignee:  -> akuchling
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2170>
__________________________________

From report at bugs.python.org  Sat Feb 23 20:56:59 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Feb 2008 19:56:59 -0000
Subject: [issue2149] Queue.maxsize, __init__() accepts any value as maxsize
In-Reply-To: <1203542440.82.0.407837052155.issue2149@psf.upfronthosting.co.za>
Message-ID: <1203796619.44.0.037766114403.issue2149@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

> The only "possible" problem I'm able to see is someone passing an object
wich has __int__() and expecting it to be used.
They should be explicit and say Queue(int(object_with__int__)).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2149>
__________________________________

From report at bugs.python.org  Sat Feb 23 21:02:59 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sat, 23 Feb 2008 20:02:59 -0000
Subject: [issue1193577] add server.shutdown() method and daemon arg to
	SocketServer
Message-ID: <1203796979.94.0.438662694303.issue1193577@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

This is getting in my way, so I'll take a look at it. I'm planning to
model the shutdown API after
http://java.sun.com/javase/6/docs/api/java/util/concurrent/ExecutorService.html.
The serve_forever->shutdown interval should probably also be available
through a context manager.

----------
assignee: skip.montanaro -> jyasskin
nosy: +jyasskin

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1193577>
_____________________________________

From report at bugs.python.org  Sat Feb 23 21:04:16 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Sat, 23 Feb 2008 20:04:16 -0000
Subject: [issue2143] smtplib.SSLFakeFile hangs forever if "\n" is not
	encountered
In-Reply-To: <1203450784.48.0.914624365549.issue2143@psf.upfronthosting.co.za>
Message-ID: <1203797056.49.0.351559306304.issue2143@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

As of 2.6 the smtplib uses the ssl module, until 2.5 it uses _ssl, I
*think* that this issue would bring an Exception on 2.5 while on 2.6
would return a zero length string:
"""
def read(self, len=1024):

        """Read up to LEN bytes and return them.
        Return zero-length string on EOF."""

        return self._sslobj.read(len)
"""

wich would fulfill the "if not chr:"

----------
nosy: +zanella

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2143>
__________________________________

From report at bugs.python.org  Sat Feb 23 21:06:21 2008
From: report at bugs.python.org (rbp)
Date: Sat, 23 Feb 2008 20:06:21 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203797181.4.0.919991030137.issue1040026@psf.upfronthosting.co.za>


rbp added the comment:

Malte noticed that my previous patch won't compile when HAVE_SYSCONFIG
and HZ are not defined. My bad, silly mistake.

I've attached a new version, which compiles and has been tested on all
three cases (with test_posix4.PATCH). Please, someone with privileges
remove os_times2.PATCH.

Added file: http://bugs.python.org/file9518/os_times3.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 21:27:24 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 20:27:24 -0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1203798444.82.0.865231145145.issue1204@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
assignee:  -> akuchling
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
__________________________________

From report at bugs.python.org  Sat Feb 23 21:28:15 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 20:28:15 -0000
Subject: [issue1204] readline configuration for shared libs w/o curses
	dependencies
In-Reply-To: <1190748848.08.0.561409665353.issue1204@psf.upfronthosting.co.za>
Message-ID: <1203798495.16.0.434574291151.issue1204@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

The patch looks reasonable.  I'll commit it on Monday when I'm on a
machine with a more up-to-date autoconf.

----------
keywords: +64bit

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1204>
__________________________________

From report at bugs.python.org  Sat Feb 23 21:37:54 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 20:37:54 -0000
Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character
	stream in InputSource
In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za>
Message-ID: <1203799074.04.0.480294220411.issue1483@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Could you please provide a simple little test case for the bug?  I'd
like to add a test when I commit the change, but you can probably boil
the problem down into a test faster than I can.

----------
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483>
__________________________________

From report at bugs.python.org  Sat Feb 23 21:42:22 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 20:42:22 -0000
Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space
	in values.
In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za>
Message-ID: <1203799342.15.0.785529913324.issue1714@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
assignee:  -> akuchling
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1714>
__________________________________

From report at bugs.python.org  Sat Feb 23 21:51:18 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 23 Feb 2008 20:51:18 -0000
Subject: [issue1064] Test issue
In-Reply-To: <1188505590.02.0.0614913365706.issue1064@psf.upfronthosting.co.za>
Message-ID: <1203799878.46.0.415832653103.issue1064@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Attaching this patch should a) set the patch keyword, and b) set the
mime type to text/plain.

----------
keywords: +patch
Added file: http://bugs.python.org/file9519/foo.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1064>
__________________________________

From report at bugs.python.org  Sat Feb 23 22:07:51 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 21:07:51 -0000
Subject: [issue1519] async_chat.__init__() parameters
In-Reply-To: <1196346058.65.0.25106672712.issue1519@psf.upfronthosting.co.za>
Message-ID: <1203800871.45.0.89629345148.issue1519@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
assignee:  -> josiahcarlson
nosy: +josiahcarlson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1519>
__________________________________

From report at bugs.python.org  Sat Feb 23 22:10:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 21:10:45 -0000
Subject: [issue2014] xmlrpclib cannot send datetime objects with dates before
	1900
In-Reply-To: <1202253157.6.0.363228271148.issue2014@psf.upfronthosting.co.za>
Message-ID: <1203801045.69.0.587805492969.issue2014@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

Attaching an updated version of the patch against trunk revision 61011.

Added file: http://bugs.python.org/file9520/xmlrpc_date_before_1900_r61011.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Sat Feb 23 22:13:26 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 21:13:26 -0000
Subject: [issue1291] test_resource fails on recent linux systems (
In-Reply-To: <1192698822.84.0.082608978163.issue1291@psf.upfronthosting.co.za>
Message-ID: <1203801206.35.0.717075783159.issue1291@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +easy

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1291>
__________________________________

From report at bugs.python.org  Sat Feb 23 22:15:12 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Feb 2008 21:15:12 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203801312.79.0.28588262573.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

os_times3.PATCH works for me on Mac OS 10.4 and RHEL.  I have a few 
comments on the patch:

1. sysconf return type is long, not clock_t
2. If sysconf is present, but _SC_CLK_TCK is not supported, it will 
return -1.  In this case we should fall back to system HZ if available.
3. Use -1 instead of NULL as the invalid value. NULL has too strong 
connotation with pointers.
4. On systems where fixed HZ is correct calling sysconf(_SC_CLK_TCK) on 
every times call is an overkill.

I would suggest that instead of patching posixmodule.c an appropriate 
system-dependent value for HZ should be defined in configure.h.  
Unfortunately I am not familiar enough with autoconf to prepare a patch.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 22:15:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Feb 2008 21:15:22 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203801322.96.0.261051089663.issue1040026@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sat Feb 23 22:19:36 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 21:19:36 -0000
Subject: [issue1311] os.path.exists(os.devnull) regression on windows
In-Reply-To: <1193054658.57.0.203252941268.issue1311@psf.upfronthosting.co.za>
Message-ID: <1203801576.26.0.198023698111.issue1311@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1311>
__________________________________

From report at bugs.python.org  Sat Feb 23 22:37:16 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 21:37:16 -0000
Subject: [issue1291] test_resource fails on recent linux systems
In-Reply-To: <1192698822.84.0.082608978163.issue1291@psf.upfronthosting.co.za>
Message-ID: <1203802636.49.0.970297453192.issue1291@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

I went ahead and pulled the 2.6 test back into 2.5-maint in
rev. 61016, and then realized that Nick actually backported the
change in rev. 60727.  I decided to leave it alone; the 2.6
test should still avoid the problem, has the additional 
feature of using unittest, and isn't a feature change to the interpreter
itself.

----------
nosy: +akuchling
status: open -> closed
title: test_resource fails on recent linux systems ( -> test_resource fails on recent linux systems

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1291>
__________________________________

From report at bugs.python.org  Sat Feb 23 22:42:28 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 21:42:28 -0000
Subject: [issue1088077] [PATCH] tty needs a way to restore the terminal mode.
Message-ID: <1203802948.14.0.771960175887.issue1088077@psf.upfronthosting.co.za>


Facundo Batista added the comment:

As Martin says, the functionality is present. If still you think we have
a new method here, please raise a discussion in python-dev regarding this.

Thank you!

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1088077>
_____________________________________

From report at bugs.python.org  Sat Feb 23 22:44:31 2008
From: report at bugs.python.org (Mike Beachy)
Date: Sat, 23 Feb 2008 21:44:31 -0000
Subject: [issue1156430] doctest should support -m
Message-ID: <1203803071.49.0.411885757232.issue1156430@psf.upfronthosting.co.za>


Mike Beachy added the comment:

This request was implemented in 1663234, so this case can be closed.

----------
nosy: +mbeachy

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1156430>
_____________________________________

From report at bugs.python.org  Sat Feb 23 22:45:24 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 21:45:24 -0000
Subject: [issue1746071] class mutex doesn't do anything atomically
Message-ID: <1203803124.14.0.173459304432.issue1746071@psf.upfronthosting.co.za>


Facundo Batista added the comment:

On 2008/2/23, Guido van Rossum said in python-dev

> According to the docstring it's only meant to be used with sched.py.
> Please don't try to make it work with threads!

Anyway, this module will be removed, or at least its API hidden, in 3.0.

----------
nosy: +facundobatista
resolution:  -> wont fix
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746071>
_____________________________________

From report at bugs.python.org  Sat Feb 23 22:51:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 21:51:12 -0000
Subject: [issue1156430] doctest should support -m
Message-ID: <1203803472.48.0.622066899432.issue1156430@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Closing as fixed.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1156430>
_____________________________________

From report at bugs.python.org  Sat Feb 23 22:59:06 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 21:59:06 -0000
Subject: [issue1633953] re.compile("(.*$){1,4}", re.MULTILINE) fails
Message-ID: <1203803946.12.0.603981901227.issue1633953@psf.upfronthosting.co.za>


Changes by Ralf Schmitt:


----------
nosy: +schmir

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1633953>
_____________________________________

From report at bugs.python.org  Sat Feb 23 22:59:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 21:59:20 -0000
Subject: [issue2101] xml.dom documentation doesn't match implementation
In-Reply-To: <1202913434.5.0.501643425154.issue2101@psf.upfronthosting.co.za>
Message-ID: <1203803960.82.0.91161165981.issue2101@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed in r61017.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2101>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:03:18 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 22:03:18 -0000
Subject: [issue1576208] ConfigParser: whitespace leading comment lines
Message-ID: <1203804198.34.0.395982320306.issue1576208@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Duplicate of #1524825

----------
nosy: +facundobatista
resolution:  -> duplicate
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1576208>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:03:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 22:03:58 -0000
Subject: [issue1524825] ConfigParser: accept leading whitespace on
	options+comments
Message-ID: <1203804238.82.0.66199449034.issue1524825@psf.upfronthosting.co.za>


Changes by Georg Brandl:


----------
type:  -> feature request
versions: +Python 2.6, Python 3.0

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524825>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:05:03 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 22:05:03 -0000
Subject: [issue1524825] ConfigParser: accept leading whitespace on
	options+comments
Message-ID: <1203804303.93.0.258887838653.issue1524825@psf.upfronthosting.co.za>


Changes by Facundo Batista:


----------
keywords: +easy -patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524825>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:05:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Feb 2008 22:05:50 -0000
Subject: [issue1746071] class mutex doesn't do anything atomically
Message-ID: <1203804350.37.0.903457609747.issue1746071@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

For what it's worth, here's a test case against the trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file9521/test_mutex.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746071>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:06:15 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 22:06:15 -0000
Subject: [issue1607087] popen() slow on AIX due to large FOPEN_MAX value
Message-ID: <1203804375.34.0.16592716523.issue1607087@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

python 2.6 has os.closerange. however it is currently not used in popen2.

----------
nosy: +schmir

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1607087>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:09:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 22:09:41 -0000
Subject: [issue1607087] popen() slow on AIX due to large FOPEN_MAX value
Message-ID: <1203804581.2.0.711022078587.issue1607087@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Changed popen2 to use os.closerange() in r61019.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1607087>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:21:25 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 23 Feb 2008 22:21:25 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za>
Message-ID: <1203805285.84.0.417296793099.issue1740@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Here is an updated patch, it should apply fine against trunk.

Added file: http://bugs.python.org/file9522/logtest2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:25:44 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 22:25:44 -0000
Subject: [issue1718942] glibc error: corrupted double linked list (CPython
	2.5.1)
Message-ID: <1203805544.37.0.387236763315.issue1718942@psf.upfronthosting.co.za>


Facundo Batista added the comment:

As Raymond says, it's not a Python issue, but an extension one.

----------
nosy: +facundobatista
resolution:  -> rejected
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1718942>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:33:59 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Feb 2008 22:33:59 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203806039.14.0.0379545137106.issue2144@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Small comment on the patch:

                 def clear(self):
-                    for key in self.data.keys():
+                    for key in self.keys():
                         unsetenv(key)
-                        del self.data[key]
+                        del self[key]

It looks like the patched version will unsetenv twice, Change

del self[key]

to

dict.__delitem__(self, key)


+1

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:38:47 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 22:38:47 -0000
Subject: [issue919238] Recursive variable definition causes sysconfig infinite
	loop
Message-ID: <1203806327.2.0.537651926557.issue919238@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Is a "print" really the right way to emit this warning?

----------
nosy: +georg.brandl

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue919238>
____________________________________

From report at bugs.python.org  Sat Feb 23 23:40:21 2008
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Sat, 23 Feb 2008 22:40:21 -0000
Subject: [issue1714] ConfigParser.py do not allow leading (and trailing) space
	in values.
In-Reply-To: <1199115002.03.0.289718233868.issue1714@psf.upfronthosting.co.za>
Message-ID: <1203806421.58.0.864684047553.issue1714@psf.upfronthosting.co.za>


Quentin Gallet-Gilles added the comment:

Here's an updated patch, taking in account akuchling and schmir suggestions.

----------
keywords: +patch
Added file: http://bugs.python.org/file9523/cfgparser_doublequotes_r61014.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1714>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:43:24 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Feb 2008 22:43:24 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203806604.3.0.501037057088.issue2144@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Here's a corrected version.

----------
keywords: +patch
Added file: http://bugs.python.org/file9524/environ-modern2.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:46:41 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 22:46:41 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203806801.71.0.180582102985.issue2144@psf.upfronthosting.co.za>


Georg Brandl added the comment:

See #1367711 for a discussion whether this is really the way to go.

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:49:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 23 Feb 2008 22:49:35 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203806975.83.0.438900769865.issue2144@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

And another.

Added file: http://bugs.python.org/file9525/environ-modern3.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:49:46 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 22:49:46 -0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1203806986.42.0.0767151524554.issue1820@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Is there something else to be done for this to be closed?

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:54:02 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 23 Feb 2008 22:54:02 -0000
Subject: [issue1820] Enhance Object/structseq.c to match namedtuple and tuple
	api
In-Reply-To: <1200284428.58.0.762384814897.issue1820@psf.upfronthosting.co.za>
Message-ID: <1203807242.23.0.621509075548.issue1820@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

All three items are still open.  The second one is the easiest.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1820>
__________________________________

From report at bugs.python.org  Sat Feb 23 23:54:33 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sat, 23 Feb 2008 22:54:33 -0000
Subject: [issue1746071] class mutex doesn't do anything atomically
Message-ID: <1203807273.13.0.310718435371.issue1746071@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Added test case in r61024.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1746071>
_____________________________________

From report at bugs.python.org  Sat Feb 23 23:55:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 22:55:24 -0000
Subject: [issue1825] msilib.add_data() takes exactly three parameters
In-Reply-To: <1200337960.21.0.113421612542.issue1825@psf.upfronthosting.co.za>
Message-ID: <1203807324.67.0.455385670445.issue1825@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed in r61025.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1825>
__________________________________

From report at bugs.python.org  Sun Feb 24 00:02:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 23:02:30 -0000
Subject: [issue1826] operator.attrgetter() should accept dotted attribute paths
In-Reply-To: <1200338540.99.0.155814937685.issue1826@psf.upfronthosting.co.za>
Message-ID: <1203807750.91.0.355824886844.issue1826@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Committed in r61027.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1826>
__________________________________

From report at bugs.python.org  Sun Feb 24 00:05:11 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 23:05:11 -0000
Subject: [issue1506171] Add "methodcaller" to the operator module
Message-ID: <1203807911.2.0.100216712447.issue1506171@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Committed patch as r61028.

----------
assignee: rhettinger -> georg.brandl
resolution:  -> accepted
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1506171>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:10:55 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 23:10:55 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203808255.88.0.515790552223.issue1725737@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

running setup.py sdist --prune results in:

making hard links in ex-0.0.0...
hard linking MANIFEST.in -> ex-0.0.0
hard linking setup.py -> ex-0.0.0
hard linking .hg/00changelog.i -> ex-0.0.0/.hg
hard linking .hg/dirstate -> ex-0.0.0/.hg
hard linking .hg/requires -> ex-0.0.0/.hg
hard linking .hg/undo.branch -> ex-0.0.0/.hg
hard linking .hg/undo.dirstate -> ex-0.0.0/.hg
hard linking .hg/store/00changelog.i -> ex-0.0.0/.hg/store
hard linking .hg/store/00manifest.i -> ex-0.0.0/.hg/store
hard linking .hg/store/undo -> ex-0.0.0/.hg/store
hard linking .hg/store/data/_m_a_n_i_f_e_s_t.in.i -> ex-0.0.0/.hg/store/data
hard linking .hg/store/data/setup.py.i -> ex-0.0.0/.hg/store/data
hard linking .svn/entries -> ex-0.0.0/.svn
creating dist
tar -cf dist/ex-0.0.0.tar ex-0.0.0
gzip -f9 dist/ex-0.0.0.tar
removing 'ex-0.0.0' (and everything under it)

Added file: http://bugs.python.org/file9526/ex.tgz

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:11:37 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 23:11:37 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203808297.06.0.819806790808.issue1725737@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

.hg, .git, are also candidates

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:15:23 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 23:15:23 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203808523.59.0.543381358821.issue1858@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Random notes on bugday.distutils.patch:

* dist.py: this change should definitely be applied, no matter what 
  happens to the rest of the patch.

* Yay!  Lots of tests!

* distutils.pypirc: I'm doubtful of the finalize_options() here;
  looking for '-r' in the args seems like it could get confused 
  if there are packages or other arguments that just happen
  to use that name.  It seems like a remote possibility, but still...

* distutils.pypirc: Class name typo in module docstring.
  
* Would the distutils.pypirc module be better named something like
  distutils.config?

* register.py: why use PyPIRCCommand.DEFAULT_REPOSITORY 
  and not register.DEFAULT_REPOSITORY?  I guess it's more useful to
  have a single Distutil-wide default repository.  No action needed.

----------
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Sun Feb 24 00:19:41 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Sat, 23 Feb 2008 23:19:41 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203808781.62.0.200196154834.issue1858@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

* I like factoring out the .pypirc code into a separate class.

* Overall I think the patch is acceptable.  We'd need to decide whether
  the new .pypirc is considered suitable -- I don't remember the reaction
  to it on the distutils-sig or catalog-sig -- but this patch seems
  like a decent implementation of the new format.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Sun Feb 24 00:21:12 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 23:21:12 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203808872.73.0.181546029525.issue1725737@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

.bzr, and _darcs (yes, underscore) also.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:22:37 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 23 Feb 2008 23:22:37 -0000
Subject: [issue1367711] Remove usage of UserDict from os.py
Message-ID: <1203808957.13.0.838512077061.issue1367711@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I would say dict's failure to call overloaded __setitem__ from 
setdefault is a dict implementation problem which should be either 
fixed, or clearly documented as warning to anyone who wants to derive 
from dict.

A fix would be trivial:

===================================================================
--- Objects/dictobject.c        (revision 61014)
+++ Objects/dictobject.c        (working copy)
@@ -1861,7 +1861,7 @@
        val = ep->me_value;
        if (val == NULL) {
                val = failobj;
-               if (PyDict_SetItem((PyObject*)mp, key, failobj))
+               if (PyObject_SetItem(mp, key, failobj))
                        val = NULL;
        }
        Py_XINCREF(val);

but I have no clue what performance or other implications would be.

Maybe something like this could be considered for Py3k - reviewing dict 
implementation to make it usable as DictMixin.  I'll write a complete 
patch if there is positive reaction.

----------
nosy: +belopolsky

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367711>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:25:44 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 23:25:44 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203809144.96.0.0804973532482.issue1720705@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Documented in both thread and threading docs in r61029.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:26:50 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 23:26:50 -0000
Subject: [issue1759997] poll() on cygwin sometimes fails [PATCH]
Message-ID: <1203809210.49.0.493942064433.issue1759997@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Closing as 3rd party, then.

----------
nosy: +georg.brandl
status: open -> closed
versions: +3rd party -Python 2.5

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1759997>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:29:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 23:29:02 -0000
Subject: [issue1175194] import statement likely to crash if module launches
	threads
Message-ID: <1203809342.44.0.94147255149.issue1175194@psf.upfronthosting.co.za>


Georg Brandl added the comment:

The documentation has now been updated to reflect this.

----------
nosy: +georg.brandl
resolution: invalid -> duplicate
status: pending -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175194>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:34:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 23:34:45 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203809685.22.0.0301023961655.issue1725737@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

updated version of diff, which also excludes .hg, .git, .bzr, and _darcs.

Added file: http://bugs.python.org/file9527/more-vcs-exclude.txt

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:50:37 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 23:50:37 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203810637.03.0.208101589164.issue1725737@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

also patch docs.

Added file: http://bugs.python.org/file9528/more-vcs-exclude+docs.txt

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:51:18 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sat, 23 Feb 2008 23:51:18 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203810678.07.0.0729297939295.issue1725737@psf.upfronthosting.co.za>


Changes by Ralf Schmitt:


----------
nosy: +georg.brandl

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Sun Feb 24 00:58:04 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 23 Feb 2008 23:58:04 -0000
Subject: [issue1411097] httplib patch to make _read_chunked() more robust
Message-ID: <1203811084.26.0.58400205512.issue1411097@psf.upfronthosting.co.za>


Georg Brandl added the comment:

This seems to have been fixed in r60747.

----------
resolution:  -> out of date
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1411097>
_____________________________________

From report at bugs.python.org  Sun Feb 24 01:03:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2008 00:03:45 -0000
Subject: [issue900744] catch invalid chunk length in httplib read routine
Message-ID: <1203811425.19.0.820745134288.issue900744@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed in r61034, including unittest.

----------
resolution:  -> fixed
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue900744>
____________________________________

From report at bugs.python.org  Sun Feb 24 01:03:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2008 00:03:57 -0000
Subject: [issue1486335] httplib: read/_read_chunked failes with ValueError
	sometime
Message-ID: <1203811437.92.0.0102215564296.issue1486335@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed for bug #900744.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1486335>
_____________________________________

From report at bugs.python.org  Sun Feb 24 01:07:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Feb 2008 00:07:29 -0000
Subject: [issue1367711] Remove usage of UserDict from os.py
Message-ID: <1203811649.25.0.223302335243.issue1367711@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

It's intentional that dict doesn't dynamically bind any calls; to
properly replace the semantics of dict, you have to implement *all* API.
There might be lack of documentation of this aspect, however, that is a
separate issue from the one being discussed here.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367711>
_____________________________________

From report at bugs.python.org  Sun Feb 24 01:15:52 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2008 00:15:52 -0000
Subject: [issue1627] Problem with httplib and Content-Length: -1
In-Reply-To: <1197636721.61.0.0455165758222.issue1627@psf.upfronthosting.co.za>
Message-ID: <1203812152.53.0.277922160966.issue1627@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Fixed in r61035.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1627>
__________________________________

From report at bugs.python.org  Sun Feb 24 01:19:01 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 00:19:01 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203812341.22.0.0855967807271.issue2144@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> dict doesn't dynamically bind any calls; to
> properly replace the semantics of dict, you
> have to implement *all* API.

What was the rationale for this decision?  To me it looks like a hold-
over from the time when dicts were not subclassable.

I agree, this is a topic for python-ideas rather than bug-track, but if 
you could point me to any prior discussions on this issue, it would help 
me to either formulate a specific proposal or drop the issue before more 
electrons are sacrificed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 01:21:15 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sun, 24 Feb 2008 00:21:15 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203812475.42.0.364416417183.issue1725737@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

http://bugs.python.org/issue1095784 proposes to exclude:
.#*  (CVS conflict files, but emacs sometimes also generates them)

*~ would also be a candidate

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Sun Feb 24 01:27:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2008 00:27:21 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203812841.02.0.280738915872.issue2144@psf.upfronthosting.co.za>


Georg Brandl added the comment:

> What was the rationale for this decision?  To me it looks like a hold-
> over from the time when dicts were not subclassable.

I reckon it's faster this way, and you want basic datatypes like dict to
be fast.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 01:28:34 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2008 00:28:34 -0000
Subject: [issue2171] Add map, filter, zip to future_builtins
In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za>
Message-ID: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za>


New submission from Georg Brandl:

And make 2to3 recognize that, not putting a list() around them then.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool), Extension Modules
messages: 62855
nosy: collinwinter, georg.brandl
severity: normal
status: open
title: Add map, filter, zip to future_builtins
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2171>
__________________________________

From report at bugs.python.org  Sun Feb 24 01:28:55 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 24 Feb 2008 00:28:55 -0000
Subject: [issue2171] Add map, filter, zip to future_builtins
In-Reply-To: <1203812914.42.0.434541981805.issue2171@psf.upfronthosting.co.za>
Message-ID: <1203812935.28.0.572078312051.issue2171@psf.upfronthosting.co.za>


Changes by Georg Brandl:


----------
versions: +Python 2.6 -Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2171>
__________________________________

From report at bugs.python.org  Sun Feb 24 01:36:52 2008
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Sun, 24 Feb 2008 00:36:52 -0000
Subject: [issue1524825] ConfigParser: accept leading whitespace on
	options+comments
Message-ID: <1203813412.53.0.132788078579.issue1524825@psf.upfronthosting.co.za>


Quentin Gallet-Gilles added the comment:

I tried to come up with a patch, but the issue isn't as easy as it
seems, the proposed change is too simplistic. Leading spaces in a line
is already used for one purpose : continuations of a previous line. For
instance :
option = value
  continued here
gives "option" as key and "value\n  continued here" as value.

The proposal conflicts with this behavior, since having :
option1 = value1
  option2 = value2
creates only one key-value pair "option1":"value1\n  option2=value2"

Adding blank lines doesn't solve the issue. The only case when it's
treated correctly is when the options is the first one of a
section/file: there's no continuation since there's no previous option
defined.

One solution could be to check for the presence of a delimiter (colon or
equals sign) and not treat it as a continuation if that's the case, but
that could potentially break existing configurations files, since
nothing forbids you from using delimiters in the values.

Any opinion ?

(By the way, the leading whitespaces for comments isn't affected by all
this, the implementation is simple)

----------
nosy: +quentin.gallet-gilles

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524825>
_____________________________________

From report at bugs.python.org  Sun Feb 24 01:38:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Feb 2008 00:38:07 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203812341.22.0.0855967807271.issue2144@psf.upfronthosting.co.za>
Message-ID: <47C0BC6C.80702@v.loewis.de>


Martin v. L?wis added the comment:

> What was the rationale for this decision?  To me it looks like a hold-
> over from the time when dicts were not subclassable.
> 
> I agree, this is a topic for python-ideas rather than bug-track, but if 
> you could point me to any prior discussions on this issue, it would help 
> me to either formulate a specific proposal or drop the issue before more 
> electrons are sacrificed.

Can't find the original discussion right now, but one statement is at

http://www.mailinglistarchive.com/python-dev at python.org/msg01728.html

In essence, inheriting from dict is intentionally unspecified: if you
only change some methods, but not all, the behavior of the
non-overridden methods is unspecified. This is necessary because
a) specifying it would be a lot of work, and
b) specifying it might unreasonable restrict future implementations, and
c) specifying late binding for some of the methods would unreasonably
    slow down their implementation, even if the common case that dict is
    not subclassed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 01:51:26 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 00:51:26 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203814286.31.0.579047871922.issue2144@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The builtins make direct calls to their own internal methods.  This has 
existed for a long time. It would be hard to change without crushing 
performance. Changing it violates Meyer's open-closed principle. And 
changing it also introduces weird, unexpected behaviors (i.e. a 
seemingly innocent method override can break pickling for an object -- 
we had a bug report on this once for dicts and sets).  Also, making 
these kind of changes makes it *much* harder for a builtin to guarantee 
that it invariants are maintained and opening the door for segfaults.

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 02:13:06 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 01:13:06 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203815586.31.0.574973162203.issue2144@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

First, if the new thread on dict behavior does not make sense, please 
see discussion at issue1367711 where it started.  (My mistake following 
up here.)

Second, the ability to subclass built-in type is such a great feature, 
that it is a shame that doing so comes with so many caveats.  The way I 
understand objections to issue1367711 patch is that (1) it is hard to 
derive from dict properly and (2) derived classes may be broken by 
future changes to dict.  The second objection applies to UserDict 
derivation as much as dict derivation, only UserDict is unlikely to be 
touched ever in the future.  As to the first objection, if the burden is 
that all methods have to be overriden, let os.environ lead by example 
and do it.  UserDict is a kludge from the XX century, stdlib should stop 
promoting its use.

Since there is so much resistance to making dict more subclass-friendly, 
what would you say to reimplementing DictMixin in C as say 'dict.mixin'?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 02:21:00 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 01:21:00 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203816059.97.0.373541841891.issue2144@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> The builtins make direct calls to their own internal methods.

Raymond, I guess issue2067 escaped your review. :-)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 02:35:02 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 01:35:02 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203816902.01.0.345714874623.issue2144@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Py3.0 updte:  UserDict is going to survive into Py3.0 and will be moved 
into the collections module.  DictMixin is replaced by the abstract 
base classes for mappings.

I think the discussion here has grown far beyond the original bug 
report.  I recommend this one be closed and that you start a thread on 
python-3000 or python-dev if you want to propose altering basic APIs or 
moving the ABC code into C.

I can't say that I support your "UserDict is a kludge ..." comment.  
The class has its uses and the standard library will continue to use it 
where appropriate.  

FWIW, at one time I also thought all uses of UserDict would ultimately 
be supplanted by dict subclassing, but I found that it was somewhat 
difficult to remove in some circumstances and that its API had some 
advantages (i.e. it's easier to write subclass code like self.data
[computedkey]=computedvalue than to dispatch to dict.__setitem__(self, 
computedkey, computedvalue) -- the latter form is somewhat errorprone 
when the subclass methods become more complex).

Will look at 1367711 as you suggest.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 02:38:59 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 01:38:59 -0000
Subject: [issue1367711] Remove usage of UserDict from os.py
Message-ID: <1203817138.93.0.676301595624.issue1367711@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Recommend closing this one.  There is no point in going on the warpath 
against UserDict.  There are downsides to changing it and almost no 
advantage (saving an import, that's it).  The primary motivation for 
this bug report is the OP's distaste for UserDict.  There doesn't seem 
to be any actual bug or measured performance issue.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367711>
_____________________________________

From report at bugs.python.org  Sun Feb 24 02:57:00 2008
From: report at bugs.python.org (David Kwast)
Date: Sun, 24 Feb 2008 01:57:00 -0000
Subject: [issue1879] sqrt(-1) doesn't raise ValueError on OS X
In-Reply-To: <1200883888.97.0.437374079609.issue1879@psf.upfronthosting.co.za>
Message-ID: <1203818220.25.0.0446261665473.issue1879@psf.upfronthosting.co.za>


David Kwast added the comment:

On OSX 10.5 this behavior is confirmed (Python2.5 and 2.6a). This fix 
appears to be a good fix for python 2.6a.

(Python 2.6a with patch applied)
Python 2.6a0 (trunk:60977M, Feb 23 2008, 19:24:52) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import log,sqrt
>>> sqrt(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error
>>> log(-1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: math domain error

david-kwasts-macbook:python-trunk davidkwast$ ./python 
./Lib/test/test_math.py 
testAcos (__main__.MathTests) ... ok
testAsin (__main__.MathTests) ... ok
testAtan (__main__.MathTests) ... ok
testAtan2 (__main__.MathTests) ... ok
testCeil (__main__.MathTests) ... ok
testConstants (__main__.MathTests) ... ok
testCopysign (__main__.MathTests) ... ok
testCos (__main__.MathTests) ... ok
testCosh (__main__.MathTests) ... ok
testDegrees (__main__.MathTests) ... ok
testExp (__main__.MathTests) ... ok
testFabs (__main__.MathTests) ... ok
testFloor (__main__.MathTests) ... ok
testFmod (__main__.MathTests) ... ok
testFrexp (__main__.MathTests) ... ok
testHypot (__main__.MathTests) ... ok
testIsinf (__main__.MathTests) ... ok
testIsnan (__main__.MathTests) ... ok
testLdexp (__main__.MathTests) ... ok
testLog (__main__.MathTests) ... ok
testLog10 (__main__.MathTests) ... ok
testModf (__main__.MathTests) ... ok
testPow (__main__.MathTests) ... ok
testRadians (__main__.MathTests) ... ok
testSin (__main__.MathTests) ... ok
testSinh (__main__.MathTests) ... ok
testSqrt (__main__.MathTests) ... ok
testTan (__main__.MathTests) ... ok
testTanh (__main__.MathTests) ... ok
test_exceptions (__main__.MathTests) ... ok
test_trunc (__main__.MathTests) ... ok

----------------------------------------------------------------------
Ran 31 tests in 0.011s

OK

----------
nosy: +david.kwast
versions:  -Python 2.5, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1879>
__________________________________

From report at bugs.python.org  Sun Feb 24 03:00:13 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 02:00:13 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203818413.35.0.332042289394.issue2144@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Let's get back on-topic.

I assume you are recommending to close this issue by rejecting the 
patch.  I disagree.  The patch can be fixed to properly override all 
methods and a unit test can be added to guarantee that all dict methods 
are overridden.

The patch has two distinct benefits: (1) UserDict is not loaded on 
startup; and (2) os.environ is faster.  IMHO, these two reasons make the 
patch worth pursuing.

BTW, one of the objections based on exec .. in os.environ behavior (see http://bugs.python.org/msg49131) has become invalid since then.

Specific issues should of course be addressed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 03:02:43 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Feb 2008 02:02:43 -0000
Subject: [issue1879] sqrt(-1) doesn't raise ValueError on OS X
In-Reply-To: <1200883888.97.0.437374079609.issue1879@psf.upfronthosting.co.za>
Message-ID: <1203818563.79.0.681825652543.issue1879@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Thanks for the confirmation, David!

The work in the trunk-math branch should also fix this, in a rather 
better fashion (i.e., without per-platform hacks).  This issue should probably be revisited after it's decided whether to merge trunk-math 
into the trunk before 2.6.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1879>
__________________________________

From report at bugs.python.org  Sun Feb 24 03:13:38 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 02:13:38 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203819218.22.0.269977296259.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Alexander, regarding your comments:

1. sysconf in general returns a long because it can return all sorts of
information, but os.times() returns clock_t items, so the _SC_CLK_TCK
value must comfortably fit into a clock_t. It's preferable to cast into
a clock_t immediately rather than doing a conversion for each of the
ensuing divisions.

2. Do you have indications that such platforms exist? In that case,
indeed the patch should be adapted. Is that -1 return value documented
somewhere?

3. I agree; 0 or -1 would be better.

4. You're right about the overhead, but someone (amk?) measured it and
it's only 5% compared to the old buggy behaviour. It's still possible to
do a million calls to os.times() from Python in a second, which is
plenty fast enough. Clearly the speed could be improved, but it doesn't
appear worth the complications to me.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 03:14:57 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 02:14:57 -0000
Subject: [issue1367711] Remove usage of UserDict from os.py
Message-ID: <1203819297.8.0.583456293489.issue1367711@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

See comments at issue2144.  Benjamin Peterson demonstrated a more than 2x 
speedup on a micro-benchmark.  Plus, the fact that two people were 
motivated enough to independently produce a near-complete patch is worth 
something.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367711>
_____________________________________

From report at bugs.python.org  Sun Feb 24 03:34:01 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 02:34:01 -0000
Subject: [issue1367711] Remove usage of UserDict from os.py
Message-ID: <1203820441.75.0.391209171898.issue1367711@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

I think some variant of these patches was rejected before and part of 
these reason had to do with subtle semantic changes when switching from 
an old-style class (inheriting from UserDict) to a new-style class 
(inheriting from dict).  There were also some concerns that it could 
break code currently relying on isinstance(x, UserDict).

IMO, this just isn't work it.  The os.environ use cases are not 
typically the performance critical part of a script.  This is a false 
optimization.  The primary motivation seems to be that the OP doesn't 
like UserDict.

Looking at the patch, I find the existing code to be more self-
evidently correct and maintainable than the proposed new code.  Though 
this is probably a matter of taste.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367711>
_____________________________________

From report at bugs.python.org  Sun Feb 24 03:40:05 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 02:40:05 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203820805.72.0.03198280632.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> 1. .. It's preferable to cast into a clock_t immediately rather than
> doing a conversion for each of the ensuing divisions.

If that's your motivation, then you should cast to double instead. 
However, I would leave it to compiler to do micro-optimizations like 
these. I am not aware of a standard that says that clock_t must be wider 
than long.  I agree that it is unlikely to produces wrong results given 
that we are realistically talking about 50-1000 range, but on some 
platforms you may see a warning.

> 2. .. Is that -1 return value documented somewhere?

Yes, see man sysconf on a sufficiently unix-like system or http://www.opengroup.org/onlinepubs/009695399/functions/sysconf.html

> 4. You're right about the overhead, but someone (amk?) measured it and
> it's only 5% compared to the old buggy behaviour. It's still possible 
to
> do a million calls to os.times() from Python in a second, which is
> plenty fast enough. Clearly the speed could be improved, but it
> doesn't appear worth the complications to me.

5% is a lot and IIRC os.times is used by some standard python profilers 
and 5% slowdown will affect people.

What I suggest is a simpler solution than your patch:

(1) Define USE_SYSTEM_HZ in config.h (will require some autoconf 
hacking).

(2) Define Py_HZ as system HZ on the systems where HZ can be trusted. 
(Some systems already define HZ as sysconf(_SC_CLK_TCK)) and fix the 
system definition appropriately where necessary.

(3) Replace HZ with Py_HZ in posixmodule.c

The advantage is that the systems where os.times is not broken will not 
be affected.

BTW, does anyone know if sysconf(_SC_CLK_TCK)) result can change during 
process lifetime?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 03:54:09 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 02:54:09 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203821649.49.0.868011934397.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Aha, I should read my own sources:

"The value shall not change during the lifetime of the calling process, 
[XSI]   except that sysconf(_SC_OPEN_MAX) may return different values 
before and after a call to setrlimit() which changes the RLIMIT_NOFILE 
soft limit." 
<http://www.opengroup.org/onlinepubs/009695399/functions/sysconf.html>

So we can consider making ticks_per_sec static and initializing it in 
posixinit.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 04:09:15 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 03:09:15 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203822555.38.0.379645953921.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

FWIW, the following minimal patch fixed the bug on MacOS X and does not 
affect Linux:

===================================================================
--- Modules/posixmodule.c       (revision 61014)
+++ Modules/posixmodule.c       (working copy)
@@ -5923,7 +5923,7 @@
 
 #ifdef HAVE_TIMES
 #ifndef HZ
-#define HZ 60 /* Universal constant :-) */
+#define HZ sysconf(_SC_CLK_TCK)
 #endif /* HZ */
 
 #if defined(PYCC_VACPP) && defined(PYOS_OS2)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 04:18:27 2008
From: report at bugs.python.org (Facundo Batista)
Date: Sun, 24 Feb 2008 03:18:27 -0000
Subject: [issue1742669] "%d" format handling for long values
Message-ID: <1203823107.0.0.704169765067.issue1742669@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r61040. Thanks you all!

----------
resolution:  -> accepted
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1742669>
_____________________________________

From report at bugs.python.org  Sun Feb 24 05:18:42 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Feb 2008 04:18:42 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203826721.96.0.83658462873.issue2144@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I also disagree that UserDict is a clutch, and that inheriting from dict
is in any way more modern or cleaner than inheriting from UserDict.

Hence I'm rejecting this patch. To "appeal", please discuss on python-dev.

----------
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 05:22:38 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 24 Feb 2008 04:22:38 -0000
Subject: [issue1367711] Remove usage of UserDict from os.py
Message-ID: <1203826958.27.0.959508448779.issue1367711@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I'm rejecting this patch, for the same reasons as issue2144. If further
discussion is needed, please discuss on python-dev.

----------
resolution:  -> rejected
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1367711>
_____________________________________

From report at bugs.python.org  Sun Feb 24 05:24:18 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 04:24:18 -0000
Subject: [issue2144] os.environ should inherit dict
In-Reply-To: <1203458212.43.0.398336316745.issue2144@psf.upfronthosting.co.za>
Message-ID: <1203827057.96.0.218559380304.issue2144@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Did anyone mention "clutch"? :-)

Oh, well, please close issue1367711 as a duplicate.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2144>
__________________________________

From report at bugs.python.org  Sun Feb 24 06:09:32 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 05:09:32 -0000
Subject: [issue2172] Add doc-string to UserDict and DictMixin
In-Reply-To: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>
Message-ID: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

Attached patch improves pydoc UserDict presentation.

One of the problems with the current documentation in comments is that 
order of methods is not preserved and thus the method level comments in 
DictMixin implementation are meaningless in pydoc. (In any case the 
comments are not accurate even in the source file.)

If this patch is accepted in principle, the original level comments 
should be removed.  I am leaving them intact to simplify the review.

----------
files: UserDict-doc.diff
keywords: patch
messages: 62876
nosy: belopolsky
severity: normal
status: open
title: Add doc-string to UserDict and DictMixin
Added file: http://bugs.python.org/file9529/UserDict-doc.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2172>
__________________________________

From report at bugs.python.org  Sun Feb 24 06:19:45 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 05:19:45 -0000
Subject: [issue2172] Add doc-string to UserDict and DictMixin
In-Reply-To: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>
Message-ID: <1203830385.99.0.441194908271.issue2172@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky:


Added file: http://bugs.python.org/file9530/UserDict-doc.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2172>
__________________________________

From report at bugs.python.org  Sun Feb 24 06:21:04 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 05:21:04 -0000
Subject: [issue2172] Add doc-string to UserDict and DictMixin
In-Reply-To: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>
Message-ID: <1203830464.61.0.472275924884.issue2172@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Fixed an error in lavels doc.  Needs review.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2172>
__________________________________

From report at bugs.python.org  Sun Feb 24 06:22:46 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 05:22:46 -0000
Subject: [issue2172] Add doc-string to UserDict and DictMixin
In-Reply-To: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>
Message-ID: <1203830566.3.0.293567022082.issue2172@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky:


----------
components: +Documentation
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2172>
__________________________________

From report at bugs.python.org  Sun Feb 24 06:41:34 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Feb 2008 05:41:34 -0000
Subject: [issue923643] long <-> byte-string conversion
Message-ID: <1203831694.26.0.343571387522.issue923643@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

pending -> closed.

----------
status: pending -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue923643>
____________________________________

From report at bugs.python.org  Sun Feb 24 07:18:46 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Feb 2008 06:18:46 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203833925.97.0.542026546603.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Reopening - I disagree with the assertion that this isn't expected to work.

----------
nosy: +ncoghlan
resolution: fixed -> 
status: closed -> open

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 08:00:16 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 07:00:16 -0000
Subject: [issue2172] Add doc-string to UserDict and DictMixin
In-Reply-To: <1203829772.14.0.952967629651.issue2172@psf.upfronthosting.co.za>
Message-ID: <1203836416.79.0.615291951436.issue2172@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


----------
assignee:  -> rhettinger
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2172>
__________________________________

From report at bugs.python.org  Sun Feb 24 08:04:43 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Feb 2008 07:04:43 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203836683.44.0.0429040082957.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Hmm, I can't reproduce any failure using the supplied zip file, even if
I increase the number of threads to 382 (if I set it any higher,
start_new_thread starts to fail). That's with both 2.5.1 and 2.6 SVN.

I'll try again with the original tkinter/urllib script.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 08:10:31 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Feb 2008 07:10:31 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203837031.93.0.921787798666.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Nope, can't reproduce it with the original tkinter/urllib script either
(again, Ubuntu's 2.5.1 release and SVN 2.6, with the thread count set at
350).

Could it be a windows specific problem? Or require a non-hyperthreaded CPU?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 08:15:25 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Feb 2008 07:15:25 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203837325.69.0.786852699187.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ah, never mind - just needed to run the test a few more times to get it
to fail.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 08:38:48 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 24 Feb 2008 07:38:48 -0000
Subject: [issue1517495] memory leak threading or socketserver module
Message-ID: <1203838728.66.0.696387725579.issue1517495@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

It's possible but unlikely that r61011 fixed this. SocketServer creates
the reference cycles it fixed, but they tended to get cleaned up by
gc.collect(), so it sounds like that wasn't the bug you're seeing here.
I haven't had time yet to check, so I'm mentioning it here so the
possibility doesn't get lost.

----------
nosy: +jyasskin

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1517495>
_____________________________________

From report at bugs.python.org  Sun Feb 24 08:40:47 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Feb 2008 07:40:47 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203838847.46.0.142452713738.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Ahah, found the real restrictions - while it turns out the OP's
demonstration code is indeed broken, I think the warning Georg added to
the docs based on Christian's comment above is *far* too strong (hence
my somewhat annoyed message on the checkins list ;).

The actual restriction is given in Py_Finalize(): all pending imports
must be given a chance to finish before the interpreter is torn down. No
new imports should be started after that point.

The threading module takes care of this for you automatically by
registering a system shut down handler that will call the join() method
of all non-daemon threads before the interpreter starts to be torn down.
As daemon threads aren't included in this, all of their imports must be
completed before the thread is switched to daemon mode.

With the thread module, a lot more is left up to the caller (one of the
main reasons this module is being renamed to _thread in Py3k). You can
make the warnings against using *this* module directly as strong as you
want - doing so really can get you in big trouble.

As for the exact nature of the bug in the OP's demonstration code: it
takes no measures to ensure that all imports are complete before the
interpreter is shut down (and in fact deliberately goes out of its way
to break the restriction). While the approach Christian suggests
(perform all your imports from the main thread) is certainly one way to
obey the restriction, it is far from the only way (e.g. use the
threading module, and have any daemon threads only flag themselves as
such once they finish their imports).

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 08:50:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Feb 2008 07:50:22 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203839422.07.0.148907603502.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Correction to previous comment: you can't safely perform imports from
daemon threads at all, as you have to set their daemon status before you
start them.

So, to be able to safely import from a thread other than the main thread:
- it must be created by the threading module, or otherwise guaranteed to
be terminated when the interpreter exits
- if created through the threading module, it must not be set to daemon mode

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 08:55:02 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 24 Feb 2008 07:55:02 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203839702.23.0.578745342394.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

And one other restriction: the thread performing the import must not be
spawned as a side effect of importing a module (as this will deadlock
the interpreter)

The effect of disobeying the two restrictions in my previous comment
will be intermittent crashes at shutdown, such as those experienced by
the original poster of this bug report.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Sun Feb 24 09:04:37 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 24 Feb 2008 08:04:37 -0000
Subject: [issue1910] Document that with is slower than try/finally
In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za>
Message-ID: <1203840277.05.0.842039082014.issue1910@psf.upfronthosting.co.za>


Changes by Jeffrey Yasskin:


----------
nosy: +jyasskin

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1910>
__________________________________

From report at bugs.python.org  Sun Feb 24 09:56:43 2008
From: report at bugs.python.org (Eh Tan)
Date: Sun, 24 Feb 2008 08:56:43 -0000
Subject: [issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so
In-Reply-To: <1189921072.53.0.557521657427.issue1167@psf.upfronthosting.co.za>
Message-ID: <1203843403.46.0.966332574565.issue1167@psf.upfronthosting.co.za>


Eh Tan added the comment:

According to gdbm NEW, the dbm/ndbm compatibility routines was moved to
libgdbm_compat in v1.8.1, which was released in late 2002.

The patch works for gdbm-1.8.1+. But I am afraid that the patch will
cause build error with gdbm-1.8.0 and earlier version. A more
sophisticated approach is needed. The approach will do the following:

1. find gdbm library and gdbm/ndbm.h header
2. check the presence of dbm_open() function in gdbm library
3. if present, link with gdbm
4. if not, link with gdbm_compat

Step 1 and 3 are already in setup.py. The patch adds step 4, but step 2
is missing.

I don't have enough skill in distutil to implement it though...

----------
nosy: +tan2

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1167>
__________________________________

From report at bugs.python.org  Sun Feb 24 10:13:33 2008
From: report at bugs.python.org (Eh Tan)
Date: Sun, 24 Feb 2008 09:13:33 -0000
Subject: [issue1706863] Failed to build Python 2.5.1 with sqlite3
Message-ID: <1203844413.92.0.0128312143366.issue1706863@psf.upfronthosting.co.za>


Eh Tan added the comment:

The problem is at line 890, setup.py, r60970.

sqlite_libfile = self.compiler.find_library_file(                      
           
                     sqlite_dirs_to_check + lib_dirs, 'sqlite3')
sqlite_libdir = [os.path.abspath(os.path.dirname(sqlite_libfile))]
                                                                       
       

self.compiler.find_library_file() will return None if the library is not
found. The code passes None to os.path.dirname and cause the error.

----------
nosy: +tan2

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1706863>
_____________________________________

From report at bugs.python.org  Sun Feb 24 10:19:13 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sun, 24 Feb 2008 09:19:13 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203844753.38.0.046673977233.issue2168@psf.upfronthosting.co.za>


Changes by Thomas Herve:


----------
keywords: +patch
Added file: http://bugs.python.org/file9531/dbm.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Sun Feb 24 10:19:14 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 09:19:14 -0000
Subject: [issue1910] Document that with is slower than try/finally
In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za>
Message-ID: <1203844754.09.0.570234809118.issue1910@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, we don't usually document relative speeds (or even O(n) 
performance).  Those things are implementation dependent and can vary 
across releases.

In the case of the with-statement, it would seem self-evident 
that "with" does everything try/finally does and adds function call 
overhead, the __enter__/__exit dance, and possibly introducing a 
locally scoped variable with the "as" clause.

----------
status: pending -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1910>
__________________________________

From report at bugs.python.org  Sun Feb 24 10:19:21 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sun, 24 Feb 2008 09:19:21 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203844761.37.0.3203517997.issue2168@psf.upfronthosting.co.za>


Changes by Thomas Herve:


Added file: http://bugs.python.org/file9532/gdbm.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Sun Feb 24 10:20:55 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sun, 24 Feb 2008 09:20:55 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203844855.68.0.0588286825336.issue2168@psf.upfronthosting.co.za>


Thomas Herve added the comment:

Attached files add contains method to dbm and gdbm objects. It fixes
failures with test_shelve. I'm ready to add more tests for this, but
#1960 should probably go in first (it converts the tests to unittest,
and add some coverage).

Please review!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Sun Feb 24 10:30:26 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 09:30:26 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203845426.42.0.494145248256.issue2168@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

The patch looks good to my eye, but I can't test it directly.  Will 
apply and see what the buildbots think about it.

----------
nosy: +rhettinger
priority:  -> high

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Sun Feb 24 10:31:03 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 24 Feb 2008 09:31:03 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203845463.29.0.690362059856.issue2168@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


----------
assignee:  -> rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Sun Feb 24 11:26:30 2008
From: report at bugs.python.org (Michael Otteneder)
Date: Sun, 24 Feb 2008 10:26:30 -0000
Subject: [issue2173] Pyton fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>


New submission from Michael Otteneder:

Python seems to fail silently when LANG enviroment variable is set to a
bad value. In Mac OS X Leopard it is set too UTF-8 for instance which
does not seem to be valid. Python fails building the modules during make
and the generated python.exe is unable to output anything. Setting the
LANG variable to C or some other valid value fixes the problem. But I
suppose python should fail more verbose in case of a bad locale,or maybe
it should fallback to a standard locale.

----------
components: Interpreter Core
messages: 62892
nosy: motteneder
severity: normal
status: open
title: Pyton fails silently on bad locale
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
__________________________________

From report at bugs.python.org  Sun Feb 24 12:26:50 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 24 Feb 2008 11:26:50 -0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1203852410.12.0.841046967025.issue1738@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

The documentation doesn't say anything about dircmp being supposed to 
support pattern matching. This ticket is a feature request rather than a 
bug.

----------
components: +Library (Lib) -None
nosy: +vdupras
type: behavior -> feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
__________________________________

From report at bugs.python.org  Sun Feb 24 13:40:32 2008
From: report at bugs.python.org (John J Lee)
Date: Sun, 24 Feb 2008 12:40:32 -0000
Subject: [issue841728] urllib and cookie module improvements
Message-ID: <1203856832.79.0.112128761177.issue841728@psf.upfronthosting.co.za>


John J Lee added the comment:

This should be closed.

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue841728>
____________________________________

From report at bugs.python.org  Sun Feb 24 13:43:57 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2008 12:43:57 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203857037.19.0.343256320887.issue1040026@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Hi Alexander,

> 5% is a lot and IIRC os.times is used by some standard python profilers 
> and 5% slowdown will affect people.

Profiled runs are always slower than non-profiled runs, so I'm not
convinced it is very important. You use profiling only when you need it,
not in normal production conditions.

However, fetching the value only once and then caching it is a valid
approach, so you can produce an updated patch for that if you want :-)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 14:10:52 2008
From: report at bugs.python.org (Mike Beachy)
Date: Sun, 24 Feb 2008 13:10:52 -0000
Subject: [issue1729305] test_doctest fails when run in verbose mode
Message-ID: <1203858652.36.0.808864306435.issue1729305@psf.upfronthosting.co.za>


Mike Beachy added the comment:

The basic issue here is that running in verbose mode echoes back the
expected values from the file, so the results from non-ascii doctest
files must be encoded before printing.

It looks to me like the DocTestRunner class must grow an '_encoding'
attribute to keep track of how to encode any verbose output. I've
attached a patch that does this.

Happy post bug day!
Mike

----------
keywords: +patch
nosy: +mbeachy
Added file: http://bugs.python.org/file9533/doctest.patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729305>
_____________________________________

From report at bugs.python.org  Sun Feb 24 14:12:37 2008
From: report at bugs.python.org (Mike Beachy)
Date: Sun, 24 Feb 2008 13:12:37 -0000
Subject: [issue1729305] test_doctest fails when run in verbose mode
Message-ID: <1203858757.55.0.49815816374.issue1729305@psf.upfronthosting.co.za>


Mike Beachy added the comment:

Here's a patch for test_doctest.py that checks the problem has been fixed.

Added file: http://bugs.python.org/file9534/test_doctest.patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1729305>
_____________________________________

From report at bugs.python.org  Sun Feb 24 14:19:42 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Sun, 24 Feb 2008 13:19:42 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203859182.6.0.247634911556.issue1533@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

According to the documentation
(http://docs.python.org/dev/library/functions.html) "The arguments must
be plain integers", so I think the wrong thing here is to run the
object's __int__() under the range()'s hood. I think the right thing to
do would be to explicitly invoke int() on passing an non-int argument as
parameter.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Sun Feb 24 14:48:43 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 13:48:43 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1203860923.39.0.308466444336.issue1657@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I've updated the patch. The latest patch didn't contain the unit tests
and it failed to apply cleanly, too.

Added file: http://bugs.python.org/file9535/trunk_select_epoll_kqueue9.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Sun Feb 24 14:48:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 13:48:55 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1203860935.43.0.0441835844665.issue1657@psf.upfronthosting.co.za>


Changes by Christian Heimes:


Removed file: http://bugs.python.org/file9019/trunk_select_epoll_kqueue5.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Sun Feb 24 14:49:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 13:49:00 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1203860940.88.0.653837321659.issue1657@psf.upfronthosting.co.za>


Changes by Christian Heimes:


Removed file: http://bugs.python.org/file9029/trunk_select_epoll_kqueue7.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Sun Feb 24 14:49:04 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 13:49:04 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1203860944.98.0.9799310348.issue1657@psf.upfronthosting.co.za>


Changes by Christian Heimes:


Removed file: http://bugs.python.org/file9027/trunk_select_epoll_kqueue6.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Sun Feb 24 14:49:10 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 13:49:10 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1203860950.13.0.293227981674.issue1657@psf.upfronthosting.co.za>


Changes by Christian Heimes:


Removed file: http://bugs.python.org/file9241/trunk_select_epoll_kqueue8.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Sun Feb 24 14:52:32 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 13:52:32 -0000
Subject: [issue2174] xml.sax.xmlreader does not support the InputSource
	protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>


New submission from Yitz Gale:

In the documentation for xml.sax.xmlreader.InputSource objects
(section 8.12.4 of the Library Reference) we find that
users of InputSource objects should use the following
sequence to get their input data:

1. If the InputSource has a character stream, use that.
2. Otherwise, if the InputSource has a byte stream, use that.
3. Otherwise, open a URI connection to the system ID.

The parse() method of IncrementalParser skips step 1.

In addition, we need to add a method
getSourceEncoding() to the XMLReader interface;
if non-null, it will indicate to the parser that
the input is a byte stream in the given encoding.

The documentation should indicate what the parser
should do if the XML itself announces that its
encoding is something else. I propose that the parser should
be required to raise an error in that case.

See also #1483.

----------
components: Documentation, Library (Lib), XML
messages: 62900
nosy: ygale
severity: normal
status: open
title: xml.sax.xmlreader does not support the InputSource protocol
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:03:03 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 14:03:03 -0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>


New submission from Yitz Gale:

The expat sax parser in xml.sax.expatreader
does not fully support the InputSource protocol
in xml.sax.xmlreader. It only accepts
byte streams. It ignores the encoding
indicated in the InputStream object and
only uses the encoding read from
the XML or defaults to UTF-8.

Rather than silently doing the wrong thing,
it should raise an error when fed a character stream,
or when given an encoding, via the InputSource
interface.

And most importantly, these limitations should be mentioned
in the documentation.

----------
components: Documentation, Extension Modules, Library (Lib), Unicode, XML
messages: 62901
nosy: ygale
severity: normal
status: open
title: Expat sax parser silently ignores the InputSource protocol
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:04:32 2008
From: report at bugs.python.org (Jakub Fedyczak)
Date: Sun, 24 Feb 2008 14:04:32 -0000
Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class
Message-ID: <1203861872.93.0.0923841494352.issue2176@psf.upfronthosting.co.za>


Changes by Jakub Fedyczak:


----------
components: Documentation
nosy: bukaj
severity: normal
status: open
title: Undocumented lastrowid attribute i sqlite3 cursor class
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2176>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:06:50 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 14:06:50 -0000
Subject: [issue1483] xml.sax.saxutils.prepare_input_source ignores character
	stream in InputSource
In-Reply-To: <1195653795.8.0.542576278207.issue1483@psf.upfronthosting.co.za>
Message-ID: <1203862010.4.0.956181306486.issue1483@psf.upfronthosting.co.za>


Yitz Gale added the comment:

Sure. Here is a simple test case:

  def testUseCharacterStream(self):
    '''If the source is an InputSource with a character stream, use 
it.'''
    src = xml.sax.xmlreader.InputSource(temp_file_name)
    src.setCharacterStream(StringIO.StringIO(u"foo"))
    prep = xml.sax.saxutils.prepare_input_source(src)
    self.failIf(prep.getCharacterStream() is None, "ignored character 
stream")

If "temp_file_name" is omitted, you'll get an
AttributeError, and if you put it in but the
file doesn't exist, you'll get an IOError.

I'm attaching an almost full set of tests.
It omits the case of a URL. You can easily
put that in if you have a handy function that
converts a file path to a file URL, with all
the fidgety stuff you need for Windows. (Does that
already exist somewhere?)

Unfortunately, I now see that the problem
is a bit deeper than this. There are two more
related bugs that need to be fixed before
this really works.

See #2174 and #2175.

Added file: http://bugs.python.org/file9536/test_prepare_input_source.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1483>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:09:12 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 14:09:12 -0000
Subject: [issue2175] Expat sax parser silently ignores the InputSource protocol
In-Reply-To: <1203861783.69.0.636987169656.issue2175@psf.upfronthosting.co.za>
Message-ID: <1203862152.13.0.686593368607.issue2175@psf.upfronthosting.co.za>


Yitz Gale added the comment:

See also: #1483 and #2174.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2175>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:09:58 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 14:09:58 -0000
Subject: [issue2174] xml.sax.xmlreader does not support the InputSource
	protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1203862198.53.0.635544242483.issue2174@psf.upfronthosting.co.za>


Yitz Gale added the comment:

See also: #1483 and #2175.

----------
components: +Unicode

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:12:52 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 14:12:52 -0000
Subject: [issue1306] Embedded python reinitialization
In-Reply-To: <1192887310.11.0.424828418654.issue1306@psf.upfronthosting.co.za>
Message-ID: <1203862372.36.0.773299584982.issue1306@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I've fixed the bug in Python 3.0 a few weeks ago. I'm not sure about the
stackless bug but this is the wrong place to report it. Please contact
the other Christian.

----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1306>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:13:28 2008
From: report at bugs.python.org (Jakub Fedyczak)
Date: Sun, 24 Feb 2008 14:13:28 -0000
Subject: [issue2176] Undocumented lastrowid attribute i sqlite3 cursor class
In-Reply-To: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za>
Message-ID: <1203862408.41.0.133171732382.issue2176@psf.upfronthosting.co.za>


New submission from Jakub Fedyczak:

con = sqlite3.connect("file")
c = con.cursor()
c.execute("INSERT INTO .....")
last_id = c.lastrowid <--- nothing about it in the docs

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2176>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:18:29 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 14:18:29 -0000
Subject: [issue2174] xml.sax.xmlreader does not support the InputSource
	protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1203862709.16.0.350903771401.issue2174@psf.upfronthosting.co.za>


Yitz Gale added the comment:

Hmm. When getSourceEncoding() is None, there needs to be some
way for the parser to distinguish between the cases where it
is getting pre-decoded Unicode through a character stream,
or where it is getting a byte stream with an unspecified
encoding. In the latter case, it will have to look in the
XML for an encoding declaration, or use UTF-8 by default).

Note that expat only can handle the latter case.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
__________________________________

From report at bugs.python.org  Sun Feb 24 15:25:38 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Sun, 24 Feb 2008 14:25:38 -0000
Subject: [issue839159] iterators broken for weak dicts
Message-ID: <1203863138.5.0.310232964435.issue839159@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

I made a patch to fix the problem. The cleaning up of they weakref keys or 
values will be held until all references to iterators created by the 
weakdict are dead.

I also couldn't resist removing code duplication of code in items(), 
keys() and values().

At first, I couldn't understand why this whole remove(), _remove() and 
selfref() mechanism was in place. I had removed them and replaced them 
with methods, and the tests still passed. Then I realized it was to make 
sure keys and values didn't prevent the weak dicts from being freed. I 
added tests for this.

----------
keywords: +patch
nosy: +vdupras
type:  -> behavior
versions: +Python 2.6
Added file: http://bugs.python.org/file9537/weakref_dict_iter.diff

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue839159>
____________________________________

From report at bugs.python.org  Sun Feb 24 15:53:30 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 14:53:30 -0000
Subject: [issue2174] xml.sax.xmlreader does not support the InputSource
	protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1203864810.15.0.0554571432412.issue2174@psf.upfronthosting.co.za>


Yitz Gale added the comment:

So I think there are two possibilities:

1. Use a special value for getSourceEnconding(),
like "unicode", to indicate that this is a
unicode character stream and not a byte stream.

2. Provide yet another method in the XMLReader
interface: sourceIsCharacterStream(), returning
a bool.

There is a more drastic option:

3. Since expat doesn't support this stuff
anyway, and perhaps not too many people
have written parsers that do support it,
dumb down the InputSource interface.

Specifically, deprecate setCharacterStream(),
getCharacterStream(), setEncoding() and
getEncoding(), none of which are used by
expat. Parsers should read the XML from
the byte stream and use that to determine
the encoding.

That may upset some implementors of XML
libraries though. They would each have to go
to some trouble to provide their own
proprietary and possibly incompatible
mechanisms for this, if they need it.

Perhaps a compromise fourth path would
be to have subclasses of InputSource for
the two cases of character stream and
byte stream.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
__________________________________

From report at bugs.python.org  Sun Feb 24 16:29:45 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 15:29:45 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203866985.51.0.557317114256.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Alexander, speed-wise your patch is worse than the original one on
systems where HZ isn't predefined, because it calls sysconf 5 times in
each call to os.times, rather than only once per call.

If you worry about speed, the approach outlined in Antoine's last
message makes most sense to me. Doing this in the configure script
appears dangerous to me; it is well possible that the clock tick value
changes over time on the same machine (e.g. after a kernel upgrade), so
this should be determined upon process initialization, not before
compilation.

Also, I don't think that the HZ value should be preferred to the sysconf
value if both are available, as all times man pages I could check
mention sysconf as the correct way to do this, not HZ. (Some of them
state that HZ is used on "older systems".)

Finally, your patch assumes that HAVE_TIMES implies HAVE_SYSCONF; is
that guaranteed? In particular, it's not clear to me what happens on
Windows (see comment at the top of the file). I also have no idea how
any of the earlier patches behaves on Windows, unfortunately.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 16:39:24 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 15:39:24 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203867564.8.0.00552436290157.issue1040026@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I suggest that you define "static int hz" and assign a value to the var
in INITFUNC().

#ifdef HZ
hz = HZ;
#elif defined(HAVE_SYSCONF)
hz = sysconf(_SC_CLK_TCK);
#else
hz = 60; /* It's 50Hz in Europe */
#endif

----------
nosy: +tiran

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 16:46:23 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 15:46:23 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203867982.98.0.565361507457.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Tiran, that's the general approach we should follow, yes.

But the people who discussed this on #python-dev all felt a bit queasy
about the "60" fallback -- this is what caused the bug in the first
place on Guido's and my machine. (A value of 60 was assumed; 100 would
have been correct.) Having no such fallback would be preferable, unless
it's necessary.

You use Windows, right? Can you test if that fallback is necessary
there? As far as I can tell, it should not be necessary on a more
UNIX-ish system.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 16:53:51 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 15:53:51 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203868431.05.0.277154875296.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Never mind, on Windows a different code path is chosen.
I'm now working on a patch that computes the hz value during module
initialization. So should I keep the 60 magic value? What is the
justification?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 16:57:57 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 15:57:57 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203868677.33.0.694092443187.issue1040026@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I don't *use* Windows except for some computer games. But I'm doing some
development for Python on Windows in a VMWare box. I'm going to check HZ
for you. Give me a couple of minutes to boot the image.

How do you like this idea. Since HZ is only used in posix_times it's
fine to cache it in a local static var.

static PyObject *
posix_times(PyObject *self, PyObject *noargs)
{
	static int hz = -1;
	struct tms t;
	clock_t c;

	if (hz == -1) {
		/* Py_HZ may call sysconf(), cache the value */
		hz = Py_HZ;
	}
	errno = 0;
	...

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 17:23:39 2008
From: report at bugs.python.org (Thomas Herve)
Date: Sun, 24 Feb 2008 16:23:39 -0000
Subject: [issue2177] Update compiler module to handle class decorators
In-Reply-To: <1203870219.45.0.496617339478.issue2177@psf.upfronthosting.co.za>
Message-ID: <1203870219.45.0.496617339478.issue2177@psf.upfronthosting.co.za>


New submission from Thomas Herve:

The attached patch (tries to?) updates compiler to handle class
decorators, and also to handle the new way decorated function are
handled. I had a weird bug because it seems that ast.py was modified at
hand last time (r51330).

This fixes the recent failures in the buildbot slaves.

Please review!

----------
components: Library (Lib)
files: compiler.diff
keywords: patch
messages: 62915
nosy: therve
severity: normal
status: open
title: Update compiler module to handle class decorators
versions: Python 2.6
Added file: http://bugs.python.org/file9538/compiler.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2177>
__________________________________

From report at bugs.python.org  Sun Feb 24 17:40:27 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 24 Feb 2008 16:40:27 -0000
Subject: [issue2110] Implement __format__ for Decimal
In-Reply-To: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>
Message-ID: <1203871227.19.0.215972136099.issue2110@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

Here's a first attempt at Decimal.__format__; the patch is against the 
trunk, and should be forward ported as usual to 3.0, with obvious minor 
changes related to str/unicode.  It still needs some cleanup and some 
more tests, but I'm posting it now in the hope of getting some feedback.

I'm adding Raymond Hettinger and Eric Smith to the nosy list in case 
they want to comment.

Some points of interest:

 * I decided to make plain 'e', 'f' and 'g' formats (without an explicit 
precision) do no rounding:  they return a string that captures the exact 
value of the Decimal instance (though it can lose information about 
significant zeros).  So format(x, 'e') is basically a way to say 'give 
me str(x), but always include an exponent', and format(x, 'f') gives a 
way to print the value without ever including an exponent.  format(x, 
'g') is identical to str(x), except that it always uses the character 
'e' for an exponent (instead of using 'e' or 'E' depending on the 
context).

There are other possible options here (have a default precision;  use 
the precision from the context), but this one seemed to make most sense.  
I'd appreciate opinions.

 * the integer format specifiers are not supported.  After noticing that
the integer format specifiers aren't supported for floats either, I 
think this is the right thing to do.

 * the 'n' format specifier is not supported either;  it's supposed to 
use the current locale.  I can't find any easy way to do this---it seems 
as though the only real option is to manually fix the decimal point 
character, figure out where to place thousands separators, etc.  This 
would add quite a lot of not-really-Decimal-related code to decimal.py, 
and I'm reluctant to do that.  The right solution probably involves 
writing some support code and putting it somewhere else in the std. lib.

 * on the subject of not-really-Decimal-related code, it would be great
if the parse_format_specifier and format_align functions (near the end 
of decimal.py) could be moved somewhere else.  I'm planning to reuse 
these functions for Fraction.__format__.

----------
keywords: +patch
nosy: +eric.smith, rhettinger
versions: +Python 2.6
Added file: http://bugs.python.org/file9539/decimal_format.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2110>
__________________________________

From report at bugs.python.org  Sun Feb 24 18:03:10 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 17:03:10 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203872590.24.0.931154805151.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Here is an updated patch (os_times4.PATCH) that incorporates Christian's
suggestions. The patch includes the new unit test, so test_posix?.PATCH
need not be applied separately.

I again made the unit test a bit more lenient to allow an absolute error
of 0.02 seconds, as there may be systems where the clock tick
granularity is only 1/60 seconds, and then the old tolerance of 0.015
seconds would be too low.

This patch prefers sysconf where it is available; this is what "man 2
times" asks to do. If sysconf is available but produces an error, that
error is raised. (Errors should never pass silently.) HZ is only used if
sysconf is not available. If neither sysconf nor HZ is available, a
compile-time error is raised -- in that case, HAVE_TIMES shouldn't have
been defined in the first place.

I also timed this; there is no discernible change compared to the old
behaviour.

The patch fixes the buggy behaviour on my 64-bit Linux box and makes no
difference on my 32-bit Linux box. The new unit test passes on both
machines.

Added file: http://bugs.python.org/file9540/os_times4.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 18:59:41 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 17:59:41 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203875981.18.0.00744372461889.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Here is my take (posixmodule.diff).  When ticks per seconds cannot be 
determined, python should not provide times rather than refuse to build.  
Initialization moved to the init function.

----------
keywords: +patch
Added file: http://bugs.python.org/file9541/posixmodule.diff

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 19:10:30 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 18:10:30 -0000
Subject: [issue2177] Update compiler module to handle class decorators
In-Reply-To: <1203870219.45.0.496617339478.issue2177@psf.upfronthosting.co.za>
Message-ID: <1203876630.94.0.45520128627.issue2177@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> jhylton
nosy: +jhylton
priority:  -> urgent
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2177>
__________________________________

From report at bugs.python.org  Sun Feb 24 19:14:38 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 18:14:38 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203876878.28.0.315772663165.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

I'd prefer a noisy compile error, since in situations where times is
available but unusable, HAVE_TIMES shouldn't have been #defined in the
first place. (That is, I'd see that as a bug in the configure script.)

But this is turning into a bikeshed discussion. I care more about the
bug being fixed than about how precisely it is fixed. For the record,
Alexander's patch fixes the bug on my Linux box, too, so I'm fine with
either patch.

If Alexander's patch ends up being applied, I suggest ripping the new
unit test from os_times4.PATCH, since the timing in test_posix4.PATCH is
fragile as mentioned above.

Either way, this looks ready to be closed to me.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 19:40:13 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 18:40:13 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203878413.69.0.413805246791.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> I'd prefer a noisy compile error ..

That would be fine if you could verify that none of the currently 
supported platforms will be affected. I would still feel uneasy about 
refusing to build python simply because os.times is not ported to a 
platform.

> HAVE_TIMES shouldn't have been #defined in the
> first place. (That is, I'd see that as a bug in
> the configure script.)

No, defined HAVE_TIMES only tell you that the system has 'times' 
function in the C library.  It is not intended to mean that os.times is 
implementable.

Personally, I would still prefer a one-line change that I proposed 
above.  It is obviously better than the current smiley code and if it 
happens to fix the platforms where errant behavior was observed, it is 
worth applying even if theoretically it may be wrong.

In any case, there is plenty of material here for a developer to step in 
and close the issue.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 19:43:22 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2008 18:43:22 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203878601.95.0.373550013089.issue1040026@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

IMO, if there is no available way to compute HZ, a NotImplementedError
should be raised rather than using the 60 magic value.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 19:52:01 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 18:52:01 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203879121.04.0.259120165081.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

>> I'd prefer a noisy compile error ..
>
> That would be fine if you could verify that none of the currently 
> supported platforms will be affected. I would still feel uneasy about 
> refusing to build python simply because os.times is not ported to a 
> platform.

Unless I'm missing something, your suggested one-line change fails to
compile in exactly the same cases -- if HAVE_TIMES is defined, but HZ
and sysconf unavailable -- but with a worse error message.

> HAVE_TIMES shouldn't have been #defined in the
> first place. (That is, I'd see that as a bug in
> the configure script.)

> No, defined HAVE_TIMES only tell you that the system has 'times' 
> function in the C library.  It is not intended to mean that os.times
> is implementable.

Sure, but if times is in the standard library, but its output is
uninterpretable, then there's something wrong going on that needs to be
fixed rather than swept under the rug.

> Personally, I would still prefer a one-line change that I proposed 
> above.  It is obviously better than the current smiley code and if it 
> happens to fix the platforms where errant behavior was observed, it is 
> worth applying even if theoretically it may be wrong.

You complained in msg62869 about the original patch that calling sysconf
on every call leads to an unacceptable slowdown. Your one-line patch
calls sysconf five times on each call when HZ is not defined.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 19:53:26 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 18:53:26 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203879206.75.0.67888937303.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

s/standard library/system library/, of course.
Also, the original code is wrong in preferring HZ over the sysconf value.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 19:55:46 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 18:55:46 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203879346.76.0.0718391849157.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Antoine, none of the recently proposed patches uses the 60 magic value.

Alexander's patch doesn't define times in that case (leading to an
AttributeError when trying to call os.times) while my patch complains
about the bogus environment during compilation.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 19:59:00 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2008 18:59:00 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203879540.4.0.476700335408.issue1040026@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

I think it's better to make it a runtime error (upon invocation of
os.times()), rather than a compile-time error. But it's quite
theoretical until we find a system where the error does occur, anyway :)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 20:07:34 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 19:07:34 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203880054.15.0.904006094241.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> You complained in msg62869 about the original patch that calling 
sysconf
> on every call leads to an unacceptable slowdown. Your one-line patch
> calls sysconf five times on each call when HZ is not defined.

That's why I said that was a matter of personal preference.  I use 3 
different systems: i386 linux, x86_64 linux and Mac OS X and the last is 
not mission critical.  On i386 linux HZ is already defined as sysconf 
call, on x86_64 HZ is defined as 100 and it happens to be the correct 
value.  On MacOS X, HZ is not defined, and os.times exhibits the bug. 
One-line patch will make MacOS X behave the same as i386 Linux, which is 
fine for me, but I will oppose any changes that affect x86_64 linux 
performance.

Does anyone know of a platform where HZ is defined to a wrong value?  WE 
may want to undef or redefine HZ on such platforms.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 20:11:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 24 Feb 2008 19:11:06 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203880266.19.0.528321577968.issue1040026@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

> but I will oppose any changes that affect x86_64 linux 
performance.

Alexander, as I said I'm really curious about any situation where
os.times() is so performance-critical that a 5% slowdown for that
function call is unacceptable. Even when a profiler is involved,
os.times() is not the only overhead added by profiling, there is also
all the bookkeeping needed for recording various statistics... Perhaps
by profiling the profiler we would have an answer :)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 20:22:47 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 19:22:47 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203880967.05.0.554428596959.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Alexander, your one-line patch *does* affect performance on my 64-bit
Linux machine in a worse way than any other proposed patch by calling
sysconf five times. HZ may be defined on your machine, but it isn't on
my (Xeon) machine.

I checked man pages on four different Linuxes (32 bit and 64 bit; SuSE,
Fedora, Ubuntu; recent or six years old). All of them state that using
the sysconf value is the right thing to do. This is also stated in the
man page excerpt in Guido's original bug report.

Neither your latest patch (posixmodule.diff) not my latest patch
(os_times4.PATCH) affects performance; they both only call sysconf once
and then used a cached value.

I'm perfectly fine with your posixmodule.diff, which also meets
Antoine's criteria. I suggest we apply that patch, along with the unit
test from os_times4.PATCH, and be done with it.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 20:47:16 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 19:47:16 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203882436.95.0.918172863507.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

>  HZ may be defined on your machine, but it isn't on my (Xeon) machine.

Are you sure?  Please note that HZ will not show up in grep -w HZ 
/usr/include because the right header file further up the tree.

On Solaris:
/usr/include/sys/param.h:#define        HZ              
((clock_t)_sysconf(_SC_CLK_TCK))

On 32-bit Linux:
/usr/include/asm-i386/param.h:#define HZ sysconf(_SC_CLK_TCK)

On 64-bit Linux:
/usr/include/asm-x86_64/param.h:#define HZ 100

Did you try to run posixmodule.c through gcc -E on your system?

I should not play devil's advocate and argue against my own patch, but 
there are two issues:

1. If a system provides non-standard HZ, is it to be preferred to 
sysconf(..)?  Are there systems with correct HZ but no sysconf?

2. Is the added complexity of #ifdef dance justified for the performance 
improvements on some platforms?  I know it looks like I am flip-flopping 
here, but I just don't want to change anything on the platforms where 
os.times is not broken and use a solution that is know to work on some 
platforms to fix the bug where it shows up.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 21:12:00 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 20:12:00 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203883920.78.0.0406361725147.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

If I remove the "#define 60" line in an unmodified posixmodule.c from
trunk, I get the following compiler error:

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE  -c
./Modules/posixmodule.c -o Modules/posixmodule.o
./Modules/posixmodule.c: In function posix_times:
./Modules/posixmodule.c:5964: error: HZ undeclared (first use in this
function)

So yes, HZ isn't available there. It sure is defined *somewhere* (grep
shows a definition in /usr/include/asm-x86_64/param.h), but it isn't
anywhere Python would pick it up.

And I don't really see why it should when the man pages all argue that
using HZ for times is for "older system" (this is a man page from 2002,
no less!). Can you measure a performance difference between your patch
and the old buggy behaviour? I couldn't, on any machine, and I'd be very
surprised if it existed. There is no significant difference between
dividing by a constant and diving by a static module variable, and, as
Antoine rightly suggests, any such difference would be completely lost
in the noise considering the hefty cost of the other operations.

Regarding your two issues:
1. Yes, the sysconf value should take precedence over HZ, since this is
what "man 2 times" says you should use.
2. Personally, I'd be just as fine with the original patch that doesn't
have the code complexity of the value caching, but I'm fine with
anything that fixes the bug. Keeping the old behaviour where possible
"for old time's sake" seems a bad idea -- there were at least two broken
platforms (Mac OS and Xeon), and there may be others. Using the
documented behaviour (sysconf) where available is a much better
solution; honestly, sticking to using HZ as a default without support
for that from any documentation has a cargo-cult programming smell to me.

I don't know if there are platforms that have times, but neither sysconf
nor HZ. That sounds very strange to me, but of course I can't rule it
out. But if there are, it is likely that os.times was broken before on
these platforms -- it was broken on two platforms that I wouldn't
consider minor. In that case, it will still be broken, but at least now
we have a unit tests that detects this.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 21:13:15 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 20:13:15 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203883995.24.0.732592520221.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

In the first line of my previous message, I mean "#define HZ 60", of course.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 21:37:03 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 20:37:03 -0000
Subject: [issue1040026] os.times() is bogus
In-Reply-To: <1203883995.24.0.732592520221.issue1040026@psf.upfronthosting.co.za>
Message-ID: <47C1D56B.20809@cheimes.de>


Christian Heimes added the comment:

Guys, please don't waste too much time on this issue! The tracker still
has more than 1,700 open issues for to debate on. While I enjoy the
fact, that you three are enthusiastic, I strongly feel the urge to
re-route your men power. This bug isn't important enough to waste your
precious time on it.

My opinion as junior core developer is:

sysconf(_SC_CLK_TCK) is the winner and it should be used instead of HZ
when available. A default value should not be used because it will lead
to wrong data. Wrong results are worse than no results.

Since calls to sysconf seem to cost several CPU cycles "clk_tck" should
be cached somehow. I prefer a local static variable in the function but
a static var on file level is fine, too.

The compilation of Python must not fail. When neither HZ nor sysconf is
available but HAVE_TIMES is defined then the function must not be
included. Either you skip the function plus undef HAVE_TIMES or you add
some code to configure.in that does it earlier. The C89 standard doesn't
define #warn so that not an option, too. But configure is allowed fail
for a broken system.

Christian

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 21:40:08 2008
From: report at bugs.python.org (Tiago Alves)
Date: Sun, 24 Feb 2008 20:40:08 -0000
Subject: [issue1230540] sys.excepthook doesn't work in threads
Message-ID: <1203885608.78.0.4572362355.issue1230540@psf.upfronthosting.co.za>


Tiago Alves added the comment:

I don't see it as a problem or as the threading module trying to be
"clever". It clearly was a design choice to make the module have its own
exception treatment in order to make it clear in which thread the
exception occurred.
IMHO the decision here should be to implement per thread excepthook's.

----------
nosy: +tiagoaoa

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1230540>
_____________________________________

From report at bugs.python.org  Sun Feb 24 21:47:27 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 20:47:27 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203886047.22.0.785174122247.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Christian, I agree on all points. Alexander's patch posixmodule.diff
satisfies those requirements.

I suggest also adding the unit test from os_times4.PATCH (but not the
changes to posixmodule.c in that patch), as this will help identify
misbehaving platforms in the future.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 21:49:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 20:49:24 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203886164.52.0.25635041058.issue1040026@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Thanks Cristian for your intervention.  This bug is clearly an 
aberration: how many GvR reported bugs do you know that stayed open for 
3+ years?

I think posixmodule.diff satisfies all your requirements and was not 
opposed by anyone except yours truly.  Do you need anything else to be 
done before you can accept the patches.  It looks like test_posix4.PATCH 
+ posixmodule.diff should be enough.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 21:54:51 2008
From: report at bugs.python.org (Malte Helmert)
Date: Sun, 24 Feb 2008 20:54:51 -0000
Subject: [issue1040026] os.times() is bogus
Message-ID: <1203886491.26.0.750760002418.issue1040026@psf.upfronthosting.co.za>


Malte Helmert added the comment:

Great, we're approaching closure! :-)

One final small thing: As said somewhere above, the allowed discrepancy
in test_posix4.PATCH is a bit too low for machines with only 60 ticks
per second. I uploaded a slightly more generous test_posix5.PATCH instead.

So posixmodule.diff + test_posix5.PATCH.

This is the same as what I mentioned above (posixmodule.diff + only the
unit test from os_times4.PATCH).

Added file: http://bugs.python.org/file9542/test_posix5.PATCH

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1040026>
_____________________________________

From report at bugs.python.org  Sun Feb 24 22:03:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 21:03:22 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203887002.02.0.260632449118.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

This is related to issue1540617 and issue1546078.

issue1540617 contains a simple patch that extend acceptable range of 
argument to +/-2**63

issue1546078 contains a complete long integer support implementation and  
was accepted in Py3k.

It looks like all three issues can be closed by either accepting or 
rejecting issue1540617 patch for 2.6 and marking issue1546078 patch as 
accepted for Py3k.

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Sun Feb 24 22:08:00 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 21:08:00 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203887280.52.0.336993888974.issue1533@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm -10 on the patch in issue1540617 ( +/-2**63).

Reason: It's a good thing that the range of "range" is limited since it
returns a list of integers. range(2**32) allocates (2**32)*16 bytes +
small overhead for ints plus the space for the list (probably
(2**32)*sizeof(ptr) which is 4 or 8 bytes). So far the memory for the
ints is *never* returned to the system. I'm working on the problem.

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Sun Feb 24 22:12:45 2008
From: report at bugs.python.org (Ihar Hrachyshka)
Date: Sun, 24 Feb 2008 21:12:45 -0000
Subject: [issue2178] Problems with Belarusian Latin locale
In-Reply-To: <1203887565.7.0.326406718733.issue2178@psf.upfronthosting.co.za>
Message-ID: <1203887565.7.0.326406718733.issue2178@psf.upfronthosting.co.za>


New submission from Ihar Hrachyshka:

There is a glibc locale: be_BY.UTF-8 at latin. If my locale environment is
set to this locale then all i18n-ed programs are shown with proper
translation, except Python-based ones where I see POSIX (?) locale
translation (all in English). Though if I set locale as be_BY at latin then
all goes well. Please fix the behavior of Python programs in my locale.
Affected programs: Sonata MPD client, GnoCHM, Gajim and possibly other.

----------
components: None
messages: 62939
nosy: booxter
severity: normal
status: open
title: Problems with Belarusian Latin locale
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2178>
__________________________________

From report at bugs.python.org  Sun Feb 24 22:16:41 2008
From: report at bugs.python.org (Yitz Gale)
Date: Sun, 24 Feb 2008 21:16:41 -0000
Subject: [issue2174] xml.sax.xmlreader does not support the InputSource
	protocol
In-Reply-To: <1203861152.32.0.18277152276.issue2174@psf.upfronthosting.co.za>
Message-ID: <1203887801.06.0.86838170039.issue2174@psf.upfronthosting.co.za>


Yitz Gale added the comment:

Subclass of XMLReader would be needed, not InputStream.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2174>
__________________________________

From report at bugs.python.org  Sun Feb 24 22:35:53 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 21:35:53 -0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1203888953.23.0.682781075178.issue1540617@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> enumerate() and itertools.count() both
> show how to support arbitrary longs without
> killing the performance of common cases.

Unlike enumerate() and count(), range object has 3 integer members: 
start, step and len.  Doubling all of them as in count does not sound 
right.

On the other hand, range has a unique implementation advantage over 
enumerate() and count() because one can determine whether long integers 
will ever be produced at initialization.

It looks like a reasonable solution would be to have xrange produce a 
subtype of rangeobject type supporting long integers in the cases when 
current code bails out.

This smells too much like int/long dichotomy in 2.x that was rejected in 
3.0, but I don't see much of the downside.

In any case, I can produce a patch (simply reusing the code from py3k, 
but only when range_new determines that long ints will be produceable 
from the range), but would like to hear from Martin or Raymond first.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540617>
_____________________________________

From report at bugs.python.org  Sun Feb 24 22:39:09 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Sun, 24 Feb 2008 21:39:09 -0000
Subject: [issue1524] os.system() fails for commands with multiple quoted file
	names
In-Reply-To: <1196367416.9.0.40290581495.issue1524@psf.upfronthosting.co.za>
Message-ID: <1203889149.6.0.25339321605.issue1524@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

I don't have access to a Windows machine, but is it really necessary to
quote the command part? I mean, on GNU/Linux if you pass a command wich
has spaces , say e.g.: ls -lah, quoted it fails too, but if passed
without quotes it runs just fine.

----------
nosy: +zanella

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524>
__________________________________

From report at bugs.python.org  Sun Feb 24 22:44:37 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 21:44:37 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203889477.23.0.638979191678.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Christian,

I was probably a bit sloppy using "range" instead of "xrange," but issue1540617 is limited to xrange only.  Are you still -10 on extending 
xrange on 64-bit platforms to +/- 2**63?  If so, what is your position 
on backporting py3k's unlimited range implementation?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Sun Feb 24 22:57:04 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Sun, 24 Feb 2008 21:57:04 -0000
Subject: [issue1986] io.StringIO allows any parameter
In-Reply-To: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>
Message-ID: <1203890224.53.0.579187302481.issue1986@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

I believe you're referring to StringIO, if so, it changes the parameter
received to a string:

"""
class StringIO:
  def __init__(self, buf = ''):
        # Force self.buf to be a string or unicode
        if not isinstance(buf, basestring):
            buf = str(buf)
"""

----------
nosy: +zanella

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1986>
__________________________________

From report at bugs.python.org  Sun Feb 24 23:00:36 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 22:00:36 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203890436.63.0.18059035266.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> So far the memory for the ints is *never* returned
> to the system. I'm working on the problem.

Christian,

Are you working on the memory problem or on this issue? I think I have a 
solution to OP's problem, but don't want to duplicate your effort.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Sun Feb 24 23:02:30 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Sun, 24 Feb 2008 22:02:30 -0000
Subject: [issue1986] io.StringIO allows any parameter
In-Reply-To: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>
Message-ID: <1203890550.15.0.0728105867722.issue1986@psf.upfronthosting.co.za>


Rafael Zanella added the comment:

oops, stupid me, this a 3.0 issue..., well seems the str() conversion is
done as well on the 3.0 io module:

"""
class StringIO(TextIOWrapper):
   def __init__(self, initial_value="", encoding="utf-8",
                 errors="strict", newline="\n"):
        super(StringIO, self).__init__(BytesIO(),
                                       encoding=encoding,
                                       errors=errors,
                                       newline=newline)
        if initial_value:
            if not isinstance(initial_value, str):
                initial_value = str(initial_value)
"""

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1986>
__________________________________

From report at bugs.python.org  Sun Feb 24 23:14:52 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 22:14:52 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203891292.25.0.300514223985.issue1533@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I'm working on the memory problem. See #2039 and #2013.

xrange is a totally different story. I'm +0 on changing xrange. Is
Python 3.0's range function compatible with xrange? If the answer is
yes, we may reuse the code for an unlimited xrange.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Sun Feb 24 23:15:58 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 24 Feb 2008 22:15:58 -0000
Subject: [issue1858] Make .pypirc handle multiple servers
In-Reply-To: <1200573233.93.0.822400680572.issue1858@psf.upfronthosting.co.za>
Message-ID: <1203891358.1.0.8272191709.issue1858@psf.upfronthosting.co.za>


Tarek Ziad? added the comment:

for the -r option, is has to be catched by both register and upload when
the command is called like this :

  $ python setup.py register sdist upload -r my-pypi

without the args lookup, register will get an empty value for -r. 

This option seems to me quite global to distutils.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1858>
__________________________________

From report at bugs.python.org  Sun Feb 24 23:32:37 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 24 Feb 2008 22:32:37 -0000
Subject: [issue1986] io.StringIO allows any parameter
In-Reply-To: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>
Message-ID: <1203892357.72.0.171119255331.issue1986@psf.upfronthosting.co.za>


Christian Heimes added the comment:

In Python 2.x StringIO.StringIO calls str() on its arguments:

>>> StringIO.StringIO(1).read()
'1'
>>> StringIO.StringIO(object).read()
"<type 'object'>"
>>> str(object)
"<type 'object'>"

io.StringIO has the same behavior:
>>> io.StringIO(1).read()
'1'
>>> io.StringIO(object).read()
"<type 'object'>"

Georg, what's the bug here?

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1986>
__________________________________

From report at bugs.python.org  Mon Feb 25 00:08:46 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 24 Feb 2008 23:08:46 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203894526.82.0.0976533527868.issue1533@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Attached patch addresses OP's issue:

$ ./python.exe bad_range.py
[8, 9, 10, 11, 12, 13, 14, 15, 16, 17]
here
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 
18446744073709551619L, 18446744073709551620L, 18446744073709551621L, 
18446744073709551622L, 18446744073709551623L, 18446744073709551624L, 
18446744073709551625L]
[18446744073709551616L, 18446744073709551617L, 18446744073709551618L, 
18446744073709551619L, 18446744073709551620L, 18446744073709551621L, 
18446744073709551622L, 18446744073709551623L, 18446744073709551624L, 
18446744073709551625L]

The only existing test that fails is range(1e100, 1e101, 1e101) 
producing a TypeError. It will now produce

>>> range(1e100, 1e101, 1e101)
__main__:1: DeprecationWarning: integer argument expected, got float
[10000000000000000159028911097599180468360808563945281389781327557747838
772170381060813469985856815104L]

Note that range(1e100, 1e101) would still fail:
>>> range(1e100, 1e101)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: range() result has too many items

An alternative solution would be to disallow non-ints regardless of 
their value, but that is more likely to break someone's code.

----------
keywords: +patch
Added file: http://bugs.python.org/file9543/bltinmodule.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Mon Feb 25 00:10:41 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 24 Feb 2008 23:10:41 -0000
Subject: [issue2179] with should be as fast as try/finally
In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za>
Message-ID: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

Currently, 'with' costs about .2us over try/finally:

$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'lock.acquire()' 'try: pass' 'finally:
lock.release()'
1000000 loops, best of 3: 0.617 usec per loop
$ ./python.exe -m timeit -s 'import thread; lock =
thread.allocate_lock()' 'with lock: pass'
1000000 loops, best of 3: 0.774 usec per loop

Since it's doing the same thing (and calling the same C functions to do
the lock manipulation), it shouldn't take more time. The bytecodes
associated with the two options look like:

2)    with lock:
3)      pass

 2           0 LOAD_GLOBAL              0 (lock)
              3 DUP_TOP             
              4 LOAD_ATTR                1 (__exit__)
              7 STORE_FAST               0 (_[1])
             10 LOAD_ATTR                2 (__enter__)
             13 CALL_FUNCTION            0
             16 POP_TOP             
             17 SETUP_FINALLY            4 (to 24)

  3          20 POP_BLOCK           
             21 LOAD_CONST               0 (None)
        >>   24 LOAD_FAST                0 (_[1])
             27 DELETE_FAST              0 (_[1])
             30 WITH_CLEANUP        
             31 END_FINALLY         
             32 LOAD_CONST               0 (None)
             35 RETURN_VALUE        


6)    lock.acquire()
7)    try:
8)      pass
9)    finally:
10)     lock.release()

  6           0 LOAD_GLOBAL              0 (lock)
              3 LOAD_ATTR                1 (acquire)
              6 CALL_FUNCTION            0
              9 POP_TOP             

  7          10 SETUP_FINALLY            4 (to 17)

  8          13 POP_BLOCK           
             14 LOAD_CONST               0 (None)

 10     >>   17 LOAD_GLOBAL              0 (lock)
             20 LOAD_ATTR                2 (release)
             23 CALL_FUNCTION            0
             26 POP_TOP             
             27 END_FINALLY         
             28 LOAD_CONST               0 (None)
             31 RETURN_VALUE


The major difference I see is the extra local variable (_[1]) used by
with. It looks like the compiler ought to be able to save that on the
stack instead, and save 3 opcodes. Neal Norwitz suggested that, if that
optimization is impossible, WITH_CLEANUP could be modified to take the
variable as a parameter, which would let it absorb the LOAD_FAST and
DELETE_FAST instructions.

I've added everyone on the previous bug to the nosy list. Sorry if you
don't care. :)

----------
components: Interpreter Core
messages: 62951
nosy: amaury.forgeotdarc, benjamin.peterson, jyasskin, nnorwitz, rhettinger, tiran
severity: normal
status: open
title: with should be as fast as try/finally
type: feature request
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2179>
__________________________________

From report at bugs.python.org  Mon Feb 25 00:13:09 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Sun, 24 Feb 2008 23:13:09 -0000
Subject: [issue1910] Document that with is slower than try/finally
In-Reply-To: <1201046324.17.0.644886854652.issue1910@psf.upfronthosting.co.za>
Message-ID: <1203894789.26.0.547477839721.issue1910@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I've filed issue 2179 to see if it's possible to make with as fast as
try/finally.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1910>
__________________________________

From report at bugs.python.org  Mon Feb 25 01:04:27 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 00:04:27 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203897867.18.0.5147227686.issue1394@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I am not sure what this patch would accomplish. I tried
$ cat t.py 
def f():
    return 1
    1+2
from dis import dis
print dis(f)

Both with and without patch I get

$ ./python.exe -O t.py
  2           0 LOAD_CONST               1 (1)
              3 RETURN_VALUE        

  3           4 LOAD_CONST               1 (1)
              7 LOAD_CONST               2 (2)
             10 BINARY_ADD          
             11 POP_TOP             
None

I am sure I am missing something, but it is hard to tell what without 
any use cases provided.

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 01:25:46 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 00:25:46 -0000
Subject: [issue1772673] Replacing char* with const char*
Message-ID: <1203899146.79.0.853155062848.issue1772673@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Douglas Greiman submitted many similar changes with his issue2135 patch.  
His patch also amends documentation, which is missing here.

I am adding dgreiman to the nosy list here to avoid duplication of 
effort.

I am -0 on the idea.

----------
nosy: +belopolsky, dgreiman

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1772673>
_____________________________________

From report at bugs.python.org  Mon Feb 25 01:56:30 2008
From: report at bugs.python.org (Collin Winter)
Date: Mon, 25 Feb 2008 00:56:30 -0000
Subject: [issue2179] with should be as fast as try/finally
In-Reply-To: <1203894641.18.0.492382147443.issue2179@psf.upfronthosting.co.za>
Message-ID: <1203900990.92.0.0490376005197.issue2179@psf.upfronthosting.co.za>


Changes by Collin Winter:


----------
nosy: +collinwinter

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2179>
__________________________________

From report at bugs.python.org  Mon Feb 25 01:57:27 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 00:57:27 -0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1203901047.19.0.961639146042.issue1766304@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Do we really need another way to spell a <= x < b? Have you got a
> real-world use case in mind for the version with step > 1?

> I'm at most lukewarm; I'd be willing to look at a patch to the C code
> in the py3k-struni branch, plus unit tests though.

-- GvR at http://thread.gmane.org/gmane.comp.python.python-
3000.devel/8732

I read this as a rejection for 2.x series.  For py3k, this is a 
premature optimization.  Current py3k implementation is likely to be 
optimized for regular size integers at some point.  This patch will only 
introduce more code to be changed then.

If this is not ready to be rejected for 2.x, let's wait for resolution 
of issue1540617 since it may result in backporting of py3k range 
implementation.

----------
nosy: +belopolsky

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_____________________________________

From report at bugs.python.org  Mon Feb 25 02:55:51 2008
From: report at bugs.python.org (Jared Grubb)
Date: Mon, 25 Feb 2008 01:55:51 -0000
Subject: [issue2180] tokenize: mishandles line joining
Message-ID: <1203904551.76.0.51250156022.issue2180@psf.upfronthosting.co.za>


Changes by Jared Grubb:


----------
components: Extension Modules
nosy: jaredgrubb
severity: minor
status: open
title: tokenize: mishandles line joining
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2180>
__________________________________

From report at bugs.python.org  Mon Feb 25 02:59:18 2008
From: report at bugs.python.org (Jared Grubb)
Date: Mon, 25 Feb 2008 01:59:18 -0000
Subject: [issue2180] tokenize: mishandles line joining
In-Reply-To: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za>
Message-ID: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za>


New submission from Jared Grubb:

tokenize does not handle line joining properly, as the following string
fails the CPython tokenizer but passes the tokenize module.

Example 1:
>>> s = "if 1:\n  \\\n  #hey\n  print 1"
>>> exec s
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<string>", line 3
    #hey
       ^
SyntaxError: invalid syntax

>>> tokenize.tokenize(StringIO(s).readline)
1,0-1,2:	NAME	'if'
1,3-1,4:	NUMBER	'1'
1,4-1,5:	OP	':'
1,5-1,6:	NEWLINE	'\n'
2,0-2,2:	INDENT	'  '
3,2-3,6:	COMMENT	'#hey'
3,6-3,7:	NEWLINE	'\n'
4,2-4,7:	NAME	'print'
4,8-4,9:	NUMBER	'1'
5,0-5,0:	DEDENT	''
5,0-5,0:	ENDMARKER	''

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2180>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:00:14 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:00:14 -0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

This patch optimizes code like:

   x = any_expression
   return x

to:
   return any_expression

Currently it only optimizes out the local variable if there is a return
because it can't determine if this is the last use of the variable or not.

This shouldn't change behaviour under normal circumstances, but would
change behaviour with a debugger.  Perhaps this optimization should only
be performed if -O is passed on the command line?

This optimization saves two trips around the eval loop (STORE_FAST and
LOAD_FAST) and 6 bytes in the byte code.

----------
components: Interpreter Core
files: opt-out-local-var.patch
keywords: patch, patch
messages: 62957
nosy: nnorwitz
severity: normal
status: open
title: optimize out local variables at end of function
type: resource usage
Added file: http://bugs.python.org/file9544/opt-out-local-var.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:03:09 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:03:09 -0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1203904989.69.0.76677574892.issue2181@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

I forgot to mention that if another loop was added to PyCode_Optimize
that kept track of the # of times each local variable was
LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could
perform a similar optimization without requiring the return.

Bonus points for other cases like if it was the last use inside a list
comprehension or the variable is otherwise unaccessible.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:06:48 2008
From: report at bugs.python.org (Jared Grubb)
Date: Mon, 25 Feb 2008 02:06:48 -0000
Subject: [issue2182] tokenize: does not allow CR for a newline
In-Reply-To: <1203905207.87.0.633637741257.issue2182@psf.upfronthosting.co.za>
Message-ID: <1203905207.87.0.633637741257.issue2182@psf.upfronthosting.co.za>


New submission from Jared Grubb:

tokenize recognizes '\n' and '\r\n' as newlines, but does not tolerate '\r':

>>> s = "print 1\nprint 2\r\nprint 3\r"
>>> open('temp.py','w').write(s)
>>> exec(open('temp.py','r'))
1
2
3
>>> tokenize.tokenize(open('temp.py','r').readline)
1,0-1,5:	NAME	'print'
1,6-1,7:	NUMBER	'1'
1,7-1,8:	NEWLINE	'\n'
2,0-2,5:	NAME	'print'
2,6-2,7:	NUMBER	'2'
2,7-2,9:	NEWLINE	'\r\n'
3,0-3,5:	NAME	'print'
3,6-3,7:	NUMBER	'3'
3,7-3,8:	ERRORTOKEN	'\r'
4,0-4,0:	ENDMARKER	''

----------
components: Extension Modules
messages: 62959
nosy: jaredgrubb
severity: minor
status: open
title: tokenize: does not allow CR for a newline
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2182>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:22:30 2008
From: report at bugs.python.org (Jared Grubb)
Date: Mon, 25 Feb 2008 02:22:30 -0000
Subject: [issue2180] tokenize: mishandles line joining
In-Reply-To: <1203904758.19.0.84784431119.issue2180@psf.upfronthosting.co.za>
Message-ID: <1203906150.42.0.824335055729.issue2180@psf.upfronthosting.co.za>


Jared Grubb added the comment:

CPython allows \ at EOF, but tokenize does not.

>>> s = 'print 1\\\n'
>>> exec s
1
>>> tokenize.tokenize(StringIO(s).readline)
1,0-1,5:	NAME	'print'
1,6-1,7:	NUMBER	'1'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py",
line 153, in tokenize
    tokenize_loop(readline, tokeneater)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py",
line 159, in tokenize_loop
    for token_info in generate_tokens(readline):
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/tokenize.py",
line 283, in generate_tokens
    raise TokenError, ("EOF in multi-line statement", (lnum, 0))
tokenize.TokenError: ('EOF in multi-line statement', (2, 0))

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2180>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:22:32 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:22:32 -0000
Subject: [issue2183] optimize list comprehensions
In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za>
Message-ID: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

Optimize list comprehensions by using the list on the stack, rather than
storing in a (local/global) variable.  This reduces the size of the
stack by one pointer, reduces the bytecode size by 8, and reduces the
iterations in the eval loop by 2 + # of iterations to create the new
list.  It also eliminates internal variables in varnames.

List comps in module/class scope execute faster by avoiding more costly
dict lookups in globals.

For this source code:
    def f(): return [x for x in s]

Byte code before change:
  1           0 BUILD_LIST               0
              3 DUP_TOP             
              4 STORE_FAST               0 (_[1])
              7 LOAD_GLOBAL              1 (s)
             10 GET_ITER            
        >>   11 FOR_ITER                13 (to 27)
             14 STORE_FAST               1 (x)
             17 LOAD_FAST                0 (_[1])
             20 LOAD_FAST                1 (x)
             23 LIST_APPEND         
             24 JUMP_ABSOLUTE           11
        >>   27 DELETE_FAST              0 (_[1])
             30 RETURN_VALUE        

New byte code:
  1           0 BUILD_LIST               0
              3 LOAD_GLOBAL              0 (s)
              6 GET_ITER            
        >>    7 FOR_ITER                12 (to 22)
             10 STORE_FAST               0 (x)
             13 LOAD_FAST                0 (x)
             16 LIST_APPEND              2
             19 JUMP_ABSOLUTE            7
        >>   22 RETURN_VALUE        

DUP_TOP/STORE_FAST are eliminated before the loop.  One LOAD_FAST is
eliminated inside the loop.  LIST_APPEND is changed to reference the
value on the stack.  Is it a problem to change the opcode of LIST_APPEND?

This might make debugging harder.  I'm not sure how debuggers work with
list comps.

A similar optimization could probably be done to eliminate all uses of
the temporary variables (WITH_CLEANUP at least).

This patch still needs to update docs and the compiler package
implemented in Python.

----------
components: Interpreter Core
files: list-comp-opt2.patch
keywords: patch, patch
messages: 62961
nosy: nnorwitz
severity: normal
status: open
title: optimize list comprehensions
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9545/list-comp-opt2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2183>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:22:44 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:22:44 -0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1203906164.79.0.636913059624.issue2181@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

I forgot to mention that if another loop was added to PyCode_Optimize
that kept track of the # of times each local variable was
LOAD_FAST/STORE_FAST/DELETE_FAST and that the count was 2, we could
perform a similar optimization without requiring the return.

Bonus points for other cases like if it was the last use inside a list
comprehension or the variable is otherwise unaccessible.

----------
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:30:24 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Mon, 25 Feb 2008 02:30:24 -0000
Subject: [issue2184] Speed up Thread.start()
In-Reply-To: <1203906623.93.0.917189380676.issue2184@psf.upfronthosting.co.za>
Message-ID: <1203906623.93.0.917189380676.issue2184@psf.upfronthosting.co.za>


New submission from Jeffrey Yasskin:

Thread.start() used sleep(0.000001) to make sure it didn't return before
the new thread had started. At least on my MacBook Pro, that wound up
sleeping for a full 10ms (probably 1 jiffy). By using an Event instead,
we can be absolutely certain that the thread has started, and return
more quickly (217us).

Before:
$  ./python.exe -m timeit -s 'from threading import Thread'  't =
Thread(); t.start(); t.join()'
100 loops, best of 3: 10.3 msec per loop
$  ./python.exe -m timeit -s 'from threading import Thread; t =
Thread()'  't.isAlive()'
1000000 loops, best of 3: 0.47 usec per loop

After:
$  ./python.exe -m timeit -s 'from threading import Thread'  't =
Thread(); t.start(); t.join()'
1000 loops, best of 3: 217 usec per loop
$  ./python.exe -m timeit -s 'from threading import Thread; t =
Thread()'  't.isAlive()'
1000000 loops, best of 3: 0.86 usec per loop

To be fair, the 10ms isn't CPU time, and other threads including the
spawned one get to run during it. There are also some slightly more
complicated ways to get back the .4us in isAlive() if we want.

----------
components: Library (Lib)
files: faster_thread_startup.diff
keywords: patch, patch
messages: 62963
nosy: jyasskin
severity: normal
status: open
title: Speed up Thread.start()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9546/faster_thread_startup.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2184>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:30:31 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:30:31 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203906631.02.0.493758653932.issue1394@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

It would be great to see test cases with this change.  That would help
answer Alexander's question too.

----------
nosy: +nnorwitz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 03:41:40 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 02:41:40 -0000
Subject: [issue2185] code objects should conserve memory
In-Reply-To: <1203907300.87.0.511382024936.issue2185@psf.upfronthosting.co.za>
Message-ID: <1203907300.87.0.511382024936.issue2185@psf.upfronthosting.co.za>


New submission from Neal Norwitz:

Various bits are often duplicated in code objects.  For example,
sometimes names and varnames are equal.  In this case, we don't need two
objects since they are both const.  This patch implements a trivial fix
for this case.  However, there are more cases.  We should profile where
the memory is being used and do simple/cheap consolidations where
possible.  Another example would be a 1-element tuple containing:
(None,) for consts.

Some (all?) of these sorts of optimizations should probably be done in
the code object itself.

----------
files: marshal-mem.patch
keywords: patch, patch
messages: 62965
nosy: nnorwitz
severity: normal
status: open
title: code objects should conserve memory
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9547/marshal-mem.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2185>
__________________________________

From report at bugs.python.org  Mon Feb 25 04:22:55 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 03:22:55 -0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1203909775.52.0.525827888588.issue2181@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

Guido says to do it only with -O. 
http://mail.python.org/pipermail/python-dev/2008-February/077193.html

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Mon Feb 25 05:04:21 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 04:04:21 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

There are other ways of getting the same effects now (list() or zip()
for map(None, ...)).

----------
keywords: easy
messages: 62967
nosy: gvanrossum
severity: normal
status: open
title: map and filter shouldn't support None as first argument (in Py3k only)
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 05:04:49 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 04:04:49 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203912289.67.0.374364605722.issue2186@psf.upfronthosting.co.za>


Changes by Guido van Rossum:


----------
components: +Interpreter Core
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 05:06:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 04:06:34 -0000
Subject: [issue2187] map and filter objects shouldn't call themselves
	itertools.imap and itertools.ifilter objects
In-Reply-To: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za>
Message-ID: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za>


New submission from Guido van Rossum:

Probably ifilter and imap should go (moving the code over to bltinmodule.c).

----------
components: Interpreter Core
keywords: easy
messages: 62968
nosy: gvanrossum
severity: normal
status: open
title: map and filter objects shouldn't call themselves itertools.imap and itertools.ifilter objects
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2187>
__________________________________

From report at bugs.python.org  Mon Feb 25 05:38:28 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 04:38:28 -0000
Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve
	error msg
In-Reply-To: <1199620656.31.0.603930842428.issue1691070@psf.upfronthosting.co.za>
Message-ID: <ee2a432c0802242038y5a8dd6devd083df11f50c844c@mail.gmail.com>


Neal Norwitz added the comment:

Christian,

Could you clean this patch up?  Specifically:

 * Put everything into one patch
 * Eliminate unnecessary changes (changing variable name or whitespace)
 * Conform to the style in the file
 * Verify all the tests run with regrtest.py -u all  when built
--without-pydebug
 * Verify it runs faster

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691070>
_____________________________________

From report at bugs.python.org  Mon Feb 25 05:52:31 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 04:52:31 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203915151.7.0.530941719704.issue2186@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

In the absence of an identity function, map accepting None is useful in 
the cases like this:

converters = {..}
y = map(converters.get(c), x)

That will now have to be rewritten as

conv = converters.get(c)
if conv is None:
   y = list(x)
else:
   y = map(conv, x)

and subtle bugs will be introduced if x is used instead of list(x) in 
the None case.

Another alternative,

y = map(converters.get(c, lambda x:x), x)

will be much slower.

Take my opinion with a grain of salt because I also believe None should 
be callable with None(x) -> x and None(x,y,..) -> (x,y,..).

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 06:36:21 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 25 Feb 2008 05:36:21 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za>
Message-ID: <1203917781.54.0.371427192995.issue1740@psf.upfronthosting.co.za>


Brett Cannon added the comment:

I am attaching a reviewed version of the patch. It had some major PEP 8
violations that I had to clean up. I also moved over to the usage of
test.test_support.captured_stdout(). Otherwise it looks good.

I am going to wait a little while in hopes someone else can at least
take a look to make sure that the tests are proper and thorough since it
is a complete rewrite.

Added file: http://bugs.python.org/file9548/test_logging.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Mon Feb 25 06:39:59 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 05:39:59 -0000
Subject: [issue1518] Fast globals/builtins access (patch)
In-Reply-To: <1196329437.66.0.0945045609125.issue1518@psf.upfronthosting.co.za>
Message-ID: <1203917999.42.0.652889462532.issue1518@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

I've gone over this at a high-level and looked for various outstanding
issues.  Below are my comments.  I didn't delve into this in detail. 
There are a lot of questions too.

I think this is very interesting and hope that we can get it working,
100% robust, and verify the improved perf.

In Include/fastglobals.h, num_entries says it is len(names).  But
there is also an entries field.  This is confusing.  The name should
be num_names if it is the length of names.

isbuiltin is an array of integers that hold boolean values?  So most
of the memory is wasted?  How many entries do you expect in isbuiltin?
This field should probably be packed using each bit.  Its type should then
be unsigned.  If there were a small number of PyFastGlobalsObjects it
wouldn't be a big deal.  But from the comment it seems there will be
one of these objects for each function.

Did you measure the difference in memory size?  For example the size
at startup with and without the patch.  Did you measure the startup
time?  How big is python at the end of a regression test run with and
without this patch?

Is there ever an access to the old globals in the old code?  I wonder
if it's worthwhile to change the names in ceval.c, etc.

Does PyFastGlobals_GET_ITEM_INPLACE really need to be a macro?  It's a
pain to debug macros.  If it were a static function in the header
file, it would almost definitely get inlined.  
PyFastGlobals_ENTRY(op, index) should be captured in a local variable.

I'm thinking that entryversion should be unsigned.  Signed integer
overflow is not defined (we had some problems recently with this).
PyFastGlobals_VERSION_SET(op) can overflow.

I like the removal of one pointer from the frame object.

How does this interact with multiple interpreters?  I see the static
of __builtins__ in fastglobal.c.  See PyInterpreterState in
Include/pystate.h.  (I see that __builtins__ is a string, so this
access should be fine, but the question is still valid.  I just want
to make sure there aren't any bad interactions.)

Regarding:
/* XXX A clever adversary could prevent this from terminating */

How about the loop is limited to 10 runs or something reasonable?
That way there cannot be a DoS attack.  You can raise a RuntimeError
if the max iterations is reached.

Since PyFastGlobals_Update() is public, you should not assert that the
op is a fast globals, but rather check and set
PyErr_BadInternalCall().  That's true of all public APIs.  Internal
APIs are fine to have asserts.

In fg_check_builtins() you may be able to speed this up by checking
the most common paths first.  I know this code is taken from
frameobject.  See
http://coverage.livinglogic.de/Objects/frameobject.c.html .  Hmmm,
that isn't showing any data currently.  I'll ping Walter and ask him
if he can get that working again.

I don't understand this comment in PyFastGlobals_CheckBuiltins:
  /* Make sure fg->builtins_entry is updated first */

It says what the code does, but I don't understand *why* it does it.

Instead of:
		PyErr_NoMemory();
		Py_DECREF(newnames);
		return NULL;

You can do:
		Py_DECREF(newnames);
		return PyErr_NoMemory();

In PyFastGlobals_New(), you should verify that num_entries doesn't
overflow before creating a new tuple by increasing the size by 1.

In this code:
	isbuiltin = PyMem_NEW(int, num_entries);
	if (isbuiltin == NULL) {
		PyErr_NoMemory();
		Py_DECREF(newnames);
		PyMem_FREE(isbuiltin);
		return NULL;
	}

The free of isbuiltin should be entries.

If these arrays will be small (< 256 bytes), it would be better (faster)
to use
pymalloc rather than the PyMem interface.

PyDict_GetEntry should be prefixed with an underscore.  I don't think
this should become part of the public API.  How about passing an int
pointer to GetEntry that will be set if the key is found or clear if not
found?

This needs to be addressed:
+	/* This is a bad idea now: if gc breaks a cycle by clearing
+	f_fastglobals, when a generator is finally collected it does this
+	sequence of calls: gen_del->gen_close->gen_send_ex->
+	PyEval_EvalFrameEx. But PyEval_EvalFrameEx references
+	f_fastglobals->globals, which will be cleared by then, resuling
+	in a segfault.
+	??? Is there a way to preserve this traversal? */
+	/* Py_VISIT(f->f_fastglobals); */

----------
nosy: +nnorwitz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1518>
__________________________________

From report at bugs.python.org  Mon Feb 25 07:09:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 25 Feb 2008 06:09:53 -0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1203919793.81.0.166499121666.issue1540617@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

I fail to see the need for this, from more than an academic point of
you. What specific event triggered your working on this?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540617>
_____________________________________

From report at bugs.python.org  Mon Feb 25 07:14:49 2008
From: report at bugs.python.org (Hye-Shik Chang)
Date: Mon, 25 Feb 2008 06:14:49 -0000
Subject: [issue1276] LookupError: unknown encoding: X-MAC-JAPANESE
In-Reply-To: <1192270029.29.0.976742738273.issue1276@psf.upfronthosting.co.za>
Message-ID: <1203920089.0.0.14379932176.issue1276@psf.upfronthosting.co.za>


Hye-Shik Chang added the comment:

I'll take this.

----------
assignee: lemburg -> hyeshik.chang
nosy: +hyeshik.chang

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1276>
__________________________________

From report at bugs.python.org  Mon Feb 25 11:24:38 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 25 Feb 2008 10:24:38 -0000
Subject: [issue2124] xml.sax and xml.dom fetch DTDs by default
In-Reply-To: <1203086575.38.0.209227458245.issue2124@psf.upfronthosting.co.za>
Message-ID: <1203935078.04.0.926753326911.issue2124@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

I mention urllib because, as noted earlier in the discussion, code that
fetches resources over HTTP should really be caching (looking at the
Expires header, sending an ETag and an If-Modified-Since header, etc.).
 It's difficult for us to add these features to the urllib/urllib2 APIs,
so we should make users aware of other libraries that provide these
features,  so that users will use such a library instead of just writing
to the lower-level APIs provided with Python.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2124>
__________________________________

From report at bugs.python.org  Mon Feb 25 12:08:49 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Mon, 25 Feb 2008 11:08:49 -0000
Subject: [issue2188] [patch] urllib2 hint - disabled ProxyHandler()
In-Reply-To: <1203937729.17.0.846967390302.issue2188@psf.upfronthosting.co.za>
Message-ID: <1203937729.17.0.846967390302.issue2188@psf.upfronthosting.co.za>


New submission from anatoly techtonik:

Patch documents that empty dictionary is used to make ProxyHandler()
with disabled proxy autodetection. Empty constructor doesn't give the
desired effect.

P.S. An ideal approach would be, of course, to change the API. Even
though it can be changed drastically the simple hack would look like:

class ProxyHandler([proxies][, autodetect=False])

Seems like it is better to leave API for Py3K refactoring issue, like #1333

----------
components: Documentation
files: urllib2.patch.txt
messages: 62976
nosy: techtonik
severity: normal
status: open
title: [patch] urllib2 hint - disabled ProxyHandler()
versions: Python 2.6
Added file: http://bugs.python.org/file9549/urllib2.patch.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2188>
__________________________________

From report at bugs.python.org  Mon Feb 25 12:15:50 2008
From: report at bugs.python.org (Michael Otteneder)
Date: Mon, 25 Feb 2008 11:15:50 -0000
Subject: [issue2163] test_socket is flakey
In-Reply-To: <1203699782.31.0.112043665965.issue2163@psf.upfronthosting.co.za>
Message-ID: <1203938150.3.0.376187196657.issue2163@psf.upfronthosting.co.za>


Michael Otteneder added the comment:

I'm not able to reproduce this with latest svn on OS X 10.5.2.
test_socket never fails.

----------
nosy: +motteneder

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2163>
__________________________________

From report at bugs.python.org  Mon Feb 25 13:09:49 2008
From: report at bugs.python.org (djc)
Date: Mon, 25 Feb 2008 12:09:49 -0000
Subject: [issue2189] urllib.quote() throws KeyError when passed an iterator
In-Reply-To: <1203941389.03.0.634927871204.issue2189@psf.upfronthosting.co.za>
Message-ID: <1203941389.03.0.634927871204.issue2189@psf.upfronthosting.co.za>


New submission from djc:

>>> urllib.quote(['', 'aa'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/urllib.py", line 1205, in quote
    res = map(safe_map.__getitem__, s)
KeyError: ''

I think this is a weird error message to throw. quote() is obviously
assuming that the param passed is a one-character string iterator or
something. It should either accept just strings or come up with a better
error message when confronted with an iterator element that is not a
one-character string, IMO.

----------
components: Library (Lib)
messages: 62978
nosy: djc
severity: minor
status: open
title: urllib.quote() throws KeyError when passed an iterator
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2189>
__________________________________

From report at bugs.python.org  Mon Feb 25 13:36:45 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 25 Feb 2008 12:36:45 -0000
Subject: [issue1725737] Distutils default exclude doesn't match top level .svn
Message-ID: <1203943005.57.0.887418784541.issue1725737@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

The original patch should by betelgeus should be applied to 2.5 branch.

Georg, this is complete from my point of view and could be applied.
Unless you want *~ and .#* to also be excluded?

----------
versions: +Python 2.5, Python 2.6

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1725737>
_____________________________________

From report at bugs.python.org  Mon Feb 25 13:41:13 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 25 Feb 2008 12:41:13 -0000
Subject: [issue919238] Recursive variable definition causes sysconfig infinite
	loop
Message-ID: <1203943273.22.0.299595210308.issue919238@psf.upfronthosting.co.za>


Ralf Schmitt added the comment:

distutils.extension has:

            if warnings is not None:
                warnings.warn(msg)
            else:
                sys.stderr.write(msg + '\n')

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue919238>
____________________________________

From report at bugs.python.org  Mon Feb 25 14:14:25 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Feb 2008 13:14:25 -0000
Subject: [issue1524] os.system() fails for commands with multiple quoted file
	names
In-Reply-To: <1196367416.9.0.40290581495.issue1524@psf.upfronthosting.co.za>
Message-ID: <1203945265.18.0.193582002574.issue1524@psf.upfronthosting.co.za>


Christian Heimes added the comment:

Yes, it's necessary whenever the command part contains a space or other
special characters.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524>
__________________________________

From report at bugs.python.org  Mon Feb 25 15:33:35 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 14:33:35 -0000
Subject: [issue1540617] Use Py_ssize_t for rangeobject members
Message-ID: <1203950015.29.0.662744174325.issue1540617@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> What specific event triggered your working on this?

That was a long time ago, but IIRC, we had some code dealing with large 
files that grew up beyond 2G.  The files contained fixed-length records 
and we used xrange to iterate over record offsets. We worked around that 
problem by replacing uses of xrange with large "start"/"end" with 
nympy's arange.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540617>
_____________________________________

From report at bugs.python.org  Mon Feb 25 15:42:41 2008
From: report at bugs.python.org (Christian Heimes)
Date: Mon, 25 Feb 2008 14:42:41 -0000
Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve
	error msg
Message-ID: <1203950561.45.0.659293446576.issue1691070@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I did some cleanup (style, var names, <80 chars per line) and combined
the patch set into a single patch. The regression tests are passing for
a pydebug build. I'm too busy to profile and test the patch with a
vanilla Python right now.

Pybench is showing a small speedup (first run with patch, second run
without patch): 26498ms 25920ms   +2.2% 28000ms 26888ms   +4.1%

Added file: http://bugs.python.org/file9550/trunk_getargs_speedup.patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691070>
_____________________________________

From report at bugs.python.org  Mon Feb 25 16:52:56 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 15:52:56 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203954776.39.0.0519204149612.issue2186@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Attached patch removes support for None from filter and 
itertools.ifilter.  My objections for removing that from map do not 
apply because bool function can be used instead of None in filter 
achieving similar performance and better clarity.

None support was apparently removed from map in r60206.

Remaining questions:

1. map(None,[]), filter(None,[]) and in fact map(anything,[]) still 
work.  I don't think that needs to be fixed.

2. Should None support be removed from itertools.ifilterfalse? I would 
guess yes, unless it is going away.

----------
keywords: +patch
Added file: http://bugs.python.org/file9551/filter.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 17:39:06 2008
From: report at bugs.python.org (Dou Yuan)
Date: Mon, 25 Feb 2008 16:39:06 -0000
Subject: [issue2190] MozillaCookieJar ignore HttpOnly cookies
In-Reply-To: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za>
Message-ID: <1203957546.34.0.123660895963.issue2190@psf.upfronthosting.co.za>


New submission from Dou Yuan:

HttpOnly cookie in Firefox's cookies.txt begins with "#HttpOnly_" now,
just like a comment, e.g.:

#HttpOnly_.rad.live.com    TRUE    /    FALSE    1258200001    FC09    FB=
#HttpOnly_service.ilib.cn    FALSE    /    FALSE    1209905939   
.ASPXANONYMOUS   
JMeD5-atyAEkAAAAYjZlNDUyNDAtOGQ4ZC00NTEyLTljN2EtMzNkODM3M2JjMjFivtX6ikB7Iv0jRJBJs9ftggv_a2k

Since no obvious need, there are no patches for save method and
cookielib.Cookie class.

----------
components: Library (Lib)
files: _MozillaCookieJar.diff
keywords: patch
messages: 62985
nosy: douyuan
severity: minor
status: open
title: MozillaCookieJar ignore HttpOnly cookies
versions: Python 2.6
Added file: http://bugs.python.org/file9552/_MozillaCookieJar.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2190>
__________________________________

From report at bugs.python.org  Mon Feb 25 18:03:30 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 17:03:30 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203959010.92.0.643242649768.issue2186@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

Let me assign this to Raymond for the answering of the question about
ifilterfalse.

----------
assignee:  -> rhettinger
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 18:24:07 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 17:24:07 -0000
Subject: [issue2163] test_socket is flakey
In-Reply-To: <1203699782.31.0.112043665965.issue2163@psf.upfronthosting.co.za>
Message-ID: <1203960247.69.0.703768217368.issue2163@psf.upfronthosting.co.za>


Guido van Rossum added the comment:

It seems to work now for me too. I'll keep an eye out though.

----------
resolution:  -> works for me
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2163>
__________________________________

From report at bugs.python.org  Mon Feb 25 18:33:31 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 17:33:31 -0000
Subject: [issue2187] map and filter objects shouldn't call themselves
	itertools.imap and itertools.ifilter objects
In-Reply-To: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za>
Message-ID: <1203960811.47.0.37226179193.issue2187@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Can you assign this to Raymond as well? If this is done first, issue2186 
patch will be simpler (at least in the documentation portion).  The same 
question on the fate of ifilterfalse is pertinent here as well.

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2187>
__________________________________

From report at bugs.python.org  Mon Feb 25 18:34:11 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 17:34:11 -0000
Subject: [issue2187] map and filter objects shouldn't call themselves
	itertools.imap and itertools.ifilter objects
In-Reply-To: <1203912393.93.0.542034145093.issue2187@psf.upfronthosting.co.za>
Message-ID: <1203960851.27.0.972842732731.issue2187@psf.upfronthosting.co.za>


Changes by Guido van Rossum:


----------
assignee:  -> rhettinger
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2187>
__________________________________

From report at bugs.python.org  Mon Feb 25 18:52:54 2008
From: report at bugs.python.org (Robert Bradshaw)
Date: Mon, 25 Feb 2008 17:52:54 -0000
Subject: [issue1533] Bug in range() function for large values
In-Reply-To: <1196468890.07.0.55666875231.issue1533@psf.upfronthosting.co.za>
Message-ID: <1203961974.5.0.803956645888.issue1533@psf.upfronthosting.co.za>


Robert Bradshaw added the comment:

Alexander Belopolsky's patch looks like the right fix for range() to me. 

The xrange limits still hold, but that should probably be a separate
issue/ticket.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1533>
__________________________________

From report at bugs.python.org  Mon Feb 25 19:06:27 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 25 Feb 2008 18:06:27 -0000
Subject: [issue2177] Update compiler module to handle class decorators
In-Reply-To: <1203870219.45.0.496617339478.issue2177@psf.upfronthosting.co.za>
Message-ID: <1203962787.44.0.450250114523.issue2177@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r61067.

Thank you!

----------
nosy: +facundobatista
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2177>
__________________________________

From report at bugs.python.org  Mon Feb 25 19:17:16 2008
From: report at bugs.python.org (Rafael Zanella)
Date: Mon, 25 Feb 2008 18:17:16 -0000
Subject: [issue1193577] add server.shutdown() method and daemon arg to
	SocketServer
Message-ID: <1203963436.31.0.0081302599299.issue1193577@psf.upfronthosting.co.za>


Changes by Rafael Zanella:


----------
nosy: +zanella

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1193577>
_____________________________________

From report at bugs.python.org  Mon Feb 25 20:08:29 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Feb 2008 19:08:29 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203966509.11.0.70300732605.issue2186@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Will think about ifilter() and ifilterfalse() for a day or two.  The
None argument handles the common use-case and there may be a good case
for keeping it.  If I do decide to drop it, will put in my own patch
that optimized for the case with the filter function is bool().

+1 On removing the None argument from map() and imap().  It was
hold-over from the days before zip().

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 20:09:34 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 19:09:34 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203966574.28.0.390575433925.issue1394@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I figured that out:

>>> def g():
...   raise RuntimeError
... 

Before the patch:

>>> dis(g)
  2           0 LOAD_GLOBAL              0 (RuntimeError)
              3 RAISE_VARARGS            1
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE        

After the patch:
>>> dis(g)
  2           0 LOAD_GLOBAL              0 (RuntimeError)
              3 RAISE_VARARGS            1

Looks reasonable to me.  Paul, do you need help with unit tests?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 20:26:10 2008
From: report at bugs.python.org (Ken Lalonde)
Date: Mon, 25 Feb 2008 19:26:10 -0000
Subject: [issue1524825] ConfigParser: accept leading whitespace on
	options+comments
Message-ID: <1203967570.29.0.331020918251.issue1524825@psf.upfronthosting.co.za>


Ken Lalonde added the comment:

Quentin: I didn't appreciate the line-continuation issue.
Breaking existing code is out of the question, so I'd like to
retract that part of the patch.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524825>
_____________________________________

From report at bugs.python.org  Mon Feb 25 20:26:50 2008
From: report at bugs.python.org (Pedro Werneck)
Date: Mon, 25 Feb 2008 19:26:50 -0000
Subject: [issue1193577] add server.shutdown() method and daemon arg to
	SocketServer
Message-ID: <1203967610.72.0.549763972445.issue1193577@psf.upfronthosting.co.za>


Pedro Werneck added the comment:

I had some code here to do the exact same thing with XML-RPC server. The
patch adds the feature to SocketServer, with a server.shutdown() method
to stop serve_forever(), and change the unittest to use and test the
feature.

I disagree on adding the daemon_threads arg as a keyword to TCPServer
since that's a feature of ThreadingMixIn

----------
keywords: +patch
nosy: +werneck
Added file: http://bugs.python.org/file9553/issue1193577.patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1193577>
_____________________________________

From report at bugs.python.org  Mon Feb 25 20:39:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 25 Feb 2008 19:39:24 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za>
Message-ID: <1203968364.29.0.15448913279.issue1740@psf.upfronthosting.co.za>


Antoine Pitrou added the comment:

Out of curiosity, what were the PEP 8 violations? Usually I try to
respect the coding guidelines.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:07:33 2008
From: report at bugs.python.org (Madhusudan SK)
Date: Mon, 25 Feb 2008 20:07:33 -0000
Subject: [issue2191] SubProcess Startup error
In-Reply-To: <1203970053.49.0.924039219535.issue2191@psf.upfronthosting.co.za>
Message-ID: <1203970053.49.0.924039219535.issue2191@psf.upfronthosting.co.za>


New submission from Madhusudan SK:

After installing the Python.msi x86 installer on an Intel P4 machine 
running Windows XP SP2, I am getting the error "Subprocess startup 
error" and when i click OK on the dialog box the Python IDLE closes. I 
do not have Microsoft Visual Studio installed on my system but do have 
the .NET framework 1.1 installed. The reason code in the pop up says 
either the IDLE cannot start a subprocess or a firewall is blocking the 
connection. Is it necessary that the anitvirus/firewall software needs 
to be disabled before installing Python 3.0 or is it the case as 
mentioned in the http://www.python.org/download/releases/3.0/ "Read 
this first" section i.e. python30.dll cannot be installed in system32 
folder?

----------
components: IDLE
files: Python3.0a IDLE startup error.htm
messages: 62996
nosy: madhusudan.sk
severity: major
status: open
title: SubProcess Startup error
type: crash
versions: Python 3.0
Added file: http://bugs.python.org/file9554/Python3.0a IDLE startup error.htm

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2191>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:18:26 2008
From: report at bugs.python.org (aka)
Date: Mon, 25 Feb 2008 20:18:26 -0000
Subject: [issue2192] error with backslash as last character in raw string
In-Reply-To: <1203970706.3.0.353851421096.issue2192@psf.upfronthosting.co.za>
Message-ID: <1203970706.3.0.353851421096.issue2192@psf.upfronthosting.co.za>


New submission from aka:

When creating a raw string ending with a backslash the systems answers
with an error:

>>> r'c:\'
SyntaxError: EOL while scanning single-quoted string

This happens on many systems with many versions, so it is propably a
problem of the interpreter itself.

----------
components: Interpreter Core
messages: 62997
nosy: aka
severity: normal
status: open
title: error with backslash as last character in raw string
type: compile error
versions: Python 2.3, Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2192>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:20:49 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 25 Feb 2008 20:20:49 -0000
Subject: [issue2192] error with backslash as last character in raw string
In-Reply-To: <1203970706.3.0.353851421096.issue2192@psf.upfronthosting.co.za>
Message-ID: <1203970849.09.0.517389508699.issue2192@psf.upfronthosting.co.za>


Raghuram Devarakonda added the comment:

This is as per the design. Please see
http://www.python.org/doc/faq/general/#why-can-t-raw-strings-r-strings-end-with-a-backslash.

----------
nosy: +draghuram
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2192>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:25:50 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Mon, 25 Feb 2008 20:25:50 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203971150.9.0.438092788506.issue1394@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

Yes, help with unit tests would be appreciated.  Especially since it is
not supposed to fix anything, so I'm not sure what unit tests should be
like...

BTW, trying to understand why the patch didn't remove unreachable code
in your first example, I noticed this (both cases are with patch):

def f1():
    return 1
    x()

disassembly:
  3           0 LOAD_CONST               1 (1)
              3 RETURN_VALUE

  4           4 LOAD_GLOBAL              0 (x)
              7 CALL_FUNCTION            0
             10 POP_TOP

def f2():
    return 1
    x()
    return 2

disassembly:
  3           0 LOAD_CONST               1 (1)
              3 RETURN_VALUE

Looking a bit further, I noticed this:
	if (codestr[codelen-1] != RETURN_VALUE)
		goto exitUnchanged;

So, the patch really can't help with your first example, because peephol
optimizer just bails out before real action begins.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:31:17 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Mon, 25 Feb 2008 20:31:17 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203971476.98.0.428860789219.issue1394@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

Speaking of which, I propose that codestr[] array is made one byte
longer and RETURN_VALUE opcode wrote in that extra byte.  It will be
removed by this patch anyway (if it is accepted), but we'll remove a way
to accidentally disable peephole optimizer.

I mean, it would cost almost nothing, yet will prevent making some
functions non-optimized.  E.g. like this:

def foo(x):
    if x >= 0:
        return x * 2
    raise ValueError

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 21:59:21 2008
From: report at bugs.python.org (Madhusudan SK)
Date: Mon, 25 Feb 2008 20:59:21 -0000
Subject: [issue2191] SubProcess Startup error
In-Reply-To: <1203970053.49.0.924039219535.issue2191@psf.upfronthosting.co.za>
Message-ID: <1203973161.17.0.287653520173.issue2191@psf.upfronthosting.co.za>


Madhusudan SK added the comment:

One more thing i am already running Python 2.5.2 and concurrently 
installed Python 3.0 a without uninstalling the 2.5.2.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2191>
__________________________________

From report at bugs.python.org  Mon Feb 25 22:10:44 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 21:10:44 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203973844.05.0.5025468284.issue2186@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Raymond,

There must be a reason why we constantly disagree.  Do you live in
California by any chance? :-)

I am not sure if map(None, ..) fate is still up for voting given your
changes at r60206, but your own patch illustrates the problem that I
highlighted:

< it = izip(map(key, in1), count(), in2)                  # decorate
--
> keys = in1 if key is None else map(key, in1)
> it = izip(keys, count(), in2)                           # decorate

See
http://svn.python.org/view/python/branches/py3k/Lib/heapq.py?rev=60206&view=diff&r1=60206&r2=60205&p1=python/branches/py3k/Lib/heapq.py&p2=/python/branches/py3k/Lib/heapq.py

With filter, availability of bool as a substitute for None is probably
making special handling unnecessary because __nonzero__ is called on
every object anyways.

In the case of map(None,...) the optimization is more substantial and
without None is precluded by the absence of a singleton identity function.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 22:30:02 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 25 Feb 2008 21:30:02 -0000
Subject: [issue2191] SubProcess Startup error
In-Reply-To: <1203970053.49.0.924039219535.issue2191@psf.upfronthosting.co.za>
Message-ID: <1203975002.23.0.633847376206.issue2191@psf.upfronthosting.co.za>


Facundo Batista added the comment:

IDLE works in a server/client configuration with itself. Most probably
the firewall is blocking IDLE's connections.

Best way to try this is full disabling the firewall, and trying. 

If it works, remember to activate the firewall back, and configure it
properly to work with IDLE.

----------
nosy: +facundobatista
resolution:  -> works for me
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2191>
__________________________________

From report at bugs.python.org  Mon Feb 25 22:32:10 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Feb 2008 21:32:10 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203975130.0.0.0092678359847.issue1394@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

>Yes, help with unit tests would be appreciated.  Especially since it is
>not supposed to fix anything, so I'm not sure what unit tests should be
>like...
Unit tests are just for bugfixes. They let us make sure Python is doing
what we want it to do in a given case. Your unit test will probably have
functions where you optimization should take effect and assert that it
does. For starters, take a look at Lib/test/test_peephole.py

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 22:50:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 25 Feb 2008 21:50:16 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1203975130.0.0.0092678359847.issue1394@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802251350x75650128m4d54f61206c2bb04@mail.gmail.com>


Guido van Rossum added the comment:

On Mon, Feb 25, 2008 at 1:32 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>  Unit tests are just for bugfixes.

I presume you meant "are *not* just for bugfixes".

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 23:05:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Feb 2008 22:05:49 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203977149.32.0.635663676417.issue1394@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

> I presume you meant "are *not* just for bugfixes".
(Sigh) Yes, of course.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Mon Feb 25 23:08:25 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Feb 2008 22:08:25 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203977305.41.0.708633991219.issue2186@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

FWIW, I didn't disagree on filter().  Am taking your suggestion under
advisement for a couple days.  At this point, I'm leaning towards
accepting the request (although with a different version of the patch).

For map(None, ...), I happy to live with examples like the patch you
referenced. It's important that this API be as simple and clean as
possible.  It's a matter of taste.  I concur with Guido that we never
would have created map(None, ...) if zip() had existed.  The primary use
case is obsolete.  

Also, I think the motivation behind your other use case will likey be
addressed in a more general way with an identify function being added to
the operator module.  That is a more explicit and less hackish than
having a special meaning for None.  It is also more in-line with the way
functional language approach the same problem.

Will meditate on both of these for a couple days and get back.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Mon Feb 25 23:33:43 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Mon, 25 Feb 2008 22:33:43 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203978823.48.0.139930985104.issue2168@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

Thomas, thanks for fixing this.  I didn't see any specific problems with
the patch, but I'm wondering why the code doesn't just call has_key in
both cases?

----------
nosy: +nnorwitz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Mon Feb 25 23:35:04 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 25 Feb 2008 22:35:04 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203978904.93.0.605122444429.issue2168@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Applied in r61072. 

Raymond, I stole this from you, because I had the same conclusion and it
was very needed for the buildbot.

Thank you all!

----------
nosy: +facundobatista
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Mon Feb 25 23:41:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Feb 2008 22:41:26 -0000
Subject: [issue2189] urllib.quote() throws KeyError when passed an iterator
In-Reply-To: <1203941389.03.0.634927871204.issue2189@psf.upfronthosting.co.za>
Message-ID: <1203979286.27.0.0131442970343.issue2189@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Does something in the docs lead you to believe urllib.quote should
accept a list of strings? The stdlib tends to shun type-checking to make
cleaner and faster code, and let the client get exceptions like these.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2189>
__________________________________

From report at bugs.python.org  Mon Feb 25 23:47:36 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Feb 2008 22:47:36 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203979656.75.0.932334697998.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

Proposed wording for a warning pointing that threads and imports can get
you in trouble. It might be better to squirrel off into a new subsection
on threaded imports, rather than giving it too much prominence (since
the recommended approach to creating subthreads should 'just work' -
it's only daemon threads and using the thread module directly that can
get you in trouble):

"""While the import machinery is thread safe, there are two key
restrictions on threaded imports due to inherent limitations in the way
that thread safety is provided.
Firstly, other than in the main module, an import should not have the
side effect of spawning a new thread and then waiting for that thread in
any way. Failing to abide by this restriction can lead to a deadlock if
the spawned thread directly or indirectly attempts to import a module.
Secondly, all import attempts must be completed before the interpreter
starts shutting itself down. This can be most easily achieved by only
performing imports from non-daemon threads created through the threading
module. Daemon threads and threads created directly with the thread
module will require some other form of synchronization to ensure they do
not attempt imports after system shutdown has commenced. Failure to
abide by this restriction will lead to intermittent exceptions and
crashes during interpreter shutdown (as the late imports attempt to
access machinery which is no longer in a valid state)."""

(If we were going to actually change anything in the code, it would be
to ensure that breaking the second restriction could only lead to
exceptions rather than crashes - I suspect that would be pretty messy
though, as there are a bunch of PyImport_* calls that currently can't
fail that would start having to be checked for error returns)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Mon Feb 25 23:49:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Mon, 25 Feb 2008 22:49:22 -0000
Subject: [issue1720705] thread + import => crashes?
Message-ID: <1203979762.69.0.674210457432.issue1720705@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

(oh, one thing - the 'crashes' mentioned in my proposed wording are due
to explicit calls to PyErr_FatalError rather than a segfault or anything
like that. The one specifically reported by the OP is due to sys.modules
being gone by the time an import is attempted)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1720705>
_____________________________________

From report at bugs.python.org  Mon Feb 25 23:56:42 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Feb 2008 22:56:42 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203980202.52.0.00951246479022.issue1394@psf.upfronthosting.co.za>


Changes by Raymond Hettinger:


----------
assignee:  -> rhettinger
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 00:06:20 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 23:06:20 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203980780.75.0.385496215307.issue2186@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Raymond,

it looks like you just broke the build for me:

/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c: In 
function 'ifilter_next':
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c:2058: 
error: invalid operands to binary ==
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c: In 
function 'ifilterfalse_next':
/Users/sasha/Work/python-svn/trunk/Modules/itertoolsmodule.c:2202: 
error: invalid operands to binary ==

$ svn update Modules/itertoolsmodule.c
At revision 61073.

(Mac OS 10.4)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 00:10:21 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Feb 2008 23:10:21 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203981021.8.0.699742569936.issue2186@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Alexander, please contact me directly at python at rcn dot com.

Need to figure-out why this works on my build but not yours.  There may
be an include file issue.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 00:13:05 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Mon, 25 Feb 2008 23:13:05 -0000
Subject: [issue2168] gdbm needs to be iterable
In-Reply-To: <1203780367.21.0.757207458085.issue2168@psf.upfronthosting.co.za>
Message-ID: <1203981185.64.0.50294043434.issue2168@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Thx.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2168>
__________________________________

From report at bugs.python.org  Tue Feb 26 00:33:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Feb 2008 23:33:23 -0000
Subject: [issue1986] io.StringIO allows any parameter
In-Reply-To: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>
Message-ID: <1203982403.39.0.926261199.issue1986@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

According to the docs: "When a StringIO object is created, it can be
initialized to an existing string by passing the string to the constructor."
So, it seems that that the docs are being too strict, or the code is
being too open. The conversion to str in the constructor is explicit, so
I'd favor leaving it be.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1986>
__________________________________

From report at bugs.python.org  Tue Feb 26 00:37:29 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 25 Feb 2008 23:37:29 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203982649.03.0.908505983523.issue1394@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Attached patch adds test_elim_unreachable() unit test.  Last two 
assertions should fail with unpatched python.

I am still trying to convince myself that the transformation are 
correct.

> I propose that codestr[] array is made one byte
> longer and RETURN_VALUE opcode wrote in that extra byte.

I don't think that will be correct.  Did you consider the following 
comment?

        /* Verify that RETURN_VALUE terminates the codestring.  This 
allows 
           the various transformation patterns to look ahead several 
           instructions without additional checks to make sure they are 
not 
           looking beyond the end of the code string. 
        */ 
        if (codestr[codelen-1] != RETURN_VALUE) 
                goto exitUnchanged;

Added file: http://bugs.python.org/file9555/test_peepholer.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 00:53:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 25 Feb 2008 23:53:13 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203983593.46.0.421502367885.issue2186@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

It appears Facundo fixed your problem.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 01:00:08 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Tue, 26 Feb 2008 00:00:08 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203984008.75.0.207319201077.issue1394@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

Thanks for writing the test.

Yes, I did read the comment.  As I understood it, RETURN_VALUE is needed
only so that various optimization can assume codestr[] cannot suddenly
end without one.  E.g. if you match for BINARY_ADD, you can safely check
the next command: if BINARY_ADD matched, there is a _guaranteed_ next
command, not an out-of-array failure.

Such proposed fake RETURN_VALUE _must_ be unreachable, so it must not be
problematic at all.  If it was reachable, real codestr[] would end in
reachable non-return command, which must not happen during compilation.
 I dunno, maybe interpreter guards against execution point falling of
the bytecode string, but in any case this must not happen in
non-corrupted files generated by the bytecode compiler.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 02:44:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Feb 2008 01:44:38 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1203990278.54.0.846993384879.issue1394@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Paul,

You are right.  I misunderstood that comment myself.  I've tried the 
attached modification to your patch (unreachable-code-1.diff) and it 
passes all tests while fixing msg62953  problem:

$ cat t.py 
def f():
    return 1
    1+2
from dis import dis
dis(f)

$ ./python.exe t.py
  6           0 LOAD_CONST               0 (None)
              3 RETURN_VALUE

Added file: http://bugs.python.org/file9556/unreachable-code-1.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 02:56:35 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Feb 2008 01:56:35 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203990995.48.0.818155715259.issue2186@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

What do you guys think about just making the predicate argument optional? 

   filter([-2,0,2]) --> -2, 2
   filter(pred, iterable)

One arg is the first case and two args is the second case.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 03:13:30 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Feb 2008 02:13:30 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203992010.39.0.561019633791.issue2186@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> What do you guys think about just making the predicate argument 
> optional?

You've read my mind! That what I was going to suggest if I realized that 
optional argument does not have to be the last one.

Looks like it would make sense to keep filterfalse with a similar 
change.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 03:27:23 2008
From: report at bugs.python.org (BM)
Date: Tue, 26 Feb 2008 02:27:23 -0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>


New submission from BM:

According to David M. Kristol, only comma, space and semi-colon are 
forbidden in the cookie Name. However, Python's Cookie.py rejects a 
colon too. At the same time, Java Cookie in the servlet implementation 
allows a colon and Perl too.

The fix would be to add a colon symbol into _LegalChars variable.

----------
components: Library (Lib)
messages: 63023
nosy: BM
severity: major
status: open
title: Cookie Colon Name Bug
versions: Python 2.4, Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
__________________________________

From report at bugs.python.org  Tue Feb 26 04:03:15 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Feb 2008 03:03:15 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1203994995.71.0.501615424862.issue2186@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> I think the motivation behind your other use case will likey be
> addressed in a more general way with an identify function being
> added to the operator module.

Quite true, but I thought operator.identity was dead and buried.  Can 
you update issue1673203 if some decision was made?

Note that in msg55022 I said: "If [the identity] proposal is accepted, 
it will make sense to deprecate the use of None as an identity function 
in map."  So there may be no disagreement at all.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 04:37:54 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 26 Feb 2008 03:37:54 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1203968364.29.0.15448913279.issue1740@psf.upfronthosting.co.za>
Message-ID: <bbaeab100802251937p536a4481u965a44e50a67f312@mail.gmail.com>


Brett Cannon added the comment:

On Mon, Feb 25, 2008 at 11:39 AM, Antoine Pitrou <report at bugs.python.org> wrote:
>
>  Antoine Pitrou added the comment:
>
>  Out of curiosity, what were the PEP 8 violations? Usually I try to
>  respect the coding guidelines.

There were three that pervaded the code.

1. A newline after the opening docstring quotes::

    """
    docstring
    """

is bad.

2. Use of camelCase for methods and variables is bad.

3. The doc string for classes is supposed to have a blank line between
the class definition line and the docstring itself.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Tue Feb 26 05:41:01 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 26 Feb 2008 04:41:01 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203990995.48.0.818155715259.issue2186@psf.upfronthosting.co.za>
Message-ID: <ca471dc20802252040l1cef565do3e7335794933fece@mail.gmail.com>


Guido van Rossum added the comment:

>  What do you guys think about just making the predicate argument optional?
>
>    filter([-2,0,2]) --> -2, 2
>    filter(pred, iterable)
>
>  One arg is the first case and two args is the second case.

-1. Apart from range() this is used nowhere else in Python. (Well, it
is in curses, but it's an abomination there too.) I'd rather keep
explicit None that *this*, though I really don't see what's wrong with
filter(bool, ...) -- you can even optimize for that pattern.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 05:59:59 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 26 Feb 2008 04:59:59 -0000
Subject: [issue2186] map and filter shouldn't support None as first argument
	(in Py3k only)
In-Reply-To: <1203912260.97.0.67586423055.issue2186@psf.upfronthosting.co.za>
Message-ID: <1204001999.14.0.844284466427.issue2186@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

Okay.  Will drop None in favor of bool() in ifilter and ifilterfalse. 
Also, it looks like there agreement on dropping None for map() and 
going forward with the operator.identity() patch.  Will check these in 
in the next couple of days.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2186>
__________________________________

From report at bugs.python.org  Tue Feb 26 06:38:47 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 26 Feb 2008 05:38:47 -0000
Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve
	error msg
Message-ID: <1204004327.0.0.366800703821.issue1691070@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

I looked over the new patch Christian uploaded and I think I understand
what's going on.  I didn't do a through comparison, but if all the tests
pass, I think that's good enough.  Good work!

Here are the issues I would like to see fixed before check in (all small
and easy):
 * Fix the format nits.  There were missing spaces around = and ==.
 * Remove the comment that says:
+				 * XXX TypeError doesn't seem right for this,
+				 * maybe create an ArgumentError ???
+				 * XXX Arg positions currently reported as
+				 * 1-based, contrary to most things in
+				 * python ???

    The first line of that comment should stay.
 * Expand the comment that says: Maybe skip this in debug build ?
    Add a XXX or TODO and explain why.  I think it's just that it would
give extra testing.  I'm not sure it's worth it since that would be
added code, but it's a valid question.

 * Verify that it's faster by compiling python in a release build (ie,
optimized, not debug with assertions) and do something that would
trivially execute the code.  For example:

  * ''.split()
  * ''.split('', 1)
  * (1,).index(1)
  * (1,).index(1, 0, 1)

That might be a decent set.  I just grepped for PyArg_ParseTuple
Objects/*.c and found some common cases where this code would be used. 
It would be great to add the timing info from the test cases above (as
well as the pybench results) to the check in message.

 * In the test do a single import at the top of the file.
 * Use raise Error('') instead of raise Error, '' in the test.  Actually
instead of raising an exception, call self.fail(error_message)

----------
resolution:  -> accepted

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691070>
_____________________________________

From report at bugs.python.org  Tue Feb 26 06:39:23 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 26 Feb 2008 05:39:23 -0000
Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve
	error msg
Message-ID: <1204004363.51.0.975846903876.issue1691070@psf.upfronthosting.co.za>


Changes by Neal Norwitz:


----------
assignee: nnorwitz -> tiran

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691070>
_____________________________________

From report at bugs.python.org  Tue Feb 26 06:58:48 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 26 Feb 2008 05:58:48 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1204005528.41.0.0938398281088.issue1394@psf.upfronthosting.co.za>


Neal Norwitz added the comment:

Can you add more tests?  It seems that almost all the examples given in
this thread are good examples.  Also something like:

  while 1:
    if cond: return 1
    return 2
  return 3

There are a bunch more cases that could be added for where the code
should be optimized or might be optimized wrong that.

The #if 0 code should be removed in the patch.  Also, since
CONTINUE_LOOP is removed in this patch, it would be good to explicitly
add a test for that.  

This patch looks good to me, but I'll let Raymond decide.  Did all the
entire test suite run?  Note, you must remove all the .pyc files to test
this patch or change the MAGIC number in Python/import.c.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 07:29:20 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Tue, 26 Feb 2008 06:29:20 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1197051927.23.0.805200385049.issue1569@psf.upfronthosting.co.za>
Message-ID: <1204007360.54.0.470027757857.issue1569@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven added the comment:

As taken from http://blogs.msdn.com/astebner/
archive/2006/08/23/715755.aspx

"Hi Didier - You should not try to install this vcredist package using 
a nested install.  Performing nested installs causes problems with 
installing hotfixes for the child packages.  You will need to use some 
kind of chainer to launch the vcredist setup package in silent mode, 
and then launch your main MSI setup afterwards."

vcredist 8 information: http://blogs.msdn.com/astebner/
archive/2007/02/07/update-regarding-silent-install-of-the-vc-8-0-
runtime-vcredist-packages.aspx

Some hints on how to redistribute vc++ libraries:

http://blogs.msdn.com/vcblog/archive/2007/10/12/how-to-redistribute-the-
visual-c-libraries-with-your-application.aspx

----------
nosy: +asmodai

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Tue Feb 26 07:36:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 26 Feb 2008 06:36:15 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1197051927.23.0.805200385049.issue1569@psf.upfronthosting.co.za>
Message-ID: <1204007775.81.0.426257601671.issue1569@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

asmodai, which details in these postings are you referring to
specifically? I find none of them helpful, wrt to packaging Python.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Tue Feb 26 07:49:16 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Tue, 26 Feb 2008 06:49:16 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1197051927.23.0.805200385049.issue1569@psf.upfronthosting.co.za>
Message-ID: <1204008556.73.0.257334940066.issue1569@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven added the comment:

The hints that the vcredist cannot/should not be installed nested, but 
should be chained.
The details on the full flags used/supported by the vcredist files.
And the last one how to do the merge modules (and some other 
scenario's) way of adding the dependency.

I have no idea of the level of Windows development of people, but at 
least this way some of the background information is logged somewhere.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Tue Feb 26 07:58:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Feb 2008 06:58:02 -0000
Subject: [issue1986] io.StringIO allows any parameter
In-Reply-To: <1201864727.99.0.0928794307411.issue1986@psf.upfronthosting.co.za>
Message-ID: <1204009082.53.0.517843663413.issue1986@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Okay, then I see this as a intended feature.

----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1986>
__________________________________

From report at bugs.python.org  Tue Feb 26 08:09:55 2008
From: report at bugs.python.org (Ian Kelly)
Date: Tue, 26 Feb 2008 07:09:55 -0000
Subject: [issue1167] gdbm/ndbm 1.8.1+ needs libgdbm_compat.so
In-Reply-To: <1189921072.53.0.557521657427.issue1167@psf.upfronthosting.co.za>
Message-ID: <1204009795.89.0.153922768805.issue1167@psf.upfronthosting.co.za>


Ian Kelly added the comment:

I'm not sure why you think this patch would be backwards incompatible. 
I've tested it with gdbm-1.8.0 and gdbm-1.7.3, and it works for those.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1167>
__________________________________

From report at bugs.python.org  Tue Feb 26 08:46:50 2008
From: report at bugs.python.org (Madhusudan SK)
Date: Tue, 26 Feb 2008 07:46:50 -0000
Subject: [issue2191] SubProcess Startup error
In-Reply-To: <1203975002.23.0.633847376206.issue2191@psf.upfronthosting.co.za>
Message-ID: <3ae315050802252346t2c32911dt3750a968749d51b2@mail.gmail.com>


Madhusudan SK added the comment:

hi,
thanks so much for the clarification but i never faced this problem
with 2.5.2. This is the only instance of pyhton that causes the
mentioned error.

On 2/26/08, Facundo Batista <report at bugs.python.org> wrote:
>
> Facundo Batista added the comment:
>
> IDLE works in a server/client configuration with itself. Most probably
> the firewall is blocking IDLE's connections.
>
> Best way to try this is full disabling the firewall, and trying.
>
> If it works, remember to activate the firewall back, and configure it
> properly to work with IDLE.
>
> ----------
> nosy: +facundobatista
> resolution:  -> works for me
> status: open -> closed
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2191>
> __________________________________
>

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2191>
__________________________________

From report at bugs.python.org  Tue Feb 26 09:51:44 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Feb 2008 08:51:44 -0000
Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve
	error msg
Message-ID: <1204015904.11.0.646435221632.issue1691070@psf.upfronthosting.co.za>


Christian Heimes added the comment:

> * Fix the format nits.  There were missing spaces around = and ==.

Oh, I missed the macro above the function. :]

> * Verify that it's faster by compiling python in a release build 

It's roughly the same speed. :/ The variation between timeit runs is
quite high on my machine. The new code is neither significant faster nor
noticeable slower.

./python Lib/timeit.py "for i in xrange(100): ''.split(); ''.split(' ',
1); (1,).index(1); (1,).index(1, 0, 1)"
1000 loops, best of 3: 342 usec per loop

The timing distributes about +-15usec with 400+ every now and then.

./python Lib/timeit.py -s "def func(a, b, c=None, d=None, e=None): pass"
"for i in xrange(100): func(a=1, b=2); func(b=1, a=2, d=3, c=4, e=5)"

This benchmark shows a noticeable speedup. It's about 205usec with patch
and 225usec without patch.

Added file: http://bugs.python.org/file9557/trunk_getargs_speedup2.patch

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691070>
_____________________________________

From report at bugs.python.org  Tue Feb 26 10:46:36 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Tue, 26 Feb 2008 09:46:36 -0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1204019196.73.0.947240519282.issue2193@psf.upfronthosting.co.za>


Jerry Seutter added the comment:

Hm.  Your bug doesn't agree with my interpretation of the RFC's.

RFC2109 section 4.1 states that the the cookie name (attr) is of type
"token", which in RFC2068 section 2.2 is defined as any chars excluding
control characters and special characters.  RFC2068 lists special
characters as 
tspecials      = "(" | ")" | "<" | ">" | "@"
                         | "," | ";" | ":" | "\" | <">
                         | "/" | "[" | "]" | "?" | "="
                         | "{" | "}" | SP | HT

... so the ":" in a cookie name should not be allowed.

RFC2965 and RFC2616 (which obsolete the above RFC's) state the same thing.

Either I'm wrong or the other languages you cite are differing from the
RFC.  Do you have any idea why they might be doing that?

----------
nosy: +jseutter

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
__________________________________

From report at bugs.python.org  Tue Feb 26 13:18:45 2008
From: report at bugs.python.org (BM)
Date: Tue, 26 Feb 2008 12:18:45 -0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1204028325.04.0.301053174916.issue2193@psf.upfronthosting.co.za>


BM added the comment:

OK, I see and agree there are no actually that standard 
that we can call as a standard. But let me try to put in 
the other way again:

1. This documentation refers to the same RFC2109:
http://docs.python.org/lib/module-Cookie.html
But the RFC is slightly older than next David's edition.


2. David M. Kristol's cookie overview also says that only comma, 
semi-column and a space is not allowed. 
Here you go: http://arxiv.org/abs/cs.SE/0105018


3. Java implements the *same* RFC2109 but supports a colon too, 
as oppose to Python version. Here is the link to the source of
Tomcat 6 (the latest one):
http://www.google.com/codesearch?
hl=en&q=show:okuSsOjruck:iKnUOb7eVzc:kvBYp8tS5ms&sa=N&ct=rd&cs_p=ftp://apache.mirrors.pair.com/tomcat/tomcat-
6/v6.0.10/src/apache-tomcat-6.0.10-src.zip&cs_f=apache-tomcat-6.0.10-
src/java/javax/servlet/http/Cookie.java&start=1

As you can see, there is no 0x3a to be excluded. The snippet is:
-----------------------------------------------
private static final String tspecials = ",; ";

private boolean isToken(String value) {
    int len = value.length();
    for (int i = 0; i < len; i++) {
        char c = value.charAt(i);
        if (c < 0x20 || c >= 0x7f || tspecials.indexOf(c) != -1)
            return false;
        }
    return true;
}
-----------------------------------------------
I agree, Java is not a standard, but yet another (buggy) language. :-)
Still it means something...


4. Perl module from CPAN does the same and allows a colon.
http://search.cpan.org/~gaas/libwww-perl-5.808/lib/HTTP/Cookies.pm

5. You probably refer to the old Netscape specs 
(http://wp.netscape.com/newsref/std/cookie_spec.html) that 
for instance allows to contain an unquoted "," in the expires 
field, so usually new parser have to use special ad-hoc way to 
get it right. 

The difference between old format of cookies and new one is,
that cookie name begins with a $. So the old format expects 
these cookies to be separated by semi-colon, not comma. 


6. I am not very sure that tokens you are talking about are
referring to NAME of Set-Cookie NAME=VALUE pair. Because the
same section allows a white space between tokens, while it is
not very true. Moreover, braces etc *are* allowed. The reason
why comma, space and semi-colon are disallowed, because of
parser should know where it what. Other symbols parsers does
not care...


7. Maybe we should ask D.Kristol for this after all. :-)


Hm... What do you think? :)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
__________________________________

From report at bugs.python.org  Tue Feb 26 13:19:08 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 26 Feb 2008 12:19:08 -0000
Subject: [issue2173] Pyton fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1204028348.89.0.0837998855136.issue2173@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Same here, Ubuntu on x86 32b.

Doing first a "make clean", ./configure runs ok.

But then, in the "make":

...
  File "/home/facundo/devel/reps/python/py3k/Lib/locale.py", line 479,
in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
make: *** [sharedmods] Error 1

Full make output is attached.

The problem seems to be in the setlocale module. I compiled everything
with LANG in es_AR.UTF-8, but then executing Python again with a bad locale:

facundo at virtub:~/devel/reps/python/py3k$ LANG=UTF-8 ./python 
Python 3.0a2+ (py3k:61084, Feb 26 2008, 10:12:19) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.getpreferredencoding()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/facundo/devel/reps/python/py3k/Lib/locale.py", line 515,
in getpreferredencoding
    setlocale(LC_CTYPE, "")
  File "/home/facundo/devel/reps/python/py3k/Lib/locale.py", line 479,
in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting
>>> 

Regards,

----------
nosy: +facundobatista
Added file: http://bugs.python.org/file9558/full_make_output.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
__________________________________

From report at bugs.python.org  Tue Feb 26 14:10:06 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Feb 2008 13:10:06 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1204031406.17.0.619967484837.issue1394@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I have added more tests as Neal suggested. See unreachable-code-with-
tests.diff for a combined patch.  I've rerun all tests after removing 
.pyc files and also with -O option (ensuring no existing .pyo files as 
well). All works.

I've removed #if 0  block and changed "Verify" to "Ensure" in the 
RETURN_VALUE comment.  Paul, maybe you and add an explanation why the 
added RETURN_VALUE will always be eliminated.  I am not sure when python  
produces code with no terminating RETURN_VALUE in the first place.

Added file: http://bugs.python.org/file9559/unreachable-code-with-tests.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 14:45:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Feb 2008 13:45:22 -0000
Subject: [issue1673203] add identity function
Message-ID: <1204033522.18.0.0615723699208.issue1673203@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Raymond Hettinger wrote in msg63027 (issue2186):

"""
.. it looks like there [is an] agreement on dropping None for map() and 
going forward with the operator.identity() patch.  Will check these in 
in the next couple of days.
"""

This leaves open the issue of multi-argument identity.  I would argue 
that def identity(*args): return args[-1] # or args[0] will conflict 
with the use of identity instead of None in map: map(identity, x, y, ..) 
will silently produce results different from current map(None, x, y, 
..).  It is possible to make identity behave exactly like None in map by 
defining it  as

def identity(*args):
   if len(args) == 1:
      return args[0]
   else:
      return args
 
While there is certain cuteness in making identity(...) equivalent to 
(...), it is a bit too cute for my taste.  I am -1 on multi-argument 
identity.

Also placement of identity in operator while map is in builtin, may 
complicate implementation of passthrough map optimization.  While it is 
possible to avoid importing operator in builtin by implementing identity  
in builtin but exporting it only from operator, a more straightforward 
solution would be to keep map and identity in the same module.  This 
logic may be a slippery slope, however, because optimizing filterfalse, 
would suggest that operator.not_ should be moved in the same module as 
the ultimate location for filterfalse. I am +1 on implementing 
optimization for map(identity, ..), +0 on that for filterfalse(not_, 
..), 0 on the location of identity. (BTW, maybe we should implement 
optimization for filter(not_, ..) and drop filterfalse altogether.)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1673203>
_____________________________________

From report at bugs.python.org  Tue Feb 26 15:26:52 2008
From: report at bugs.python.org (Michael Otteneder)
Date: Tue, 26 Feb 2008 14:26:52 -0000
Subject: [issue2173] Pyton fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1204036012.13.0.7826579695.issue2173@psf.upfronthosting.co.za>


Michael Otteneder added the comment:

Interestingly it fails with a different error message on Mac. The Ubuntu
one is at least helpful.
I get this during make(configure also runs fine) :
gcc  -u _PyMac_Error -o python.exe \
			Modules/python.o \
			libpython3.0.a -ldl      
make: *** [sharedmods] Error 1

The created python.exe also behaves very strange:
Tinuviel:py3k mc$ ./python.exe 
Python 3.0a2+ (py3k:61071, Feb 26 2008, 14:50:42) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> print("hello")
>>> exit()
>>> exit()
>>> dfklasjd
>>> 

Locales:
Tinuviel:py3k mc$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=


Solution: set LANG to "C" or some other valid value.

Added file: http://bugs.python.org/file9560/make.log

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
__________________________________

From report at bugs.python.org  Tue Feb 26 15:29:53 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Tue, 26 Feb 2008 14:29:53 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1204036193.85.0.239174141793.issue1394@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

Well, I cannot guarantee it will _always_ be eliminated, since I too
don't really know when generated bytecode can (currently) end in
non-return.  However, if before it ended in non-return, that non-return
must have been unreachable, obviously (else code flow would fall off of
the valid bytecode string).  So, there is pretty good chance that this
patch will remove both the unreachable code and the fake return byte. 
In the worst case, we increase bytecode length by 1 byte, but we always
enable peephole optimizer, which can be expected to give a much more
significant gain.

As your unit tests suggest, the patch doesn't always remove unreachable
code, because some opcodes after which this can be done are already
handled differently.  Also, there might in theory be some false block
boundaries (e.g. a jump from unreachable code to another piece of such
code).

BTW, I think that just removing #if 0'd block is not correct.  I propose
to convert it to a comment then, just to explain that there are more
opcodes after which we can expect unreachable code and don't check only
because it'd give duplicate case labels.  Maybe some goto magic can
handle them, don't have sources here.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 15:31:43 2008
From: report at bugs.python.org (Michael Otteneder)
Date: Tue, 26 Feb 2008 14:31:43 -0000
Subject: [issue2173] Pyton fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1204036303.8.0.0938010984565.issue2173@psf.upfronthosting.co.za>


Michael Otteneder added the comment:

On my system I get different results. The error message is everything
but useful.
My Output:
gcc  -u _PyMac_Error -o python.exe \
			Modules/python.o \
			libpython3.0.a -ldl      
make: *** [sharedmods] Error 1
Tinuviel:py3k mc$ ./python.exe 
Python 3.0a2+ (py3k:61071, Feb 26 2008, 14:50:42) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> print("hello")
>>> exit()
>>> exit()
>>> dfklasjd
>>> 

Locales:
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

Added file: http://bugs.python.org/file9561/make.log

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
__________________________________

From report at bugs.python.org  Tue Feb 26 15:38:21 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Tue, 26 Feb 2008 14:38:21 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1204036701.07.0.350928573678.issue1394@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

Actually, it is even better.  Since you don't increment codelen, that
extra RETURN_VALUE is "virtual" in that it acts as a sentinel, but will
not appear in the resulting bytecode.  You can test this by backing out
the patch and disassembling something.  For this reason, if() before
writing the RETURN_VALUE is not needed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 16:25:20 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 26 Feb 2008 15:25:20 -0000
Subject: [issue1394] simple patch, improving unreachable bytecode removing
In-Reply-To: <1194300541.67.0.109986222934.issue1394@psf.upfronthosting.co.za>
Message-ID: <1204039520.25.0.955909755537.issue1394@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

> Since you don't increment codelen ..

Good catch!

> For this reason, if() before
> writing the RETURN_VALUE is not needed.

In this case it will be clearer to use STOP_CODE instead of RETURN_VALUE 
as a sentinel.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1394>
__________________________________

From report at bugs.python.org  Tue Feb 26 16:31:05 2008
From: report at bugs.python.org (Quentin Gallet-Gilles)
Date: Tue, 26 Feb 2008 15:31:05 -0000
Subject: [issue1524825] ConfigParser: accept leading whitespace on
	options+comments
Message-ID: <1204039865.74.0.68750760633.issue1524825@psf.upfronthosting.co.za>


Quentin Gallet-Gilles added the comment:

Okay, I'll upload a patch with unit tests and doc changes for the
comment part in the next few days.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1524825>
_____________________________________

From report at bugs.python.org  Tue Feb 26 16:45:54 2008
From: report at bugs.python.org (Tim Golden)
Date: Tue, 26 Feb 2008 15:45:54 -0000
Subject: [issue2194] Tiny patch to docs
In-Reply-To: <1204040754.9.0.589972420385.issue2194@psf.upfronthosting.co.za>
Message-ID: <1204040754.9.0.589972420385.issue2194@psf.upfronthosting.co.za>


New submission from Tim Golden:

A patch against r61085 of /doc to correct some very minor typos in the docs

----------
components: Documentation
files: python-doc-r61085.patch
keywords: patch
messages: 63048
nosy: tim.golden
severity: minor
status: open
title: Tiny patch to docs
versions: Python 2.6
Added file: http://bugs.python.org/file9562/python-doc-r61085.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2194>
__________________________________

From report at bugs.python.org  Tue Feb 26 17:15:04 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 26 Feb 2008 16:15:04 -0000
Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve
	error msg
In-Reply-To: <1204015904.11.0.646435221632.issue1691070@psf.upfronthosting.co.za>
Message-ID: <ee2a432c0802260814l6df36b47y28b4bfce10872f43@mail.gmail.com>


Neal Norwitz added the comment:

On Tue, Feb 26, 2008 at 12:51 AM, Christian Heimes
<report at bugs.python.org> wrote:
>
>  > * Verify that it's faster by compiling python in a release build
>
>  It's roughly the same speed. :/ The variation between timeit runs is
>  quite high on my machine. The new code is neither significant faster nor
>  noticeable slower.

Use your best judgment.  I haven't looked at the resulting code, only
the patch so it's hard for me to know for certain.  It appears the
patch simplifies the code, so even if there is no speed benefit, there
may be a maintainability benefit.  It's up to you.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691070>
_____________________________________

From report at bugs.python.org  Tue Feb 26 19:25:20 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Feb 2008 18:25:20 -0000
Subject: [issue1691070] Speed up PyArg_ParseTupleAndKeywords() and improve
	error msg
Message-ID: <1204050320.16.0.306301517554.issue1691070@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I've applied the patch in r61086.

----------
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1691070>
_____________________________________

From report at bugs.python.org  Tue Feb 26 19:26:55 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 26 Feb 2008 18:26:55 -0000
Subject: [issue2194] Tiny patch to docs
In-Reply-To: <1204040754.9.0.589972420385.issue2194@psf.upfronthosting.co.za>
Message-ID: <1204050415.51.0.621581923453.issue2194@psf.upfronthosting.co.za>


Changes by Christian Heimes:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl
priority:  -> normal
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2194>
__________________________________

From report at bugs.python.org  Tue Feb 26 20:06:13 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 26 Feb 2008 19:06:13 -0000
Subject: [issue2001] Pydoc interactive browsing enhancement
In-Reply-To: <1201993553.04.0.86516199449.issue2001@psf.upfronthosting.co.za>
Message-ID: <1204052773.05.0.207784300191.issue2001@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2001>
__________________________________

From report at bugs.python.org  Tue Feb 26 20:07:32 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 26 Feb 2008 19:07:32 -0000
Subject: [issue2169] Adding DOCTYPE and "html", "body" tags to SimpleHTTPServer
In-Reply-To: <1203787685.42.0.819164609071.issue2169@psf.upfronthosting.co.za>
Message-ID: <1204052852.98.0.699375438248.issue2169@psf.upfronthosting.co.za>


Changes by A.M. Kuchling:


----------
assignee:  -> akuchling
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2169>
__________________________________

From report at bugs.python.org  Tue Feb 26 20:08:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Feb 2008 19:08:09 -0000
Subject: [issue2173] Python fails silently on bad locale
In-Reply-To: <1203848790.48.0.462049623826.issue2173@psf.upfronthosting.co.za>
Message-ID: <1204052889.17.0.884568637679.issue2173@psf.upfronthosting.co.za>


Changes by Georg Brandl:


----------
title: Pyton fails silently on bad locale -> Python fails silently on bad locale

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2173>
__________________________________

From report at bugs.python.org  Tue Feb 26 20:13:59 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 26 Feb 2008 19:13:59 -0000
Subject: [issue2194] Tiny patch to docs
In-Reply-To: <1204040754.9.0.589972420385.issue2194@psf.upfronthosting.co.za>
Message-ID: <1204053239.32.0.246972693448.issue2194@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks, committed as r61087!

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2194>
__________________________________

From report at bugs.python.org  Tue Feb 26 20:32:27 2008
From: report at bugs.python.org (aka)
Date: Tue, 26 Feb 2008 19:32:27 -0000
Subject: [issue2192] error with backslash as last character in raw string
In-Reply-To: <1203970849.09.0.517389508699.issue2192@psf.upfronthosting.co.za>
Message-ID: <47C4693F.7000308@web.de>


aka added the comment:

Hello Raghuram,
thanks for your reply. I am sorry that I didn't find this description 
before posting the error. But, reading the description I still find the 
behaviour of the interpreter a bug ;-)

Regards, Axel

Raghuram Devarakonda schrieb:
> Raghuram Devarakonda added the comment:
> 
> This is as per the design. Please see
> http://www.python.org/doc/faq/general/#why-can-t-raw-strings-r-strings-end-with-a-backslash.
> 
> ----------
> nosy: +draghuram
> resolution:  -> invalid
> status: open -> closed
> 
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2192>
> __________________________________
>

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2192>
__________________________________

From report at bugs.python.org  Tue Feb 26 20:56:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 26 Feb 2008 19:56:07 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1204008556.73.0.257334940066.issue1569@psf.upfronthosting.co.za>
Message-ID: <47C46ED3.3040509@v.loewis.de>


Martin v. L?wis added the comment:

> The hints that the vcredist cannot/should not be installed nested, but 
> should be chained.

So how do I do chaining if I can only ship a single MSI file (which is
my objective)?

> The details on the full flags used/supported by the vcredist files.

I don't think using vcredist can work at all. I would be happy to
be proven wrong, but I really cannot see a solution to use it. Instead,
I believe the merge module must be used.

> And the last one how to do the merge modules (and some other 
> scenario's) way of adding the dependency.

Which way specifically are you referring to? Using Visual Studio?
I don't think Visual Studio is capable of producing the output
that we desire (but again, I would be happy to be proven wrong).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Tue Feb 26 23:31:54 2008
From: report at bugs.python.org (Gawain Bolton)
Date: Tue, 26 Feb 2008 22:31:54 -0000
Subject: [issue2195] urlparse()
In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>
Message-ID: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>


New submission from Gawain Bolton:

The urlparse() function in urlparse module does not handle URLs without 
an explicit scheme and with port numbers.

The following works as expected:
>>> urlparse.urlparse('foo.bar.com','http').scheme
'http'

But if the URL has a port number then the scheme is wrong:
>>> urlparse.urlparse('foo.bar.com:8080','http').scheme
'foo.bar.com'

I have read RFC 1808 and its description of the parsing of the scheme 
also has this bug.  From what I can figure, the parsing algorithm needs 
to search for the scheme before the substring "://" and not just ":".

----------
components: Library (Lib)
messages: 63054
nosy: gawain
severity: normal
status: open
title: urlparse()
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2195>
__________________________________

From report at bugs.python.org  Tue Feb 26 23:32:45 2008
From: report at bugs.python.org (Gawain Bolton)
Date: Tue, 26 Feb 2008 22:32:45 -0000
Subject: [issue2195] urlparse() does not handle URLs with port numbers properly
In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>
Message-ID: <1204065165.53.0.146370715695.issue2195@psf.upfronthosting.co.za>


Changes by Gawain Bolton:


----------
title: urlparse() -> urlparse() does not handle URLs with port numbers properly

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2195>
__________________________________

From report at bugs.python.org  Tue Feb 26 23:51:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 26 Feb 2008 22:51:55 -0000
Subject: [issue2196] Fix hasattr's exception problems
In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za>
Message-ID: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za>


New submission from Benjamin Peterson:

hasattr currently returns False when any exception happens in getattr. I
see that this tracker I previous patches trying to fix this issue, but
they were rejected because they only tried to catch attribute errors. My
patch only propagates SystemExit and KeyboardInterrupt exceptions.

----------
components: Interpreter Core, Tests
files: hasattr_fixes.diff
keywords: patch
messages: 63055
nosy: benjamin.peterson
severity: normal
status: open
title: Fix hasattr's exception problems
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9563/hasattr_fixes.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2196>
__________________________________

From report at bugs.python.org  Wed Feb 27 00:26:36 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 26 Feb 2008 23:26:36 -0000
Subject: [issue745097] urllib2 doesn't handle urls without scheme
Message-ID: <1204068396.41.0.345045427663.issue745097@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Closing because it isn't clear if it's a bug (describe why do you think
it's wrong the actual state) or a feature request (describe what exactly
do you want/propose for the future).

Note that most probably urllib and urllib2 will be merged for py3k.

----------
nosy: +facundobatista
resolution:  -> invalid
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue745097>
____________________________________

From report at bugs.python.org  Wed Feb 27 00:29:59 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 26 Feb 2008 23:29:59 -0000
Subject: [issue722647] lower-level API for longs
Message-ID: <1204068599.47.0.0686972879587.issue722647@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Gregory, you're keeping this as a recordatory (it passed almost five
years and a lot of water under "long" bridge), or can be closed?

Thank you!

----------
nosy: +facundobatista

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue722647>
____________________________________

From report at bugs.python.org  Wed Feb 27 03:29:00 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 27 Feb 2008 02:29:00 -0000
Subject: [issue686667] os.spawnv(P_WAIT, ...) on Linux doesn't handle EINTR
Message-ID: <1204079340.78.0.744015538433.issue686667@psf.upfronthosting.co.za>


Facundo Batista added the comment:

spawnv is deprecated, use sobprocess instead.

And please, if you say to find the same issue in subprocess, provide a
test case to check what you say.

Thanks!!

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue686667>
____________________________________

From report at bugs.python.org  Wed Feb 27 03:38:01 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 27 Feb 2008 02:38:01 -0000
Subject: [issue1157255] PEP 328 and Python 2.4 error
Message-ID: <1204079881.47.0.763385057449.issue1157255@psf.upfronthosting.co.za>


Facundo Batista added the comment:

import mechanisms and absolute and relative imports were reviewed recently.

Please verify if you still have an issue regarding this.

Thank you!

----------
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1157255>
_____________________________________

From report at bugs.python.org  Wed Feb 27 03:41:21 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 27 Feb 2008 02:41:21 -0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1204080081.45.0.869712662428.issue1152248@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Raymond disapproved it, Skip discouraged it, and Nick didn't push it any
more, all more than two years ago.

Nick, please, if you feel this is worthwhile, raise the discussion in
python-dev.

----------
nosy: +facundobatista
resolution:  -> rejected
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_____________________________________

From report at bugs.python.org  Wed Feb 27 03:53:06 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 27 Feb 2008 02:53:06 -0000
Subject: [issue1123716] descrintro describes __new__ and __init__ behavior
	wrong
Message-ID: <1204080786.75.0.266873803018.issue1123716@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Documentation had several updates in these 2+ years.

Now it says:

"""
If __new__() returns an instance of cls, then the new instance?s
__init__() method will be invoked like __init__(self[, ...]), where self
is the new instance and the remaining arguments are the same as were
passed to __new__().

If __new__() does not return an instance of cls, then the new instance?s
__init__() method will not be invoked.
"""

, which is clearer.

Thanks!

----------
nosy: +facundobatista
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1123716>
_____________________________________

From report at bugs.python.org  Wed Feb 27 04:14:01 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 27 Feb 2008 03:14:01 -0000
Subject: [issue1106316] slightly easier way to debug from the exception handler
Message-ID: <1204082041.97.0.893380210437.issue1106316@psf.upfronthosting.co.za>


Facundo Batista added the comment:

If there's no objections, I'd make the traceback parameter optional in
the post_mortem method, making it default to sys.exc_info()[2].

Thanks!

----------
assignee:  -> facundobatista
nosy: +facundobatista

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1106316>
_____________________________________

From report at bugs.python.org  Wed Feb 27 05:42:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Feb 2008 04:42:38 -0000
Subject: [issue2197] Further simplify dict literal bytecode
In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>
Message-ID: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky:

I am attaching a proof-of-concept patch that changes the bytecode 
generated from {1:1,2:2,3:3,4:4} from 

BUILD_MAP                4  
LOAD_CONST               2 (1)  
LOAD_CONST               2 (1)  
STORE_MAP             
LOAD_CONST               1 (2)  
LOAD_CONST               1 (2)  
STORE_MAP             
LOAD_CONST               4 (3)  
LOAD_CONST               4 (3)  
STORE_MAP             
LOAD_CONST               3 (4)  
LOAD_CONST               3 (4)  
STORE_MAP             

to

LOAD_CONST               1 (4)  
LOAD_CONST               1 (4)  
LOAD_CONST               2 (3)   
LOAD_CONST               2 (3)                                                    
LOAD_CONST               3 (2)                                        
LOAD_CONST               3 (2)                                         
LOAD_CONST               4 (1)  
LOAD_CONST               4 (1)  
BUILD_MAP                4  
 
and changes BUILD_MAP to behave similarly to BUILD_(SET|LIST|TUPLE) and 
consume 2*n items from the stack.

The advantage is more compact and faster bytecode and uniform treatment 
of BUILD_* instructions.

----------
components: Interpreter Core
files: dict-literal.diff
keywords: patch
messages: 63063
nosy: belopolsky
severity: normal
status: open
title: Further simplify dict literal bytecode
versions: Python 3.0
Added file: http://bugs.python.org/file9564/dict-literal.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2197>
__________________________________

From report at bugs.python.org  Wed Feb 27 06:03:31 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Feb 2008 05:03:31 -0000
Subject: [issue2197] Further simplify dict literal bytecode
In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>
Message-ID: <1204088611.87.0.5679135299.issue2197@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Hmm, it looks like this was considered before (issue402227), but back 
then there were no set literals.  If stack-saving approach is better for 
dicts, it should be better for sets as well.  In any case, maybe it is 
time to revisit the issue and decide on the best way to treat both set 
and dict literals.  The truth may very well be that up to certain size 
it is better to build set/dict all at once from the stack, but past that 
size incremental insertion is better. The hybrid approach would be easy 
to implement.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2197>
__________________________________

From report at bugs.python.org  Wed Feb 27 06:46:29 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Feb 2008 05:46:29 -0000
Subject: [issue2197] Further simplify dict literal bytecode
In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>
Message-ID: <1204091188.77.0.939605199397.issue2197@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

This changes semantics by executing all of the stores after the inputs 
are generated.  All of the pending item pairs get built-up on an ever-
growing stack instead of being consumed pairwise, never deepening the 
stack by more than two.

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2197>
__________________________________

From report at bugs.python.org  Wed Feb 27 09:35:38 2008
From: report at bugs.python.org (Thomas Herve)
Date: Wed, 27 Feb 2008 08:35:38 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1199583606.98.0.490636410107.issue1740@psf.upfronthosting.co.za>
Message-ID: <1204101338.51.0.0569939967075.issue1740@psf.upfronthosting.co.za>


Thomas Herve added the comment:

I have just one comment: I have recently modified the initialization of
LogRecordSocketReceiver to not use a stupid loop to get a free port, but
instead use port 0 and get the port number once bound. I think this
modification should stay.

----------
nosy: +therve

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Wed Feb 27 09:48:49 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 27 Feb 2008 08:48:49 -0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1204102129.92.0.482322743085.issue1152248@psf.upfronthosting.co.za>


Raymond Hettinger added the comment:

For the record, I thought it was a reasonable request.

AWK has a similar feature.  The AWK book shows a number of example 
uses.  Google's codesearch shows that the feature does get used in the 
field:  http://www.google.com/codesearch?q=lang%3Aawk+RS&hl=en

I think this request should probably be kept open.

----------
resolution: rejected -> 
status: closed -> open

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_____________________________________

From report at bugs.python.org  Wed Feb 27 12:08:11 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 27 Feb 2008 11:08:11 -0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1204110491.78.0.586557525588.issue1152248@psf.upfronthosting.co.za>


Facundo Batista added the comment:

Sorry, I misunderstood you. I assign this to myself to give it a try.

----------
assignee:  -> facundobatista

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_____________________________________

From report at bugs.python.org  Wed Feb 27 12:09:56 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 27 Feb 2008 11:09:56 -0000
Subject: [issue1740] use unittest for test_logging
In-Reply-To: <1204101338.51.0.0569939967075.issue1740@psf.upfronthosting.co.za>
Message-ID: <47C54501.1060209@cheimes.de>


Christian Heimes added the comment:

Thomas Herve wrote:
> I have just one comment: I have recently modified the initialization of
> LogRecordSocketReceiver to not use a stupid loop to get a free port, but
> instead use port 0 and get the port number once bound. I think this
> modification should stay.

Most likely the student, who submitted the patch during the GHOP
contest, didn't know about the feature. ;) But yeah, the mod should stay
indeed.

Christian

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1740>
__________________________________

From report at bugs.python.org  Wed Feb 27 12:10:16 2008
From: report at bugs.python.org (Matej Cepl)
Date: Wed, 27 Feb 2008 11:10:16 -0000
Subject: [issue1170] shlex have problems with parsing unicode
In-Reply-To: <1190045833.27.0.172281845017.issue1170@psf.upfronthosting.co.za>
Message-ID: <1204110616.0.0.78438251263.issue1170@psf.upfronthosting.co.za>


Changes by Matej Cepl:


----------
nosy: +mcepl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1170>
__________________________________

From report at bugs.python.org  Wed Feb 27 12:31:43 2008
From: report at bugs.python.org (=?utf-8?q?=CE=A7=CF=81=CE=AE=CF=83=CF=84=CE=BF=CF=82_=CE=93=CE=B5=CF=89=CF=81=CE=B3=CE=AF=CE=BF=CF=85_(Christos_Georgiou)?=)
Date: Wed, 27 Feb 2008 11:31:43 -0000
Subject: [issue2195] urlparse() does not handle URLs with port numbers properly
In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>
Message-ID: <1204111903.55.0.208791507702.issue2195@psf.upfronthosting.co.za>


??????? ???????? (Christos Georgiou) added the comment:

RFC1808 ?2.1 suggests a generic RL syntax that specifies '://' as the
separator, so Gawain's suggestion makes practical sense. However, also
as Gawain says, the RFC specifies that '//' is considered as the first
part of a "net_path" and is not necessarily included (example:
"mailto:tzot at sil-tec.gr" (and yes, I actually welcome spammers :) ).

I believe that urlparse should stay as-is when not called with a
default_scheme argument, and fixed as-suggested when called with a
default_scheme argument (that's the point for providing default_scheme).

----------
nosy: +tzot

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2195>
__________________________________

From report at bugs.python.org  Wed Feb 27 14:29:55 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Feb 2008 13:29:55 -0000
Subject: [issue2197] Further simplify dict literal bytecode
In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>
Message-ID: <1204118995.79.0.0868784215009.issue2197@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

I did not think of the insertion after creation change of semantics.  Do 
I understand that this is important when keys have custom 
comparison/hash methods with side-effects.  If it is important for the 
language to guarantee the create/insert order in building dict literals, 
it would be unfortunate if that order were specified differently for 
dict and set literals.

I will think some more about the stack issue.  There is a valid argument 
that large dict literals will be more common than large set literals, so 
the stack issue is more important for dicts.

BTW, what is the status of making set literal a frozen set proposal?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2197>
__________________________________

From report at bugs.python.org  Wed Feb 27 16:41:39 2008
From: report at bugs.python.org (Senthil)
Date: Wed, 27 Feb 2008 15:41:39 -0000
Subject: [issue2195] urlparse() does not handle URLs with port numbers properly
In-Reply-To: <1204065114.68.0.139974159124.issue2195@psf.upfronthosting.co.za>
Message-ID: <1204126899.23.0.538555012508.issue2195@psf.upfronthosting.co.za>


Senthil added the comment:

I don't think this is a valid issue. If you browse through the RFC 1808
you will find that.
1) For net_loc information it refers to a broad section 1738 and we wont
specifically find any information on port number in that.
2) But, have a look at the BNF Representation of the net_loc

net_loc     =  *( pchar | ";" | "?" )
pchar       = uchar | ":" | "@" | "&" | "="

There it dismisses this issue.

The port number is a property of the scheme in the absolute URL
notation. so, urlparse.urlparse('foo.bar.com',8088).scheme would give
you the port.

If someone can validate my reasoning, then we can close this issue.

----------
nosy: +orsenthil

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2195>
__________________________________

From report at bugs.python.org  Wed Feb 27 17:21:25 2008
From: report at bugs.python.org (Armin Rigo)
Date: Wed, 27 Feb 2008 16:21:25 -0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1204129285.06.0.343181381985.issue2181@psf.upfronthosting.co.za>


Armin Rigo added the comment:

I suppose you are aware that performing this optimization in general
would break a lot of existing code that uses inspect.getstack() or
sys._getframe() to peek at the caller's local variables.  I know this
because it's one thing that Psyco doesn't do correctly, and one of the
most common causes I'm aware of for a random existing program to break
under Psyco.

----------
nosy: +arigo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Wed Feb 27 17:32:13 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 27 Feb 2008 16:32:13 -0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1204129285.06.0.343181381985.issue2181@psf.upfronthosting.co.za>
Message-ID: <ee2a432c0802270832k2416f629t8a3a4b505ea1e0d@mail.gmail.com>


Neal Norwitz added the comment:

>  I suppose you are aware that performing this optimization in general
>  would break a lot of existing code that uses inspect.getstack() or
>  sys._getframe() to peek at the caller's local variables.  I know this

Yes, with this optimization the variable might never be set or when
the function exits, the value would be set to the previous value.

Note that the current optimization only works just before a return and
only for local variables.  It doesn't generally optimize out
variables, although that would be a good next step.

>  because it's one thing that Psyco doesn't do correctly, and one of the
>  most common causes I'm aware of for a random existing program to break
>  under Psyco.

How often does this cause problems?  Do you view this as psyco's
problem or broken user code?

I don't view this any different that a C compiler optimizing out
variables.  It can make debugging harder since the symbols no longer
exist.  In this case the variable name is not removed from the
co_varnames even if it is the only reference.  That would also be
nice, but left for another patch.  Since this will only be used with
-O and is currently limited, this seems reasonable to me.  But I would
like to know if others disagree.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Wed Feb 27 20:20:23 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Wed, 27 Feb 2008 19:20:23 -0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1204140023.63.0.393808520076.issue2193@psf.upfronthosting.co.za>


Jerry Seutter added the comment:

Heh, I think I should not have gotten involved in this bug. :)  I have a
few comments:

In response to 2.: David M. Kristol in that article is referring to the
original Netscape cookie implementation which is somewhat different from
what is set out in the RFC's.   Now I understand where the difference is.

In response to 6: Yes, I was referring to the NAME part of NAME=VALUE...


So it looks to me like the Python code implements the specification as
set out in the RFC.  I agree with you that there are multiple
implementations (Java and Perl) in wide use that allow behavior not set
out in the RFC.  The question is, do we want to stick the bahavior in
the RFC, or accomodate existing implementations?  My opinion:  I agree
with you.

Can some Python regulars comment on Python's policy in situations like this?

I can throw together a patch if this change would likely be accepted.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
__________________________________

From report at bugs.python.org  Wed Feb 27 20:22:08 2008
From: report at bugs.python.org (Jerry Seutter)
Date: Wed, 27 Feb 2008 19:22:08 -0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1204140128.11.0.426030150338.issue2193@psf.upfronthosting.co.za>


Changes by Jerry Seutter:


----------
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
__________________________________

From report at bugs.python.org  Wed Feb 27 20:52:39 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 27 Feb 2008 19:52:39 -0000
Subject: [issue2157] sqlite numeric type conversion problems
In-Reply-To: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>
Message-ID: <1204141959.9.0.775497415754.issue2157@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

The same question came up in the external pysqlite project once. My
answer is the same here: this won't be fixed because of backwards
compatibility reasons. The current behaviour is well documented.

I acknowledge that it would be nice to be able to use declaratos like
number(x,y) used with other databases and reuse them with SQLite and
pysqlite. But we can't implement your feature request with 100 %
backwards compatibility.

----------
assignee:  -> ghaering
keywords: +patch
nosy: +ghaering
resolution:  -> wont fix
status: open -> closed
type:  -> feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2157>
__________________________________

From report at bugs.python.org  Wed Feb 27 21:03:43 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 27 Feb 2008 20:03:43 -0000
Subject: [issue1546263] Segfaults with concurrent sqlite db access and schema
	change
Message-ID: <1204142623.69.0.00345336261119.issue1546263@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

See http://initd.org/tracker/pysqlite/ticket/170 and
http://initd.org/tracker/pysqlite/changeset/301

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1546263>
_____________________________________

From report at bugs.python.org  Wed Feb 27 21:05:20 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 27 Feb 2008 20:05:20 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1204142720.9.0.364098019033.issue2127@psf.upfronthosting.co.za>


Changes by Gerhard H?ring:


----------
nosy: +ghaering

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Wed Feb 27 21:10:03 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 27 Feb 2008 20:10:03 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1204143003.38.0.71155768752.issue2127@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

I'll assign this one to me. The "sqlite3" module cannot be just
"refreshed" with the externally maintained pysqlite, I'll have to do
merging anyway. Don't worry here ;-)

----------
assignee:  -> ghaering
keywords: +easy
priority:  -> low
severity: normal -> minor
type:  -> feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Wed Feb 27 21:12:01 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 27 Feb 2008 20:12:01 -0000
Subject: [issue2152] make sqlite.Row hashable correctly
In-Reply-To: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za>
Message-ID: <1204143121.55.0.909296408485.issue2152@psf.upfronthosting.co.za>


Changes by Gerhard H?ring:


----------
assignee:  -> ghaering
nosy: +ghaering
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2152>
__________________________________

From report at bugs.python.org  Wed Feb 27 21:45:00 2008
From: report at bugs.python.org (wrobell)
Date: Wed, 27 Feb 2008 20:45:00 -0000
Subject: [issue2157] sqlite numeric type conversion problems
In-Reply-To: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>
Message-ID: <1204145100.61.0.828420921933.issue2157@psf.upfronthosting.co.za>


wrobell added the comment:

fair enough, but...

1. i really do not see that behaviour documented, i.e.

       http://docs.python.org/lib/node347.html

   says nothing about types being broken on space character.

2. i am bit missing the point about backward compability.
   when looking on internet for a reason why types like
   "numeric(10, 2)" are not being converted (please note
   that "numeric (10, 2)" works, the difference is just one
   space), then i found no explanation of such behaviour,
   no single line of code trying to register conversion
   of "numeric(10,)" or similar.

   even more. if somebody has declaration like

      register_converter("numeric(10,", Decimal)

   then i can bet that he has also

      register_converter("numeric", Decimal)

   i doubt that my patch is breaking anybody's code, as no one
   is going to register "numeric(10," without registering "numeric".

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2157>
__________________________________

From report at bugs.python.org  Wed Feb 27 21:47:47 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 27 Feb 2008 20:47:47 -0000
Subject: [issue2157] sqlite numeric type conversion problems
In-Reply-To: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>
Message-ID: <1204145267.38.0.837384282468.issue2157@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

It's mentioned here: http://docs.python.org/lib/sqlite3-Module-Contents.html

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2157>
__________________________________

From report at bugs.python.org  Wed Feb 27 21:53:22 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Wed, 27 Feb 2008 20:53:22 -0000
Subject: [issue2157] sqlite numeric type conversion problems
In-Reply-To: <1203620223.11.0.994407753132.issue2157@psf.upfronthosting.co.za>
Message-ID: <1204145602.34.0.381928492212.issue2157@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

Yes, I acknowledge the backwards incompatibility is rather a one in a
billion case than a one in a million case.

I'll reopen this one and integrate your patch or something similar for
Python 2.6 and 3.0.

----------
resolution: wont fix -> 
status: closed -> open

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2157>
__________________________________

From report at bugs.python.org  Wed Feb 27 22:31:42 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Feb 2008 21:31:42 -0000
Subject: [issue2183] optimize list comprehensions
In-Reply-To: <1203906152.35.0.945763555719.issue2183@psf.upfronthosting.co.za>
Message-ID: <1204147902.33.0.432303971694.issue2183@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

The patch looks reasonable to me. Bytecode docs need to be changed.  At 
minimum like this:
===================================================================
--- Doc/library/dis.rst (revision 61097)
+++ Doc/library/dis.rst (working copy)
@@ -463,9 +463,9 @@
    address to jump to (which should be a ``FOR_ITER`` instruction).
 
 
-.. opcode:: LIST_APPEND ()
+.. opcode:: LIST_APPEND (i)
 
-   Calls ``list.append(TOS1, TOS)``.  Used to implement list 
comprehensions.
+   Calls ``list.append(TOS[-i], TOS)``.  Used to implement list 
comprehensions.
 
 
 .. opcode:: LOAD_LOCALS ()
========

More explanation on TOS being removed while TOS[-i] (obviously) not may 
be in order.

For py3k similar optimization should be available for dict and set 
comprehensions.

More unit tests will be helpful, particularly for nested iterations such 
as [(x,y,z) for x in s for y in s for z in s].

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2183>
__________________________________

From report at bugs.python.org  Wed Feb 27 22:47:40 2008
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Wed, 27 Feb 2008 21:47:40 -0000
Subject: [issue2198] code_hash() can be the same for different code objects
In-Reply-To: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za>
Message-ID: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za>


New submission from Stephan R.A. Deibel:

The algorithm in code_hash() in codeobject.c can return the same hash
value for different code objects.  

Presumably distinct code objects should be very unlikely to have the
same hash value.  This bug affected our debugger before we worked around
it, and it could affect other things like profilers.

Adding the co_filename to the hash would be one way to fix this but I'm
not sure if that was purposely avoided in this code?

----------
components: Interpreter Core
files: code_hash_bug.tgz
messages: 63083
nosy: sdeibel
severity: normal
status: open
title: code_hash() can be the same for different code objects
type: behavior
versions: Python 2.1.1, Python 2.1.2, Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9565/code_hash_bug.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2198>
__________________________________

From report at bugs.python.org  Wed Feb 27 22:51:28 2008
From: report at bugs.python.org (Stephan R.A. Deibel)
Date: Wed, 27 Feb 2008 21:51:28 -0000
Subject: [issue2198] code_hash() can be the same for different code objects
In-Reply-To: <1204148860.69.0.229152092841.issue2198@psf.upfronthosting.co.za>
Message-ID: <1204149088.3.0.103446163849.issue2198@psf.upfronthosting.co.za>


Stephan R.A. Deibel added the comment:

I should have noted that adding co_firstlineno as well to the hash would
be necessary to distinguish like code objects within the same file.  The
example has them on the same lines in different files but changing the
first line of the defs doesn't matter.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2198>
__________________________________

From report at bugs.python.org  Wed Feb 27 23:08:09 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 27 Feb 2008 22:08:09 -0000
Subject: [issue2185] code objects should conserve memory
In-Reply-To: <1203907300.87.0.511382024936.issue2185@psf.upfronthosting.co.za>
Message-ID: <1204150089.73.0.661085714061.issue2185@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Since names and varnames are known to be tuples of interned strings, 
they can be compared without calling abstract API. Just compare sizes 
and then compare item pointers in a loop.

What are the cases when co_names == co_varnames?  How often is this the 
case in the wild?

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2185>
__________________________________

From report at bugs.python.org  Thu Feb 28 03:10:29 2008
From: report at bugs.python.org (BM)
Date: Thu, 28 Feb 2008 02:10:29 -0000
Subject: [issue2193] Cookie Colon Name Bug
In-Reply-To: <1203992843.27.0.867127322082.issue2193@psf.upfronthosting.co.za>
Message-ID: <1204164629.78.0.954623049549.issue2193@psf.upfronthosting.co.za>


BM added the comment:

Well, as D.M.Kristol says: there are no any standard for this particular 
topic. And RFC is not any standard but a request for comments...

Personally I've been added a colon in Cookie.py for let Trac and other 
Python-based software stop crashing, because such sort of cookies are quite 
often appears. For some reason people treat a colon as a namespace separator, 
like in XML. Thus there are plenty of cookies like "section:key=value" you 
can meet quite often. But this is not a fix, but just quick local fix.

You also can find a lots of cookies that consists "[" and "]", slash, 
even a space that has been quoted as "%20", which means a "%" inside the
token -- just look what godaddy.com gives to you. :-)

So I see another problem here: there is not just a colon thing, but
implementation should be slightly different. Currently Python code
lists allowed chars. I am not sure it is correct way to implement.
Rather I would list disallowed chars (see example in Java).

Here is also an example how Ruby does the thing 
(see lib/webrick/cookie.rb):
------------------------------------------
def self.parse(str)
      if str
        ret = []
        cookie = nil
        ver = 0
        str.split(/[;,]\s+/).each{|x|  # <--- Here you go.
          key, val = x.split(/=/,2)
          val = val ? HTTPUtils::dequote(val) : ""
          case key
          when "$Version"; ver = val.to_i
          when "$Path";    cookie.path = val
          when "$Domain";  cookie.domain = val
          when "$Port";    cookie.port = val
          else
            ret << cookie if cookie
            cookie = self.new(key, val)
            cookie.version = ver
          end
        }
        ret << cookie if cookie
        ret
      end
    end
------------------------------------------

I still have doubts that Cookie NAME is the same token, because
specs still disallows only comma, semi-colon and a space. Well, 
I don't know, but we can either stick to Request For Comments or 
we can behave as the rest of the world, avoiding future interference.

Would be nice to hear some comments on policies... Tim?

----------
nosy: +tim_one

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2193>
__________________________________

From report at bugs.python.org  Thu Feb 28 03:16:22 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 28 Feb 2008 02:16:22 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1204164982.52.0.54443543404.issue1682@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I'm wondering what there is left to do here.  Are we close to being able 
to close this issue?  Some thoughts:

(1) I think the docs could use a little work (just expanding, and giving 
a few examples).  But it doesn't seem urgent that this gets done before 
the next round of alphas.

(2) Looking at it, I'm really not sure that implementing 
Rational.__format__ is worthwhile;  it's not obvious that we need a way
to format a Rational as a float.  So I'm -0 on this.  If others think 
Rational should have a __format__ method I'm still happy to implement 
it.

Is there much else that needs to be done here?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Thu Feb 28 05:47:41 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 28 Feb 2008 04:47:41 -0000
Subject: [issue1762] Inheriting from ABCs makes classes slower.
In-Reply-To: <1199810349.91.0.976772037257.issue1762@psf.upfronthosting.co.za>
Message-ID: <1204174061.27.0.0401473254883.issue1762@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Since there were no comments, I submitted the patch as r61098. I think
we're done here. :)

----------
resolution:  -> fixed
status: open -> closed
type:  -> behavior
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1762>
__________________________________

From report at bugs.python.org  Thu Feb 28 07:10:16 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 28 Feb 2008 06:10:16 -0000
Subject: [issue2184] Speed up Thread.start()
In-Reply-To: <1203906623.93.0.917189380676.issue2184@psf.upfronthosting.co.za>
Message-ID: <1204179016.75.0.495850934676.issue2184@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Submitted as r61100.

----------
assignee:  -> jyasskin
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2184>
__________________________________

From report at bugs.python.org  Thu Feb 28 14:45:51 2008
From: report at bugs.python.org (Armin Rigo)
Date: Thu, 28 Feb 2008 13:45:51 -0000
Subject: [issue2181] optimize out local variables at end of function
In-Reply-To: <1203904814.51.0.0269762586023.issue2181@psf.upfronthosting.co.za>
Message-ID: <1204206351.52.0.885541639854.issue2181@psf.upfronthosting.co.za>


Armin Rigo added the comment:

I view this as a problem with Psyco, not with the user code.
An even deeper reason for which the general optimization would break
code is because it changes the lifetime of objects.  For example, Psyco
contains specific, user-requested support to make sure the following
kind of code works:

def myfunc():
    f = open('somewhere', 'r')
    fd = f.fileno()
    return os.fstat(fd)

At the moment Python guarantees that the file object is not closed
before the function exits.  The above code cannot be rewritten like this:

def bogus():
    fd = open('somewhere', 'r').fileno()
    # the file is auto-closed here and fd becomes invalid
    return os.fstat(fd)

I know it's bad style to write code relying on this property, but still
I want to make sure you are aware that it *will* introduce obscure
breakage in existing code.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2181>
__________________________________

From report at bugs.python.org  Thu Feb 28 14:46:24 2008
From: report at bugs.python.org (PyScripter)
Date: Thu, 28 Feb 2008 13:46:24 -0000
Subject: [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>


New submission from PyScripter:

cPickle has problems loading instances of gtk gobject.GEnum classes. 
gobject.GEnum is a subclass of int.  On the other hand pickle handles
those classes correctly.  Since cPickle is meant to be a faster version
of pickle this needs to be consider a bug.  

To test run the following script:

import gtk
##import pickle
import cPickle as pickle

simple_types = (
    bool,
    int,
    long,
    float,
    complex,
    basestring,
    type(None),
)


d = vars(gtk)
for (i,j) in d.iteritems():
    if isinstance(j, simple_types):
        try:
            s = pickle.dumps(j, pickle.HIGHEST_PROTOCOL)
            obj = pickle.loads(s)
        except (ValueError, TypeError):
            print j, type(j)

If you replace cPickle with pickle then the script runs fine.

----------
components: Library (Lib)
messages: 63091
nosy: pyscripter
severity: normal
status: open
title: cPickle error with gtk GEnum classes
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________

From report at bugs.python.org  Thu Feb 28 14:52:13 2008
From: report at bugs.python.org (Lev Shamardin)
Date: Thu, 28 Feb 2008 13:52:13 -0000
Subject: [issue2200] find_executable fails to find .bat files on win32
In-Reply-To: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>
Message-ID: <1204206733.81.0.37749013909.issue2200@psf.upfronthosting.co.za>


New submission from Lev Shamardin:

distutils.spawn.find_executable appends '.exe' suffix on win32 and os2
platforms. This is incorrect behavior, since it prevents finding .bat,
.cmd and other similar files. Ether all extensions from the %PATHEXT%
must be checked or filenames both with appended suffix and without
appending suffix must be checked.

----------
components: Distutils
messages: 63092
nosy: abbot
severity: major
status: open
title: find_executable fails to find .bat files on win32
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2200>
__________________________________

From report at bugs.python.org  Thu Feb 28 15:03:34 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 28 Feb 2008 14:03:34 -0000
Subject: [issue2169] Adding DOCTYPE and "html", "body" tags to SimpleHTTPServer
In-Reply-To: <1203787685.42.0.819164609071.issue2169@psf.upfronthosting.co.za>
Message-ID: <1204207414.64.0.670735374641.issue2169@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Applied to 2.6 in rev. 61105; it will be merged up to 3.0 at some point.
Thanks for the patch!

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2169>
__________________________________

From report at bugs.python.org  Thu Feb 28 15:36:18 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Thu, 28 Feb 2008 14:36:18 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1197051927.23.0.805200385049.issue1569@psf.upfronthosting.co.za>
Message-ID: <1204209378.18.0.138498668994.issue1569@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven added the comment:

OK, I played around a bit and created a setup project (.vdproj file).

The relevant part for the merge modules is:

        "MergeModule"
        {
            "{CEE29DC0-9FBA-4B99-8D47-5BC643D9B626}:_8968169979C7478FA06F2A63790836FB"
            {
            "UseDynamicProperties" = "11:TRUE"
            "IsDependency" = "11:TRUE"
            "SourcePath" = "8:microsoft_vc90_crt_x86.msm"
                "Properties"
                {
                }
            "LanguageId" = "3:0"
            "Exclude" = "11:FALSE"
            "Folder" = "8:"
            "Feature" = "8:"
            "IsolateTo" = "8:"
            }
            "{CEE29DC0-9FBA-4B99-8D47-5BC643D9B626}:_B6A9939311C545EBB80282DDFF193627"
            {
            "UseDynamicProperties" = "11:TRUE"
            "IsDependency" = "11:TRUE"
            "SourcePath" = "8:policy_9_0_Microsoft_VC90_CRT_x86.msm"
                "Properties"
                {
                }
            "LanguageId" = "3:0"
            "Exclude" = "11:FALSE"
            "Folder" = "8:"
            "Feature" = "8:"
            "IsolateTo" = "8:"
            }
        }

One thing I read is that these setup projects (and perhaps the merge 
modules) are not supported on the express editions and needs to do the 
xcopy routine.

Let me know if I should attach my .vdproj, right now it is hardcoded in 
some places, but it creates a .MSI with the following:

catalog.21023.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
nosxs_msvcm90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
nosxs_msvcp90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
nosxs_msvcr90.dll.0138F525_6C8A_333F_A105_14AE030B9A54
policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
ul_catalog.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_catalog.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
ul_manifest.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_msvcm90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_msvcp90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_msvcr90.dll.21022.08.Microsoft_VC90_CRT_x86.RTM.0138F525_6C8A_333F_A105_14AE030B9A54
ul_policy.21022.08.policy_9_0_Microsoft_VC90_CRT_x86.RTM.52105B6B_A3EF_3A90_882A_947B287C203A
_15FEE25FEEA5B2FA5906FBB18964EA25
_39CC7CD67C9CC4024DB4457CAD1D8F4B
_64A91316C96BFF833C45602D2342A095
_F11BA2FBEC12D0CBA986C9D17E9781C0

So on that front I think it is a mission accomplished, now to tweak and 
tune.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Thu Feb 28 16:57:01 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Thu, 28 Feb 2008 15:57:01 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1204214221.48.0.106206801486.issue2127@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

Ok then, we need a test for this. Patch attached.

However, I don't know if I applied Amaury's patch wrong or if I miss a 
./configure option or something, but even with the patch, the test fails.

Another thing: Why isn't the sqlite3 test suite a part of python's 
regression test suite? Or is it and I didn't notice?

----------
keywords: +patch
Added file: http://bugs.python.org/file9566/sqlite_connect_test.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Thu Feb 28 17:42:54 2008
From: report at bugs.python.org (Jarod)
Date: Thu, 28 Feb 2008 16:42:54 -0000
Subject: [issue2201] Documentation Section 4.4
In-Reply-To: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>
Message-ID: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>


New submission from Jarod:

Section 4.4 of the tutorial gives example code: 

>>> for n in range(2, 10):
...     for x in range(2, n):
...         if n % x == 0:
...             print n, 'equals', x, '*', n/x
...             break
...     else:
...         # loop fell through without finding a factor
...         print n, 'is a prime number'
... 
2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

When one is to enter the code (print n, 'equals' x, '*' n/x) you are
given syntax error:   File "<stdin>", line 4
    print n, 'equals' x, '*' n/x
                      ^
SyntaxError: invalid syntax

----------
components: Documentation
messages: 63096
nosy: str8lazy
severity: normal
status: open
title: Documentation Section 4.4
type: compile error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2201>
__________________________________

From report at bugs.python.org  Thu Feb 28 18:01:45 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Thu, 28 Feb 2008 17:01:45 -0000
Subject: [issue2201] Documentation Section 4.4
In-Reply-To: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>
Message-ID: <1204218105.6.0.585541258081.issue2201@psf.upfronthosting.co.za>


Robert Lehmann added the comment:

In the example code from the tutorial you gave, there was still a comma
separator between the string 'equals' and the reference `x`. This is
missing when you entered the code, that's why Python is throwing an
exception there.

----------
nosy: +lehmannro

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2201>
__________________________________

From report at bugs.python.org  Thu Feb 28 18:47:26 2008
From: report at bugs.python.org (Jarod)
Date: Thu, 28 Feb 2008 17:47:26 -0000
Subject: [issue2201] Documentation Section 4.4
In-Reply-To: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>
Message-ID: <1204220845.96.0.377801257065.issue2201@psf.upfronthosting.co.za>


Jarod added the comment:

I made a type in that line, but when the typo isn't there I get the same
thing. It turns out that it was an error from running a slightly older
version of the dev kit. Now that I have updated the dev kit it runs, but
I end up with the following as an output:

3 is a prime number
4 equals 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 equals 2 * 3
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
7 is a prime number
8 equals 2 * 4
9 is a prime number
9 equals 3 * 3

as opposed to the desired

2 is a prime number
3 is a prime number
4 equals 2 * 2
5 is a prime number
6 equals 2 * 3
7 is a prime number
8 equals 2 * 4
9 equals 3 * 3

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2201>
__________________________________

From report at bugs.python.org  Thu Feb 28 19:05:03 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 28 Feb 2008 18:05:03 -0000
Subject: [issue1540386] SocketServer.ForkingMixIn.collect_children() waits on
	pid 0
Message-ID: <1204221903.3.0.452346250071.issue1540386@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Mostly fixed in r61106. This should make the buildbots happy, but there
is still a corner case in which we waitpid(0) and could confuse other
libraries.

----------
nosy: +jyasskin
type:  -> behavior
versions: +Python 2.6

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1540386>
_____________________________________

From report at bugs.python.org  Thu Feb 28 19:23:09 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Thu, 28 Feb 2008 18:23:09 -0000
Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children
In-Reply-To: <1190316942.33.0.242562253308.issue1183@psf.upfronthosting.co.za>
Message-ID: <1204222989.43.0.686965182683.issue1183@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

Hmm. I think the race can only happen if you call collect_children()
concurrently from multiple threads or from a signal handler. The
waidpid(0) bug (which affected anyone who spawned subprocesses from
anything other than ForkingMixIn) is partly fixed by r61106, but I don't
intend to make ForkingMixIn thread- or signal-safe. Let me know if this
is enough for you. :)

----------
nosy: +jyasskin
resolution:  -> fixed
status: open -> pending
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1183>
__________________________________

From report at bugs.python.org  Thu Feb 28 19:26:34 2008
From: report at bugs.python.org (Brendan W. McAdams)
Date: Thu, 28 Feb 2008 18:26:34 -0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
	auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>


New submission from Brendan W. McAdams:

URLLIB2 seems to have issues attempting to digest authenticate against a
Windows-based IIS 6.x server.  The IIS server requests MD5-sess support,
and URLLIB2 throws an exception that ... far from explains this:

Traceback (most recent call last):
  File "/usr/lib64/python2.5/runpy.py", line 95, in run_module
    filename, loader, alter_sys)
  File "/usr/lib64/python2.5/runpy.py", line 52, in _run_module_code
    mod_name, mod_fname, mod_loader)
  File "/usr/lib64/python2.5/runpy.py", line 32, in _run_code
    exec code in run_globals
  File "/srv/pubPal/test/test_auth.py", line 16, in <module>
    print opener.open(uri)
  File "/usr/lib64/python2.5/urllib2.py", line 380, in open
    response = meth(req, response)
  File "/usr/lib64/python2.5/urllib2.py", line 491, in http_response
    'http', request, response, code, msg, hdrs)
  File "/usr/lib64/python2.5/urllib2.py", line 412, in error
    result = self._call_chain(*args)
  File "/usr/lib64/python2.5/urllib2.py", line 353, in _call_chain
    result = func(*args)
  File "/usr/lib64/python2.5/urllib2.py", line 992, in http_error_401
    host, req, headers)
  File "/usr/lib64/python2.5/urllib2.py", line 884, in http_error_auth_reqed
    return self.retry_http_digest_auth(req, authreq)
  File "/usr/lib64/python2.5/urllib2.py", line 889, in
retry_http_digest_auth
    auth = self.get_authorization(req, chal)
  File "/usr/lib64/python2.5/urllib2.py", line 920, in get_authorization
    H, KD = self.get_algorithm_impls(algorithm)
  File "/usr/lib64/python2.5/urllib2.py", line 972, in get_algorithm_impls
    return H, KD
UnboundLocalError: local variable 'H' referenced before assignment


The offending code is urllib2.py line 972:

    def get_algorithm_impls(self, algorithm):
        # lambdas assume digest modules are imported at the top level
        if algorithm == 'MD5':
            H = lambda x: hashlib.md5(x).hexdigest()
        elif algorithm == 'SHA':
            H = lambda x: hashlib.sha1(x).hexdigest()
        # XXX MD5-sess
        KD = lambda s, d: H("%s:%s" % (s, d))
        return H, KD

I'm not sure what's meant by the # XXX MD5-sess comment there... But
what ends up happening is that MD5-sess matches neither the if or the
elif, and when return attempts to return, H is undefined.

This could be easily patched, but support for MD5-sess would be great as
well.  

In my estimation, at the least, urllib2 shouldn't crap out in such an
obscure way when encountering an unsupported algorithm.

I'd suggest changing line 970 (The # XXX MD5-sess line) to:

 raise Exception, "Unsupported Digest Authentication Algorithm '%s'" %
(algorithm)

----------
components: Library (Lib)
messages: 63101
nosy: bwmcadams
severity: normal
status: open
title: urllib2 fails against IIS 6.0 (No support for MD5-sess auth)
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
__________________________________

From report at bugs.python.org  Thu Feb 28 19:27:49 2008
From: report at bugs.python.org (Brendan W. McAdams)
Date: Thu, 28 Feb 2008 18:27:49 -0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
	auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1204223269.34.0.307537721388.issue2202@psf.upfronthosting.co.za>


Brendan W. McAdams added the comment:

Sorry, this isn't a crash.  It doesn't crash the interpreter.  I'll
assume "behavior' is the correct categorization.

----------
type: crash -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
__________________________________

From report at bugs.python.org  Thu Feb 28 19:39:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Thu, 28 Feb 2008 18:39:45 -0000
Subject: [issue2201] Documentation Section 4.4
In-Reply-To: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>
Message-ID: <1204223985.94.0.0471193416618.issue2201@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Sorry, but there must be another typo in your code.
I guess the else clause isn't correctly indented -- it belongs to the
"for" statement, not the "if" statement.

----------
nosy: +georg.brandl
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2201>
__________________________________

From report at bugs.python.org  Thu Feb 28 21:00:37 2008
From: report at bugs.python.org (Mathew Ryden)
Date: Thu, 28 Feb 2008 20:00:37 -0000
Subject: [issue2203] ssl module getpeercert returns empty dict when
	cert_reqs=ssl.CERT_NONE
Message-ID: <1204228837.87.0.412368387154.issue2203@psf.upfronthosting.co.za>


Changes by Mathew Ryden:


----------
components: Library (Lib)
nosy: mryden
severity: normal
status: open
title: ssl module getpeercert returns empty dict when cert_reqs=ssl.CERT_NONE
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2203>
__________________________________

From report at bugs.python.org  Thu Feb 28 21:11:40 2008
From: report at bugs.python.org (Jarod)
Date: Thu, 28 Feb 2008 20:11:40 -0000
Subject: [issue2201] Documentation Section 4.4
In-Reply-To: <1204216974.8.0.2644106888.issue2201@psf.upfronthosting.co.za>
Message-ID: <1204229500.63.0.937818279917.issue2201@psf.upfronthosting.co.za>


Jarod added the comment:

@Georg: you were correct, the indentation was incorrect, I suggest that
there be some additional notation be added to code examples in the
documentation showing how many tabs there are, to make for an easier
read and minimize on errors.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2201>
__________________________________

From report at bugs.python.org  Thu Feb 28 22:29:57 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 28 Feb 2008 21:29:57 -0000
Subject: [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204234197.35.0.691512039387.issue2199@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Can you please investigate the details and report the cause of the problem?

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________

From report at bugs.python.org  Thu Feb 28 22:35:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 28 Feb 2008 21:35:28 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1204209378.18.0.138498668994.issue1569@psf.upfronthosting.co.za>
Message-ID: <47C7291D.2030107@v.loewis.de>


Martin v. L?wis added the comment:

> So on that front I think it is a mission accomplished, now to tweak and 
> tune.

Please do attach the project. I can't quite understand what it is that
you have achieved. Is that a project file that can create a full Python
installer?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Thu Feb 28 22:59:34 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 28 Feb 2008 21:59:34 -0000
Subject: [issue2202] urllib2 fails against IIS 6.0 (No support for MD5-sess
	auth)
In-Reply-To: <1204223194.19.0.670418970441.issue2202@psf.upfronthosting.co.za>
Message-ID: <1204235974.57.0.677176480593.issue2202@psf.upfronthosting.co.za>


A.M. Kuchling added the comment:

Marking as easy, assuming you add the exception; implementing MD5-sess
is probably not easy.

----------
keywords: +easy
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2202>
__________________________________

From report at bugs.python.org  Thu Feb 28 23:12:00 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Thu, 28 Feb 2008 22:12:00 -0000
Subject: [issue2204] document ConfigParser behaviour when a file has same
	section multiple times
In-Reply-To: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>
Message-ID: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>


New submission from Raghuram Devarakonda:

ConfigParser.add_section() raises DuplicateSectionError if add_section()
is called with the name of a section that is already present. How ever,
if a section is present multiple times in a file, readfp() does not
raise any exception. Instead, the sections are "combined" with values in
latter sections overwriting previous values (if any). This should be
documented in readfp(). I tried few alternatives but the sentences don't
look right. I am creating the issue in the hope that some one else may
give it a try while I continue to come up with a doc patch.

----------
assignee: georg.brandl
components: Documentation
messages: 63109
nosy: draghuram, georg.brandl
severity: normal
status: open
title: document ConfigParser behaviour when a file has same section multiple times
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2204>
__________________________________

From report at bugs.python.org  Thu Feb 28 23:31:37 2008
From: report at bugs.python.org (Senthil)
Date: Thu, 28 Feb 2008 22:31:37 -0000
Subject: [issue2204] document ConfigParser behaviour when a file has same
	section multiple times
In-Reply-To: <1204236720.35.0.634026900248.issue2204@psf.upfronthosting.co.za>
Message-ID: <1204237897.16.0.790034962439.issue2204@psf.upfronthosting.co.za>


Senthil added the comment:

Should this 'undesirable' behavior be documented? My thoughts are
a) All the key,value pairs in the named section be retrived from entire
file. Just appending the dict.
Otherwise, 
b) An Exception can be thrown if it encounters an invalid Configfile
having multiple same sections which can cause problem, but I cannot
readily think of one such case.

What do others think?

Thanks,
Senthil

----------
nosy: +orsenthil

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2204>
__________________________________

From report at bugs.python.org  Thu Feb 28 23:55:29 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 28 Feb 2008 22:55:29 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1204239329.95.0.669720179964.issue2127@psf.upfronthosting.co.za>


Gerhard H?ring added the comment:

I didn't try the patch out, yet. But I'd instead try to just open
u":memory" instead.

Also, in Lib/test/test_sqlite.py the sqlite tests are started. They are
of course run as part of the Python test suite.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Fri Feb 29 00:18:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 28 Feb 2008 23:18:22 -0000
Subject: [issue2196] Fix hasattr's exception problems
In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za>
Message-ID: <1204240702.73.0.567067756152.issue2196@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

Here's a documentation change that explains hasattr's exception issues
top accompany my patch.

----------
components: +Documentation
Added file: http://bugs.python.org/file9567/hasattr_docs.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2196>
__________________________________

From report at bugs.python.org  Fri Feb 29 00:19:50 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Thu, 28 Feb 2008 23:19:50 -0000
Subject: [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204240789.99.0.855338249333.issue2199@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

Using slightly modified PyGObject (so that it gives more useful error
message in pyg_enum_new) and adding 'raise' in the end of attached
example, I got this:

<enum GTK_RC_TOKEN_LOWEST of type GtkRcTokenType> <class
'gtk._gtk.RcTokenType'>
Traceback (most recent call last):
  File "<stdin>", line 5, in <module>
ValueError: value out of range (294 not in 0..40)

Not sure what it means yet...

----------
nosy: +_doublep

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________

From report at bugs.python.org  Fri Feb 29 00:27:09 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Thu, 28 Feb 2008 23:27:09 -0000
Subject: [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204241229.13.0.568963941475.issue2199@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

It doesn't seem 'pickle' itself works:

>>> import pickle
>>> import gtk
>>> s = pickle.dumps (gtk.RC_TOKEN_LOWEST, pickle.HIGHEST_PROTOCOL)
>>> pickle.loads (s)
__main__:1: Warning: cannot retrieve class for invalid (unclassed) type
`<invalid>'

** ERROR **: file pygenum.c: line 55 (pyg_enum_repr): assertion failed:
(G_IS_ENUM_CLASS(enum_class))
aborting...
Aborted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________

From report at bugs.python.org  Fri Feb 29 02:24:21 2008
From: report at bugs.python.org (Noriyuki Hosaka)
Date: Fri, 29 Feb 2008 01:24:21 -0000
Subject: [issue1175933] threading.Condition.wait() return value indicates
	timeout
Message-ID: <1204248261.19.0.890282023572.issue1175933@psf.upfronthosting.co.za>


Noriyuki Hosaka added the comment:

I have a question:
 Why not to raise an exception?

Timeout means "something has messed up, can not continue."
We are not doing task scheduling, aren't we?

----------
nosy: +bgnori

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175933>
_____________________________________

From report at bugs.python.org  Fri Feb 29 02:59:20 2008
From: report at bugs.python.org (makoto kuwata)
Date: Fri, 29 Feb 2008 01:59:20 -0000
Subject: [issue2205] os.times() returns uncorrect value
Message-ID: <1204250360.44.0.399055363738.issue2205@psf.upfronthosting.co.za>


Changes by makoto kuwata:


----------
components: Library (Lib)
nosy: kwatch
severity: normal
status: open
title: os.times() returns uncorrect value
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2205>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:03:05 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 29 Feb 2008 02:03:05 -0000
Subject: [issue2205] os.times() returns uncorrect value
In-Reply-To: <1204250585.31.0.481780521952.issue2205@psf.upfronthosting.co.za>
Message-ID: <1204250585.31.0.481780521952.issue2205@psf.upfronthosting.co.za>


New submission from Facundo Batista:

What?

Why you say that? What are you doing? What do you get? What do you
expect? In which version of Python and in which Platform are you working?

----------
nosy: +facundobatista
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2205>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:08:39 2008
From: report at bugs.python.org (makoto kuwata)
Date: Fri, 29 Feb 2008 02:08:39 -0000
Subject: [issue2205] os.times() returns incorrect value
In-Reply-To: <1204250585.31.0.481780521952.issue2205@psf.upfronthosting.co.za>
Message-ID: <1204250919.73.0.504253195604.issue2205@psf.upfronthosting.co.za>


makoto kuwata added the comment:

I'm sorry to put empty submit.

os.time() returns incorrect value.

test.py:

    def f(n):
      if n <= 0:
          return 1
      else:
          return f(n-1) + f(n-2)
    
    import os
    t1 = os.times()
    f(34)
    t2 = os.times()
    
    utime = t2[0] - t1[0]
    stime = t2[1] - t1[1]
    total = utime + stime
    
    print "utime %.4f, stime %.4f, total %.4f" % (utime, stime, total)

result:

    $ time python bench.py
    utime 38.6333, stime 0.1000, total 38.7333
    
    real    0m23.787s
    user    0m23.211s
    sys     0m0.138s

This shows that real time is only 23.8 seconds, but os.times()
reports that user time is over 38 seconds.

This is due to bug of Modules/posixmodule.c.

Environment: python 2.5.2, MacOS X 10.4 Tiger, GCC 4.0

----------
keywords: +patch
title: os.times() returns uncorrect value -> os.times() returns incorrect value
Added file: http://bugs.python.org/file9568/posixmodule.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2205>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:16:10 2008
From: report at bugs.python.org (makoto kuwata)
Date: Fri, 29 Feb 2008 02:16:10 -0000
Subject: [issue2205] os.times() returns incorrect value
In-Reply-To: <1204250585.31.0.481780521952.issue2205@psf.upfronthosting.co.za>
Message-ID: <1204251370.22.0.41756799109.issue2205@psf.upfronthosting.co.za>


makoto kuwata added the comment:

See
http://groups.google.com/group/comp.lang.python/browse_thread/thread/8032897a30781df/c656a79d4c3268a6
for details about this bug.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2205>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:18:58 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 29 Feb 2008 02:18:58 -0000
Subject: [issue2110] Implement __format__ for Decimal
In-Reply-To: <1202994255.28.0.383332155678.issue2110@psf.upfronthosting.co.za>
Message-ID: <1204251538.79.0.74744360472.issue2110@psf.upfronthosting.co.za>


Mark Dickinson added the comment:

I've committed a reworked version of the patch in r61123.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2110>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:39:58 2008
From: report at bugs.python.org (Xie Bengui)
Date: Fri, 29 Feb 2008 02:39:58 -0000
Subject: [issue2206] critical memory leak in hashlib.md5
Message-ID: <1204252798.22.0.882467230291.issue2206@psf.upfronthosting.co.za>


Changes by Xie Bengui:


----------
files: md5.txt
nosy: agateriver
severity: normal
status: open
title: critical memory leak in hashlib.md5
type: resource usage
versions: Python 2.6
Added file: http://bugs.python.org/file9569/md5.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:42:30 2008
From: report at bugs.python.org (Xie Bengui)
Date: Fri, 29 Feb 2008 02:42:30 -0000
Subject: [issue2206] critical memory leak in hashlib.md5
In-Reply-To: <1204252950.83.0.917993482097.issue2206@psf.upfronthosting.co.za>
Message-ID: <1204252950.83.0.917993482097.issue2206@psf.upfronthosting.co.za>


New submission from Xie Bengui:

I write a pieces of code below to find my lost password:

import hashlib

for i in range(9999,99999999):
	m=hashlib.md5(str(i)).hexdigest()
	if m=="21e83200cfd4845fd5e07ee151d70caf":
		print "password is: ", i
		break


when I run it serval minutes, all memory use up.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:43:15 2008
From: report at bugs.python.org (Xie Bengui)
Date: Fri, 29 Feb 2008 02:43:15 -0000
Subject: [issue2206] critical memory leak in hashlib.md5
In-Reply-To: <1204252950.83.0.917993482097.issue2206@psf.upfronthosting.co.za>
Message-ID: <1204252995.26.0.742080911004.issue2206@psf.upfronthosting.co.za>


Changes by Xie Bengui:


----------
nosy:  -agateriver

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:54:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Feb 2008 02:54:36 -0000
Subject: [issue2206] critical memory leak in hashlib.md5
In-Reply-To: <1204252950.83.0.917993482097.issue2206@psf.upfronthosting.co.za>
Message-ID: <1204253676.48.0.561627185743.issue2206@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

This is not a hashlib problem (or a bug at all.) range returns an list
of 99990000 numbers. The allocation of this list is the part taking up
all the memory. Try replacing range with xrange.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 03:55:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Feb 2008 02:55:57 -0000
Subject: [issue2206] critical memory leak in hashlib.md5
In-Reply-To: <1204252950.83.0.917993482097.issue2206@psf.upfronthosting.co.za>
Message-ID: <1204253757.76.0.975535756191.issue2206@psf.upfronthosting.co.za>


Changes by Benjamin Peterson:


----------
severity: normal -> minor

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 04:01:13 2008
From: report at bugs.python.org (Xie Bengui)
Date: Fri, 29 Feb 2008 03:01:13 -0000
Subject: [issue2206] critical memory leak in hashlib.md5
In-Reply-To: <1204252950.83.0.917993482097.issue2206@psf.upfronthosting.co.za>
Message-ID: <1204254073.83.0.365277709008.issue2206@psf.upfronthosting.co.za>


Xie Bengui added the comment:

I am sorry for submitting this fake issue!

Thank Benjamin Peterson!

----------
nosy: +agateriver

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 04:13:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Feb 2008 03:13:08 -0000
Subject: [issue1175933] threading.Condition.wait() return value indicates
	timeout
Message-ID: <1204254788.23.0.413109089381.issue1175933@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

I don't think an exception is the proper thing to use here. Having the
wait timeout is not exceptional or unexpected.
> Timeout means "something has messed up, can not continue."
Not really. It means "we didn't want to wait this long to be notified."

----------
nosy: +benjamin.peterson

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1175933>
_____________________________________

From report at bugs.python.org  Fri Feb 29 04:24:29 2008
From: report at bugs.python.org (David Ripton)
Date: Fri, 29 Feb 2008 03:24:29 -0000
Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children
In-Reply-To: <1190316942.33.0.242562253308.issue1183@psf.upfronthosting.co.za>
Message-ID: <1204255469.4.0.33975219054.issue1183@psf.upfronthosting.co.za>


David Ripton added the comment:

The "if pid not in self.active_children: continue" check that was added
in r61106 appears to fix the bug, so I'm happy.  Thanks.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1183>
__________________________________

From report at bugs.python.org  Fri Feb 29 06:26:31 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 29 Feb 2008 05:26:31 -0000
Subject: [issue1183] race in SocketServer.ForkingMixIn.collect_children
In-Reply-To: <1190316942.33.0.242562253308.issue1183@psf.upfronthosting.co.za>
Message-ID: <1204262791.21.0.0419970722786.issue1183@psf.upfronthosting.co.za>


Changes by Jeffrey Yasskin:


----------
status: pending -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1183>
__________________________________

From report at bugs.python.org  Fri Feb 29 07:08:04 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 29 Feb 2008 06:08:04 -0000
Subject: [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204265284.46.0.223164086651.issue2199@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

This all look like a bug in pygtk to me, not like a bug in pickle/cPickle.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________

From report at bugs.python.org  Fri Feb 29 07:37:28 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Fri, 29 Feb 2008 06:37:28 -0000
Subject: [issue1682] Move Demo/classes/Rat.py to Lib/fractions.py and fix it
	up.
In-Reply-To: <1198258890.48.0.235588402123.issue1682@psf.upfronthosting.co.za>
Message-ID: <1204267048.51.0.451259755959.issue1682@psf.upfronthosting.co.za>


Jeffrey Yasskin added the comment:

I agree that we're basically done here. I'm back to -1 on inlining the
common case for arithmetic (attached here anyway). Simple cases are
already pretty fast, and bigger fractions are dominated by gcd time, not
function call overhead. Since duplicating the definitions of arithmetic
will make it harder to do tricky things that shrink the arguments to
gcd(), we shouldn't do it.

I was always +0 to __format__, so not doing it is fine with me.

Thanks for everyone's help!

----------
resolution:  -> fixed
status: open -> closed
Added file: http://bugs.python.org/file9570/fraction_inline_arith.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1682>
__________________________________

From report at bugs.python.org  Fri Feb 29 08:18:33 2008
From: report at bugs.python.org (Virgil Dupras)
Date: Fri, 29 Feb 2008 07:18:33 -0000
Subject: [issue2127] sqlite3 docs should mention utf8 requirement
In-Reply-To: <1203170928.18.0.391446477108.issue2127@psf.upfronthosting.co.za>
Message-ID: <1204269513.73.0.380134865334.issue2127@psf.upfronthosting.co.za>


Virgil Dupras added the comment:

u':memory:'? That already worked before the patch because the implicit 
encoding with 'ascii' does not bump into any non-ascii character. Nope, 
one has to call connect with a filename containing non-ascii characters.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2127>
__________________________________

From report at bugs.python.org  Fri Feb 29 09:45:12 2008
From: report at bugs.python.org (Thomas Herve)
Date: Fri, 29 Feb 2008 08:45:12 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1204274712.07.0.606103986622.issue1657@psf.upfronthosting.co.za>


Thomas Herve added the comment:

Is there a chance for this go in the first alpha? FWIW, I've tested it
with twisted kqueue and epoll reactors, and didn't get any problems.

There are still 2 typos in the patch: KQ_ADD is used 2 times in the docs
instead of KQ_EV_ADD. Everything else looks good to me.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Fri Feb 29 10:08:46 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 29 Feb 2008 09:08:46 -0000
Subject: [issue1657] [patch] epoll and kqueue wrappers for the select module
In-Reply-To: <1198057263.13.0.0951432296357.issue1657@psf.upfronthosting.co.za>
Message-ID: <1204276126.51.0.242282661573.issue1657@psf.upfronthosting.co.za>


Christian Heimes added the comment:

I love to get it into the next alpha but I don't have time to today. Can
you take it to the mailing list and ask somebody to review and submit
the patch?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1657>
__________________________________

From report at bugs.python.org  Fri Feb 29 11:47:43 2008
From: report at bugs.python.org (Tim Golden)
Date: Fri, 29 Feb 2008 10:47:43 -0000
Subject: [issue2207] Bug in Sphinx highlighting when pygments not available
In-Reply-To: <1204282063.81.0.343709498913.issue2207@psf.upfronthosting.co.za>
Message-ID: <1204282063.81.0.343709498913.issue2207@psf.upfronthosting.co.za>


New submission from Tim Golden:

When pygments is not available to the sphinx build environment, the
PygmentsBridge in the highlighting.py module raises an exception in the
unhighlighted function. This function attempts to use the .dest
attribute which isn't set in the __init__ if the pygments import has failed.

The attached patch moves the .dest setting up so it is always set
regardless of the presence of pygments. I don't know if it's a complete
solution, but the help, htmlhelp and web all build.

----------
components: Documentation tools (Sphinx)
files: sphinx-highlighting-r61125.patch
keywords: patch
messages: 63130
nosy: tim.golden
severity: normal
status: open
title: Bug in Sphinx highlighting when pygments not available
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9571/sphinx-highlighting-r61125.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2207>
__________________________________

From report at bugs.python.org  Fri Feb 29 12:00:41 2008
From: report at bugs.python.org (Tim Golden)
Date: Fri, 29 Feb 2008 11:00:41 -0000
Subject: [issue2208] Patch to doc/make.bat to allow non-standard HTML Help
	location
In-Reply-To: <1204282841.46.0.816451204729.issue2208@psf.upfronthosting.co.za>
Message-ID: <1204282841.46.0.816451204729.issue2208@psf.upfronthosting.co.za>


New submission from Tim Golden:

The doc/make.bat file for building the docs under Windows assumes the
standard location for the HTML Help Workshop. The attached patch looks
for  an env var called HTMLHELP and uses that if it's set, falling back
to the standard location.

----------
components: Documentation tools (Sphinx)
files: doc-make-r61125.patch
keywords: patch
messages: 63131
nosy: tim.golden
severity: normal
status: open
title: Patch to doc/make.bat to allow non-standard HTML Help location
versions: Python 2.6
Added file: http://bugs.python.org/file9572/doc-make-r61125.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2208>
__________________________________

From report at bugs.python.org  Fri Feb 29 12:14:46 2008
From: report at bugs.python.org (=?utf-8?q?J=C3=BCrgen_A._Erhard?=)
Date: Fri, 29 Feb 2008 11:14:46 -0000
Subject: [issue2209] mailbox module doesn't support compressed mbox
In-Reply-To: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>
Message-ID: <1204283686.29.0.398991298124.issue2209@psf.upfronthosting.co.za>


New submission from J?rgen A. Erhard:

(Not sure if this goes here)
The mbox class (actually, the _singlefileMailbox class) takes a path,
and not, as the old mailbox module did, an opened file object.  This
makes it hard(er) to access gzipped mbox files (mailbox.open = gzip.open
works, but is ugly).

----------
components: Library (Lib)
messages: 63132
nosy: jae
severity: normal
status: open
title: mailbox module doesn't support compressed mbox
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2209>
__________________________________

From report at bugs.python.org  Fri Feb 29 12:26:17 2008
From: report at bugs.python.org (Tim Golden)
Date: Fri, 29 Feb 2008 11:26:17 -0000
Subject: [issue2208] Patch to doc/make.bat to allow non-standard HTML Help
	location
In-Reply-To: <1204282841.46.0.816451204729.issue2208@psf.upfronthosting.co.za>
Message-ID: <1204284377.05.0.265655595801.issue2208@psf.upfronthosting.co.za>


Tim Golden added the comment:

Corrected patch which replaces the @echo off at the top of the file.

Added file: http://bugs.python.org/file9573/doc-make-r61125.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2208>
__________________________________

From report at bugs.python.org  Fri Feb 29 12:58:55 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 29 Feb 2008 11:58:55 -0000
Subject: [issue1152248] Enhance file.readlines by making line separator
	selectable
Message-ID: <1204286334.92.0.380841154148.issue1152248@psf.upfronthosting.co.za>


Nick Coghlan added the comment:

The mail.python.org link I posted previously is broken. Here's an
updated link to the relevant c.l.p. thread:
http://mail.python.org/pipermail/python-list/2005-February/310020.html

>From my point of view, I still think it's an excellent idea and would be
happy to review a patch, but I'm unlikely to get around to implementing
it myself.

Also keep in mind that we now have the option of doing this only for the
new io module in Python 3.0 - it may be easier to do that and implement
something in pure Python rather than having to deal with the 2.x file
implementation.

(P.S. I found the double negative in Raymond's original comment a little
tricky to parse even as a native English speaker. I would also take
Skip's comment as merely discouraging adding a completely new method
rather than the original idea)

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1152248>
_____________________________________

From report at bugs.python.org  Fri Feb 29 13:04:00 2008
From: report at bugs.python.org (=?utf-8?q?R=C3=BCdiger_Kupper?=)
Date: Fri, 29 Feb 2008 12:04:00 -0000
Subject: [issue2210] Nested module import clutters package namespace
In-Reply-To: <1204286639.84.0.689580155696.issue2210@psf.upfronthosting.co.za>
Message-ID: <1204286639.84.0.689580155696.issue2210@psf.upfronthosting.co.za>


New submission from R?diger Kupper:

When one module of a package imports another module of the same package,
the second module will not only be introduced in the namespace of the
importing module, but also in the namespace of the enclosing package.
I.e., the module will be introduced as variable
<packagename>.<secondmodulename>. If the package namespace contained a
variable of this name before the import, it will be overwritten by the
new value.

For the user, import statements should act like assignments to the local
 namespace. They should never add names to an enclosing namespace. (At
least this is what all documentation and tutorials tell the user.)

Below follows a detailed example for the problem.


Say I have a package named 'pack'. Apart from the '__init__.py' file the 
directory contains two modules 'x.py' and 'y.py':

pack/
      __init__.py
      x.py
      y.py

The files have the following contents:

==== __init__.py ====
import x
=====================

==== x.py ===========
import y
=====================

==== y.py ===========
pass
=====================

I then do
 >>> import pack

This
(1) introduces variable 'x' bound to <module 'pack.x'>
     in pack's namespace (expected)
(2) introduces variable 'q' bound to <module 'pack.y'>
     in x's namespace (expected)
but also
(3) introduces variable 'y' bound to <module 'pack.y'>
     in pack's namespace (*totally unexpected*)

The problem is so bad as to even overwrite any variable 'y' that 
might have existed in pack's namespace before the import.

I created verbose versions of the three files above to illustrate 
what happens (see below.) They do exactly the same as above, but 
print out what they do. This is the output:

---------snip-----------
 >>> import pack
pack: Here is pack.
pack: I now assign y='hello'.
pack: My y is now: 'hello'
pack: I now 'import x' which in turn does 'import y as q'.
   x: Here is x.
   x: I now 'import y as q'.
     y: Here is y.
pack: My y is now: <module 'pack.y' from 'pack/y.pyc'>
pack: Why?
--------snip-------------

I know that any import creates an entry in sys.modules. So 'pack', 
'pack.x' and 'pack.y' get created in sys.modules. That's fine.

Apart from that, an import statement should act equivalent to an 
assignment: it should introduce entries to the local namespace of the
module it appears in. The 'import y as q' appears in x.py, so it 
should add entries to x's namespace *only*.

But why is variable 'y' in pack's namespace overwritten by the 
import in x?


P.S.: These are the files that produce the verbose output. They can be
found in the tgz file attached to this issue.

==== __init__.py ====
print "pack: Here is pack."
print "pack: I now assign y='hello'."
y="hello"
print "pack: My y is now:", repr(y)
print "pack: I now 'import x' which in turn does 'import y as q'."
import x
print "pack: My y is now:", repr(y)
print "pack: Why?"
=====================

==== x.py ===========
print '  x: Here is x.'
print "  x: I now 'import y as q'."
import y as q
=====================

==== y.py ===========
print '    y: Here is y.'
=====================

----------
files: pack.tgz
messages: 63135
nosy: ruediger.kupper
severity: normal
status: open
title: Nested module import clutters package namespace
type: behavior
versions: Python 2.4
Added file: http://bugs.python.org/file9574/pack.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2210>
__________________________________

From report at bugs.python.org  Fri Feb 29 13:10:47 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 29 Feb 2008 12:10:47 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1197051927.23.0.805200385049.issue1569@psf.upfronthosting.co.za>
Message-ID: <1204287047.94.0.213794487833.issue1569@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven added the comment:

Hi Martin,

yes, that's exactly what I am saying actually. :)

This is the resulting file I created: Python26.msi
Right now it only installs into C:\Python26 and puts python.exe, 
pythonw.exe and python26.dll there, but it is a start.

In pcbuild.sln this entry was added:

Project("{54435603-DBB4-11D2-8724-00A0C9A8B90C}") = "Python26", 
"Python26\Python26.vdproj", "{B4DFC5BC-6BEA-41B7-9A40-663F2677E506}"
EndProject

The Python26.vdproj is attached.

More work needs to be done, of course, but I merely wanted a proof of 
concept for a project file that could build a .msi and had the 
appropriate MSM integrated.

Added file: http://bugs.python.org/file9575/Python26.vdproj

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Fri Feb 29 15:09:17 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Feb 2008 14:09:17 -0000
Subject: [issue2206] critical memory leak in hashlib.md5
In-Reply-To: <1204252950.83.0.917993482097.issue2206@psf.upfronthosting.co.za>
Message-ID: <1204294157.88.0.208966058818.issue2206@psf.upfronthosting.co.za>


Changes by Georg Brandl:


----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2206>
__________________________________

From report at bugs.python.org  Fri Feb 29 15:09:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Feb 2008 14:09:43 -0000
Subject: [issue2205] os.times() returns incorrect value
In-Reply-To: <1204250585.31.0.481780521952.issue2205@psf.upfronthosting.co.za>
Message-ID: <1204294183.39.0.506417588971.issue2205@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Isn't that tracked in #1040026?

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2205>
__________________________________

From report at bugs.python.org  Fri Feb 29 15:11:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Feb 2008 14:11:39 -0000
Subject: [issue2196] Fix hasattr's exception problems
In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za>
Message-ID: <1204294299.42.0.133379841403.issue2196@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Please reformat your patch using tabs.

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2196>
__________________________________

From report at bugs.python.org  Fri Feb 29 16:47:55 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 29 Feb 2008 15:47:55 -0000
Subject: [issue2204] document ConfigParser behaviour when a file has same
	section multiple times
In-Reply-To: <1204237897.16.0.790034962439.issue2204@psf.upfronthosting.co.za>
Message-ID: <2c51ecee0802290747m2c6411b5h670e9517409c8feb@mail.gmail.com>


Raghuram Devarakonda added the comment:

>  Should this 'undesirable' behavior be documented? My thoughts are

Document should definitely reflect the code whether the behaviour is
desirable or not.

>  a) All the key,value pairs in the named section be retrived from entire
>  file. Just appending the dict.

Isn't this what is happening now unless I am not following you?

>  Otherwise,
>  b) An Exception can be thrown if it encounters an invalid Configfile
>  having multiple same sections which can cause problem, but I cannot
>  readily think of one such case.

I have no problem with throwing an exception in case of duplicate
sections but I don't think that can be done by default (it may break
some programs).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2204>
__________________________________

From report at bugs.python.org  Fri Feb 29 18:01:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 29 Feb 2008 17:01:44 -0000
Subject: [issue1569] Add VS CRT redist to the MSI installer
In-Reply-To: <1197051927.23.0.805200385049.issue1569@psf.upfronthosting.co.za>
Message-ID: <1204304504.47.0.230880163241.issue1569@psf.upfronthosting.co.za>


Martin v. L?wis added the comment:

Ok, I never doubted VS can do merge modules (what else if not VS could
do so?). What I'm still questioning that it is possible to do a full
Python installer as a VS setup project. I personally don't think it's
even worth the effort to try, but I might be wrong.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1569>
__________________________________

From report at bugs.python.org  Fri Feb 29 19:19:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Feb 2008 18:19:24 -0000
Subject: [issue2207] Bug in Sphinx highlighting when pygments not available
In-Reply-To: <1204282063.81.0.343709498913.issue2207@psf.upfronthosting.co.za>
Message-ID: <1204309164.37.0.116034857454.issue2207@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks, fixed in r61134.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2207>
__________________________________

From report at bugs.python.org  Fri Feb 29 19:21:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 29 Feb 2008 18:21:40 -0000
Subject: [issue2208] Patch to doc/make.bat to allow non-standard HTML Help
	location
In-Reply-To: <1204282841.46.0.816451204729.issue2208@psf.upfronthosting.co.za>
Message-ID: <1204309300.04.0.407195589084.issue2208@psf.upfronthosting.co.za>


Georg Brandl added the comment:

Thanks, applied in r61135.

----------
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2208>
__________________________________

From report at bugs.python.org  Fri Feb 29 20:53:16 2008
From: report at bugs.python.org (Stargaming)
Date: Fri, 29 Feb 2008 19:53:16 -0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1204314796.18.0.498209983403.issue1766304@psf.upfronthosting.co.za>


Stargaming added the comment:

Later on, when Greg mentions the current for/if performance asymmetry,
Guido states: 

> Fair enough. So maybe *you* can contribute a patch?

I don't read this as a rejection, but of course you're right -- this
patch is purely an optimization. As already written in my initial
comment (and discussed on the mailing list), there would be no change in
behaviour: The change from generic iterator behaviour to specific range
performance is transparent to the end-user.

I don't see how the other patches interfere with this one. Waiting until
the development of the range object itself has a stabilized and we
decided upon a member type/API seems sensible. Still, this patch would 
be valid on its own.

Now, your impulse is right: having the performance enhancement in the
bug tracker doesn't help much -- we need a resolution for this. If
someone could review the patch, tell me about the critical parts or
point me to references on how to improve it, I'd be really glad!

On the mentioned unit tests: I'm unsure how to verify this behaviour
since I expect it to affect runtime *only*.

PS. With the new tracker, wouldn't the "resource usage" type fit best?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_____________________________________

From report at bugs.python.org  Fri Feb 29 21:00:59 2008
From: report at bugs.python.org (Jamie Bliss)
Date: Fri, 29 Feb 2008 20:00:59 -0000
Subject: [issue2211] Cookie.Morsel interface needs update
In-Reply-To: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>
Message-ID: <1204315259.46.0.997806067058.issue2211@psf.upfronthosting.co.za>


New submission from Jamie Bliss:

Cookie.Morsel lacks in properly overloading dict methods, amongst other
things:
* .__eq__() does not take .key and .value into account
* .copy() returns a dict, not a Morsel
* .update() allows invalid attributes in, eg
Morsel().update({'eggs':'spam'}) works but Morsel()['eggs'] = 'spam' fails
* .__len__() includes unset keys (why does it set them to an empty string?)
* .__repr__() doesn't print out attributes (path, comment, etc)
* Handling of unicode is fuzzy at best: try Morsel().set(u'eggs\u00bf',
u'\u00f1', u'\00f1'.encode('utf-8'))
* Specifying the idmap and translate function in .set() seems wrong
* Setting .key doesn't check against invalid keys (eg, reserved names)
* The entire Morsel class is undocumented
* There is no way to automatically sync .value and .coded_value

----------
components: Library (Lib)
messages: 63144
nosy: astronouth7303
severity: normal
status: open
title: Cookie.Morsel interface needs update
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2211>
__________________________________

From report at bugs.python.org  Fri Feb 29 21:07:49 2008
From: report at bugs.python.org (Jamie Bliss)
Date: Fri, 29 Feb 2008 20:07:49 -0000
Subject: [issue2212] Cookie.BaseCookie has ambiguous unicode handling
In-Reply-To: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>
Message-ID: <1204315669.5.0.476777122389.issue2212@psf.upfronthosting.co.za>


New submission from Jamie Bliss:

The primary offender is in BaseCookie.load(), which uses the test:
    type(rawdata) == type("")
which should be:
    isinstance(rawdata, basestring)

----------
components: Library (Lib)
messages: 63145
nosy: astronouth7303
severity: normal
status: open
title: Cookie.BaseCookie has ambiguous unicode handling
type: behavior
versions: Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2212>
__________________________________

From report at bugs.python.org  Fri Feb 29 22:33:17 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 29 Feb 2008 21:33:17 -0000
Subject: [issue1766304] improve xrange.__contains__
Message-ID: <1204320797.96.0.761556173229.issue1766304@psf.upfronthosting.co.za>


Alexander Belopolsky added the comment:

Here are my comments on the py3k patch:

1. Sign of a PyLong object o is the same as the sign of Py_SIZE(o).  I 
would think it is safe to use this fact within python core.  (User code 
that may need to work across multiple versions of python may need to be 
more conservative.)

2. If you choose to use zero in the code, there is no need to create it 
twice per call.

3. Py_INCREF(zero); is unnecessary and creates a reference leak.

4. range_contains should return -1 when error is detected, not 0.

2.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1766304>
_____________________________________

From report at bugs.python.org  Fri Feb 29 23:04:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 29 Feb 2008 22:04:36 -0000
Subject: [issue2196] Fix hasattr's exception problems
In-Reply-To: <1204066315.71.0.0794011213674.issue2196@psf.upfronthosting.co.za>
Message-ID: <1204322676.49.0.787938887925.issue2196@psf.upfronthosting.co.za>


Benjamin Peterson added the comment:

After looking more closely, I saw that this is documented at
http://www.python.org/dev/patches/style/. So the C uses tabs, and the
Python uses spaces?

Added file: http://bugs.python.org/file9576/hasattr_fixes-good-indentation.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2196>
__________________________________

From report at bugs.python.org  Fri Feb 29 23:45:48 2008
From: report at bugs.python.org (Paul Pogonyshev)
Date: Fri, 29 Feb 2008 22:45:48 -0000
Subject: [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204325148.56.0.489205904863.issue2199@psf.upfronthosting.co.za>


Paul Pogonyshev added the comment:

Please close this issue.  It is a PyGObject bug, nothing to do with
Python: http://bugzilla.gnome.org/show_bug.cgi?id=519645

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________

From report at bugs.python.org  Fri Feb 29 23:56:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 29 Feb 2008 22:56:47 -0000
Subject: [issue2199] cPickle error with gtk GEnum classes
In-Reply-To: <1204206384.27.0.149974738498.issue2199@psf.upfronthosting.co.za>
Message-ID: <1204325807.89.0.183731992807.issue2199@psf.upfronthosting.co.za>


Changes by Martin v. L?wis:


----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2199>
__________________________________