From report at bugs.python.org  Tue Apr  1 00:19:27 2008
From: report at bugs.python.org (Christoph Burgmer)
Date: Mon, 31 Mar 2008 22:19:27 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207001967.74.0.594442324061.issue2517@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

Though I welcome the reopening of the bug for Python 3.0 I must say 
that plans of not fixing a core element rather surprises me.

I never believed Python to be a programming language with good Unicode 
integration. Several points were missing that would've been nice or 
even essential to have for good development with Unicode, most ignored 
for the sake of maintaining backward compatibility. This though is not 
the fault of the Unicode class itself and supporting packages.

Some modules like the one for CSV are lacking full Unicode support. 
But nevertheless the basic Python would always give you the 
possibility to use Unicode in (at least) a consistent way. For me 
raising exceptions does count as basic support like this.

So I still hope to see this solved for the 2.x versions which I read 
will be maintained even after the release of 3.0.

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

From report at bugs.python.org  Tue Apr  1 00:30:42 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 31 Mar 2008 22:30:42 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207002642.85.0.839472478372.issue2517@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

>I never believed Python to be a programming language with good Unicode 
>integration. Several points were missing that would've been nice or 
>even essential to have for good development with Unicode, most ignored 
>for the sake of maintaining backward compatibility. This though is not 
>the fault of the Unicode class itself and supporting packages.
Many (including myself) agree with you. That's pretty much the whole
point of Py3k. We want to fix the Python "warts" which can only be fixed
by breaking backwards compatibility.

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

From report at bugs.python.org  Tue Apr  1 01:08:22 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Mon, 31 Mar 2008 23:08:22 +0000
Subject: [issue2152] make sqlite.Row hashable correctly
In-Reply-To: <1203590912.21.0.769567830293.issue2152@psf.upfronthosting.co.za>
Message-ID: <1207004901.98.0.413219566652.issue2152@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Thanks a lot! I will review and apply this after the next releases.
Don't want to rush things in now that the next alphas are so close. Btw.
I don't find forward-porting to py3k particularly easy. The diffs
between the 2.6 version and th 3.0 version in the sqlite3 module are
quite large.

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

From report at bugs.python.org  Tue Apr  1 01:10:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 31 Mar 2008 23:10:49 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207005049.2.0.119955214563.issue2517@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Even in 2.5, __str__ is allowed to return a Unicode object;
we could change BaseException_str this way:

Index: exceptions.c
===================================================================
--- exceptions.c	(revision 61957)
+++ exceptions.c	(working copy)
@@ -108,6 +104,11 @@
         break;
     case 1:
         out = PyObject_Str(PyTuple_GET_ITEM(self->args, 0));
+        if (out == NULL &&
PyErr_ExceptionMatches(PyExc_UnicodeEncodeError))
+        {
+            PyErr_Clear();
+            out = PyObject_Unicode(PyTuple_GET_ITEM(self->args, 0));
+        }
         break;
     default:
         out = PyObject_Str(self->args);

Then str(e) still raises UnicodeEncodeError,
but unicode(e) returns the original message.

But I would like the opinion of an experimented core developer...

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

From report at bugs.python.org  Tue Apr  1 04:22:29 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 02:22:29 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207016549.45.0.589890721221.issue2517@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

After thinking some more, I'm going to add 2.6 to this. I'm attaching a
patch for the trunk (it can be merged in Py3k, and maybe 2.5) which
displays a UnicodeWarning when an Exception cannot be displayed due to
encoding issues.

Georg, can you review Amaury's and my patches? Also, would mine be a
candidate for 2.5 backporting?

----------
assignee:  -> georg.brandl
keywords: +patch
nosy: +georg.brandl
versions: +Python 2.5, Python 2.6
Added file: http://bugs.python.org/file9915/unicode_exception_warning.patch

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

From report at bugs.python.org  Tue Apr  1 04:33:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 02:33:34 +0000
Subject: [issue2519] Typing 'modules' in the interactive help system fails
	when imports fail
In-Reply-To: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za>
Message-ID: <1207017214.83.0.731165016176.issue2519@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Would you like to work on a patch?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Apr  1 04:33:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 02:33:58 +0000
Subject: [issue2519] Typing 'modules' in the interactive help system fails
	when imports fail
In-Reply-To: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za>
Message-ID: <1207017238.21.0.554450246294.issue2519@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
type:  -> feature request

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

From report at bugs.python.org  Tue Apr  1 05:54:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 01 Apr 2008 03:54:16 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

The USTimeZone example class hasn't been updated for the new US DST
rules that went into effect in 2007.  For a description of the new
rules, see:

http://wwp.greenwichmeantime.com/daylight-saving-time/usa/dst-2007.htm

----------
assignee: georg.brandl
components: Documentation
keywords: easy
messages: 64800
nosy: georg.brandl, gvanrossum
priority: high
severity: normal
status: open
title: class USTimeZone in Doc/includes/tzinfo-examples.py is out of date
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Apr  1 06:48:33 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 01 Apr 2008 04:48:33 +0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1207025313.02.0.0515969094548.issue1631171@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

I didn't realize this was waiting for me.  You should have just checked
it in, that would have gotten me to review faster. :-)

pythonrun.c:
 * Should PyModule_GetWarningsModule() return a valid pointer?
 * The code below crashes.  Need to XDECREF, not DECREF (or similar).
+        PyObject *warnings_module = PyImport_ImportModule("warnings");
+        if (!warnings_module)
+            PyErr_Clear();
+        Py_DECREF(warnings_module);

Python/_warnings.c:
 * Remove // XXX(nnorwitz): need to parse -W cmd line flags

Include/pythonrun.h
 * init_warnings has the wrong name (not prefixed with _Py).  I'm not
sure it should be exported at all.

test_support/frozen:  did you want the captured_std{out,err} change in
this patch?

Changes to Makefile.pre.in other than adding _warnings.o?

I think this is good enough if it's working.  How about checking it in
after 1) the alpha is released Wed and 2) fixing up the nits?

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

From report at bugs.python.org  Tue Apr  1 08:41:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Apr 2008 06:41:09 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207032069.76.0.0258023691029.issue2517@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Shouldn't it be an exception rather than a warning? The fact that an
exception can be downgraded to a warning (and thus involuntarily
silenced) is a bit disturbing IMHO.

Another possibility would be to display the warning, and *then* to
encode the exception message again in "replace" or "ignore" mode rather
than "strict" mode. That way exception messages are always displayed,
but not always properly. The ASCII part of the message is generally
useful, since it gives the exception name and most often the reason too.

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Apr  1 09:56:52 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Apr 2008 07:56:52 +0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1207036612.14.0.156174597843.issue1631171@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

After all the threats about checking in code that break stuff, I am not 
about to check this in. =)

I will get to the changes when I can and then commit after the alpha.

----------
assignee: nnorwitz -> brett.cannon

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

From report at bugs.python.org  Tue Apr  1 12:08:10 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Tue, 01 Apr 2008 10:08:10 +0000
Subject: [issue1700463] VC6 build patch for trunk
Message-ID: <1207044490.87.0.290657727342.issue1700463@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


Removed file: http://bugs.python.org/file9044/vc6-trunk-ver4.patch

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

From report at bugs.python.org  Tue Apr  1 13:35:26 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Tue, 01 Apr 2008 11:35:26 +0000
Subject: [issue2526] str.format() :n format does not appear to work
In-Reply-To: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>
Message-ID: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

>>> # Py30a3
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "en_US.UTF8")
'en_US.UTF8'
>>> locale.format("%d", 12345, True)
'12,345'
>>> "{0:n}".format(12345)
'12345'

According to the docs the 'n' format should use the locale-dependent
separator, so I expected both strings to be '12,345'.

Also, it is a pity that locale.format() uses the old deprecated % syntax
rather than the much nicer and better str.format() syntax.

----------
components: Interpreter Core
messages: 64804
nosy: mark
severity: normal
status: open
title: str.format() :n format does not appear to work
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  1 14:13:47 2008
From: report at bugs.python.org (Peter Otten)
Date: Tue, 01 Apr 2008 12:13:47 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>


New submission from Peter Otten <__peter__ at web.de>:

I'd like to suggest a different approach than the one taken in rev. 
54348 to improve timeit's scripting interface: allow passing it a 
namespace. Reasons:

- It has smaller overhead for functions that take an argument:
>>> def f(a): pass
...
# trunk
>>> min(ht.Timer(lambda f=f: f(42)).repeat())
0.54068493843078613
# my patch
>>> min(mt.Timer("f(42)", ns=dict(f=f)).repeat())
0.29009604454040527

- it is more flexible. Example:
# working code, requires matplotlib
from timeit import Timer
from time import sleep

def linear(i):
    sleep(.05*i)
def quadratic(i):
    sleep(.01*i**2)

x = range(10)
y = []
for a in x:
    y.append([min(Timer("f(a)", ns=dict(f=f, a=a)).repeat(1, 1))
              for f in linear, quadratic])

from pylab import plot, show
plot(x, y)
show()

The above code works unaltered inside a function, unlike the hacks 
using "from __main__ import ...".

- the implementation is simpler and should be easy to maintain.

The provided patch is against 2.5.1. If it has a chance of being 
accepted I'm willing to jump through the necessary hoops: 
documentation, tests, etc.

----------
components: Library (Lib)
files: diff_against_2_5_1.txt
messages: 64805
nosy: potten
severity: normal
status: open
title: Pass a namespace to timeit
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9916/diff_against_2_5_1.txt

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

From report at bugs.python.org  Tue Apr  1 14:42:25 2008
From: report at bugs.python.org (Jason Tishler)
Date: Tue, 01 Apr 2008 12:42:25 +0000
Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases.
In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
Message-ID: <1207053745.73.0.300009547483.issue2234@psf.upfronthosting.co.za>


Jason Tishler <jason at tishler.net> added the comment:

If the version is guaranteed to be x.y or x.y.z, then the patch seems 
correct.  Note I am not set up to test this patch and it has been 
years since I have looked at this part of the code base.  Sorry, that 
I can't be more helpful.

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

From report at bugs.python.org  Tue Apr  1 14:44:43 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 12:44:43 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207053883.18.0.487884122409.issue2517@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Have you looked at PyErr_Display? There are many, many possible
exceptions, and it ignores them all because "too many callers rely on
this." So, I think all we can do is warn. I will look into encoding the
message differently.

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

From report at bugs.python.org  Tue Apr  1 14:52:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 12:52:15 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1207054335.15.0.62834599587.issue2527@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +georg.brandl

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

From report at bugs.python.org  Tue Apr  1 15:14:36 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Apr 2008 13:14:36 +0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1207055676.43.0.961222308102.issue1631171@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Neal's issues are addressed in this patch. I also finally filled out 
warnings.h. The only thing that I didn't deal with is Neal's worry of 
exposing _PyWarnings_Init(). It is not explicitly exported anywhere as 
part of the API so I am not sure what he is worrying about.

The attached patch is finished for CPython. I do want to go back and put 
back in the pure Python code that _warnings.c replaces so that 
alternative VMs don't have to implement any part of warnings if they 
don't want to.

Added file: http://bugs.python.org/file9917/c_warnings.diff

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

From report at bugs.python.org  Tue Apr  1 15:23:16 2008
From: report at bugs.python.org (Ned Batchelder)
Date: Tue, 01 Apr 2008 13:23:16 +0000
Subject: [issue2506] Line tracing of continue after always-taken if is
	incorrect
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1207056196.31.0.659698123414.issue2506@psf.upfronthosting.co.za>


Ned Batchelder <nedbat at users.sourceforge.net> added the comment:

It's hard for me to agree with your assessment that for no practical
good would come from disabling the optimizer.  Broadly speaking, there
are two types of code execution: the vast majority of the time, you
execute the code so that it can do its work.  In this case, speed is
most important, and the peephole optimizer is a good thing. But another
important case is when you need to reason about the code.  This second
case includes coverage testing, debugging, and other types of analysis. 

Compiled languages have long recognized the need for both types of
compilation, which is why they support disabling optimization entirely.

As Python becomes more complex, and more broadly deployed, the needs of
the two types of execution will diverge more and more.  More complex
optimizations will be attempted in order to squeeze out every last drop
of performance.  And more complex tools to reason about the code will be
developed to provide rich support to those using Python for complex
development.

I see discussion here of moving the optimizer to the AST level instead
of the bytecode level.  This won't change the situation.  The optimizer
will still interfere with analysis tools.

As a developer of analysis tools, what should I tell my users when their
code behaves mysteriously?

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

From report at bugs.python.org  Tue Apr  1 15:35:29 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Apr 2008 13:35:29 +0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1207056929.06.0.462124163366.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file9761/c_warnings.diff

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

From report at bugs.python.org  Tue Apr  1 16:03:01 2008
From: report at bugs.python.org (Andrii V. Mishkovskyi)
Date: Tue, 01 Apr 2008 14:03:01 +0000
Subject: [issue2522] locale.format() problems with decimal separator
In-Reply-To: <1206983289.11.0.844443108334.issue2522@psf.upfronthosting.co.za>
Message-ID: <1207058581.06.0.906557111009.issue2522@psf.upfronthosting.co.za>


Andrii V. Mishkovskyi <mishok13 at gmail.com> added the comment:

I've uploaded a patch that fixes this concrete issue, though
locale.format() continues to silently ignore other types of malformed
strings (e.g. locale.format('%fSPAMf')).
I don't think this is correct behavior. Maybe there should be reg-exp
that locale.format() will use to avoid such issues.

----------
components: +Library (Lib)
keywords: +patch
Added file: http://bugs.python.org/file9918/locale.diff

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

From report at bugs.python.org  Tue Apr  1 16:19:19 2008
From: report at bugs.python.org (Tim Golden)
Date: Tue, 01 Apr 2008 14:19:19 +0000
Subject: [issue2528] Change os.access to check ACLs under Windows
In-Reply-To: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>
Message-ID: <1207059558.9.0.891835325783.issue2528@psf.upfronthosting.co.za>


New submission from Tim Golden <mail at timgolden.me.uk>:

At present, os.access under Windows simply calls GetFileAttributes to
determine the readonly attribute (ignoring directories). The patch
attached combines this with the use of the AccessCheck API to compare
the user's permissions with those required for the path.

I'm assuming that ATTRIB and CACLS will be available for use in the unit
tests included.

I haven't altered the structure of the posix_access function at all
although I suspect that it could now be simplified now that we're not
supporting Win9x.

----------
components: Library (Lib)
files: os_access-r62091.patch
keywords: patch
messages: 64811
nosy: tim.golden
severity: normal
status: open
title: Change os.access to check ACLs under Windows
versions: Python 2.6
Added file: http://bugs.python.org/file9919/os_access-r62091.patch

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

From report at bugs.python.org  Tue Apr  1 17:48:05 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Apr 2008 15:48:05 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1207064885.49.0.555247728453.issue2527@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

A more general approach would be to add both 'locals' and 'globals' to
be used by exec.  At least, I would change 'ns' to 'locals'.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Tue Apr  1 17:50:28 2008
From: report at bugs.python.org (John Krukoff)
Date: Tue, 01 Apr 2008 15:50:28 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1207065028.34.0.992820366076.issue643841@psf.upfronthosting.co.za>


John Krukoff <helot at comcast.net> added the comment:

I assume when you say that the documentation has already been updated, 
you mean something other than what's shown at:
http://docs.python.org/dev/reference/datamodel.html#new-style-and-
classic-classes
or
http://docs.python.org/dev/3.0/reference/datamodel.html#new-style-and-
classic-classes ?

As both of those claim to still not be up to date in relation to new 
style classes, and the __getattr__ & __getattribute__ sections under 
special names make no reference to how magic methods are handled. 
Additionally, the "Class Instances" section under the type heirachy 
makes mention of how attributes are looked up, but doesn't mention the 
new style differences even in the 3.0 documentation.

Sure, there's this note under "Special Method Names": 
For new-style classes, special methods are only guaranteed to work if 
defined in an object?s class, not in the object?s instance dictionary. 

But that only helps you figure it out if you already know what the 
problem is, and it's hardly comprehensive.

I'm not arguing that this is something that's going to change, as we're 
way past the point of discussion on the implementation, but this looks 
far more annoying if you're looking at it from the perspective of 
proxying to container classes or numeric types in a generic fashion. My 
two use cases I've had to convert are for lazy initialization of an 
object and for building an object that uses RPC to proxy access to an 
object to a remote server.

In both cases, since they are generic proxies that once initialized are 
supposed to behave exactly like the proxied instance, the list of magic 
methods to pass along is ridiculously long. Sure, I have to handle 
__copy__ & __deepcopy__, and __getstate__ & __setstate__ to make sure 
that they return instances of the proxy rather than the proxied object, 
but other than that there's over 50 attributes to override for new 
style classes just to handle proxying to numeric and container types. 

It's hard to get fancy about it too, as I can't just dynamically add 
the needed attributes to my instances by looking at the object to be 
proxied, it really has to be a static list of everything that python 
supports on the class. Additionally, while metaclasses might help here, 
there's still the problem that while my old style proxy class has 
continued to work fine as magic attributes have been added over python 
revisions, my new style equivalent will have to be updated work 
currectly as magic methods are added. Which, given the 2.x track seems 
to happen pretty frequently. Some of the bugs from that would have been 
quite tricky to track down too, such as the __cmp__ augmentation with 
the rich comparison methods.

None of the solutions really seem ideal, or at least as good as what 
old style classes provided, which is why I was hoping for some support 
in the 3.0 standard library or the conversion tool.

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

From report at bugs.python.org  Tue Apr  1 17:53:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 01 Apr 2008 15:53:24 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1207065204.89.0.581906729803.issue2527@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the second thought, I actually wanted Timer to mimic eval without
realizing that eval uses positional rather than keywords arguments. 
'locals' is obviously a bad choice for the keyword parameter because it
masks locals() builtin.  Maybe 'local_namespace'?

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

From report at bugs.python.org  Tue Apr  1 20:20:37 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Tue, 01 Apr 2008 18:20:37 +0000
Subject: [issue2234] cygwinccompiler.py fails for latest MinGW releases.
In-Reply-To: <1204656219.89.0.991339984516.issue2234@psf.upfronthosting.co.za>
Message-ID: <1207074037.81.0.841625345668.issue2234@psf.upfronthosting.co.za>


Lenard Lindstrom <len-l at telus.net> added the comment:

distutils.version.StrictVersion.parse does not handle x.y.z.n . That is
why there is an exception. I have tested the patch both with
binutils-2.18.50-20080109 (*), the latest version (a "Technology
Preview"), and its predecessor binutils-2.18.50-20071123, which also
works without the proposed patch. I use MinGW to build Pygame. Finally,
there should be no reason to use earlier versions of binutils with
Python 2.4 and up as msvcr71 support was introduced only a couple of
years ago.

(*) The MinGW binutils bundle contains both ld and dllwrap

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

From report at bugs.python.org  Tue Apr  1 20:50:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Tue, 01 Apr 2008 18:50:36 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1207075836.63.0.601365804529.issue2527@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Generally, when I use timeit from the interpreter prompt, I use "from
__main__ import *" as the setup code string. Then I can use all
currently defined global symbols directly :)

----------
nosy: +pitrou

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

From report at bugs.python.org  Tue Apr  1 20:55:27 2008
From: report at bugs.python.org (Dennis Kaarsemaker)
Date: Tue, 01 Apr 2008 18:55:27 +0000
Subject: [issue2519] Typing 'modules' in the interactive help system fails
	when imports fail
In-Reply-To: <1206949196.03.0.881908306183.issue2519@psf.upfronthosting.co.za>
Message-ID: <1207076127.86.0.951991735328.issue2519@psf.upfronthosting.co.za>


Dennis Kaarsemaker <dennis at kaarsemaker.net> added the comment:

pydoc.py from head actually does work around it in some places, but not
all. Will send a patch.

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

From report at bugs.python.org  Tue Apr  1 21:19:10 2008
From: report at bugs.python.org (Nick Guenther)
Date: Tue, 01 Apr 2008 19:19:10 +0000
Subject: [issue2529] list/generator comprehension parser doesn't match spec
In-Reply-To: <1207077549.89.0.118557412226.issue2529@psf.upfronthosting.co.za>
Message-ID: <1207077549.89.0.118557412226.issue2529@psf.upfronthosting.co.za>


New submission from Nick Guenther <kousu at users.sourceforge.net>:

I think I've found a bug in python's list comprehension parser. Observe:

>>> [e for i in j in ['a','b','c']]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
NameError: name 'j' is not defined

Now, according to the grammar at http://docs.python.org/ref/lists.html,
a list comprehension is (condensed for clarity):
list_comprehension 	::= 	expression list_for
list_for 	::= 	"for" target_list "in" old_expression_list [list_for]

So a list comprehension should always be 
[.... for ... in .... for ... in ... for ... in ...]
(that is, alternating 'for's and 'in's) but here I have a test case that
python happily tries to run that looks like
[... for ... in ... in ....]

----------
components: Interpreter Core
messages: 64818
nosy: kousu
severity: normal
status: open
title: list/generator comprehension parser doesn't match spec
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  1 22:04:44 2008
From: report at bugs.python.org (Robert Lehmann)
Date: Tue, 01 Apr 2008 20:04:44 +0000
Subject: [issue2529] list/generator comprehension parser doesn't match spec
In-Reply-To: <1207077549.89.0.118557412226.issue2529@psf.upfronthosting.co.za>
Message-ID: <1207080284.05.0.876108272174.issue2529@psf.upfronthosting.co.za>


Robert Lehmann <lehmannro at gmail.com> added the comment:

Your example is parsed as [e for i in (j in ['a','b','c'])] and since
`j` is not defined, you get a NameError. If it was defined, you would
still be iterating a boolean (which is not defined).

Grammatically, this is the following (just the important parts, again):
list_comprehension ::=  expression list_for
list_for ::=  "for" target_list "in" old_expression_list
old_expression_list ::= old_expression
old_expression ::= <stripped test hierarchy...> comparison
comparison ::= or_expr ( comp_operator or_expr )*
comp_operator ::= "in"

So your basic misconception is that both `in` keywords are belonging to
the list comprehension syntax -- the former does while the latter is
simply an operator.

----------
nosy: +lehmannro

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

From report at bugs.python.org  Tue Apr  1 22:07:30 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Apr 2008 20:07:30 +0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1207080450.87.0.923526316836.issue1631171@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


Removed file: http://bugs.python.org/file9917/c_warnings.diff

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

From report at bugs.python.org  Tue Apr  1 22:07:24 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 01 Apr 2008 20:07:24 +0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1207080444.29.0.553994425076.issue1631171@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Attached should have everything, including a pure Python fallback. As soon 
as the next alpha is out I will apply.

----------
status: open -> pending
Added file: http://bugs.python.org/file9920/c_warnings.diff

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

From report at bugs.python.org  Tue Apr  1 22:36:29 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 01 Apr 2008 20:36:29 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1207082189.14.0.807320127592.issue1068268@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Of course the signal handler may raise an exception, so my last argument
isn't that good.

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

From report at bugs.python.org  Tue Apr  1 22:41:47 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 20:41:47 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

The IO module currently has some docs strings but no official RST docs.
I'm willing to work on this.

----------
assignee: benjamin.peterson
components: Documentation
messages: 64822
nosy: benjamin.peterson, georg.brandl
priority: critical
severity: normal
status: open
title: Document IO module
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  1 22:56:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 01 Apr 2008 20:56:06 +0000
Subject: [issue2529] list/generator comprehension parser doesn't match spec
In-Reply-To: <1207077549.89.0.118557412226.issue2529@psf.upfronthosting.co.za>
Message-ID: <1207083366.2.0.472891887203.issue2529@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Indeed; your sample is equivalent to:

temp = (j in ['a','b','c'])        # the "contains" operator
[e for i in temp]                  # basic list comprehension

Even if not meaningful, this code is syntactically correct.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Tue Apr  1 23:51:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 01 Apr 2008 21:51:46 +0000
Subject: [issue2510] Bazaar ignore file
In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za>
Message-ID: <1207086706.69.0.0857107365583.issue2510@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Georg, Ralf, and Jeroen, are you ok with me checking this in now?

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

From report at bugs.python.org  Wed Apr  2 00:02:21 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 01 Apr 2008 22:02:21 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207087341.54.0.455171160081.issue2513@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Hi Mark,

I hope this patch makes it into 2.6. 

One thing I'm curious about is the version of "Visual Studio 2008" that
is needed to support this kind cross-compilation and which version will
be or is used to build the Python versions on 64-bit Windows.

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

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

From report at bugs.python.org  Wed Apr  2 00:09:35 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 01 Apr 2008 22:09:35 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207087775.84.0.929619500175.issue2513@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Nevermind, diving deep into the MSDN, I found the answer:
http://msdn2.microsoft.com/en-us/library/hs24szh9.aspx

So for cross-compilation, the Visual Studio 2008 Standard Edition is
sufficient.

Is the Professional Edition used for the standard Python binaries ? Does
it generate faster code ?

A bit off-topic, I know, but it's really hard to find this important
information elsewhere and may well be of use for other Python extension
authors as well.

Thanks.

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

From report at bugs.python.org  Wed Apr  2 00:11:37 2008
From: report at bugs.python.org (Jeremy Dunck)
Date: Tue, 01 Apr 2008 22:11:37 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>


New submission from Jeremy Dunck <jdunck at users.sourceforge.net>:

Within python 2.5.2:

>>> from decimal import Decimal
>>> x = 3.0
>>> y = Decimal('0.25')
>>> x > y
False (expected error, as in 2.4, or True)

----------
components: Library (Lib)
messages: 64827
nosy: jdunck
severity: normal
status: open
title: float compared to decimal is silently incorrect.
versions: Python 2.5

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

From report at bugs.python.org  Wed Apr  2 00:12:19 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 01 Apr 2008 22:12:19 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1207087939.63.0.868817824504.issue1068268@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Wed Apr  2 00:30:36 2008
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 01 Apr 2008 22:30:36 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207089036.6.0.205812740385.issue2513@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Hi Marc-Andre,
  The PCBuild/README.txt file has some info about compatibility with VS
versions (but probably needs to say more about x64 builds).  There is
also talk about releasing "Profile Guided Optimization" built binaries,
which does require a professional version.  I believe, but am not sure,
that Martin uses the professional versions to make the official
binaries.  Either way, this might be getting off-topic for this patch.

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

From report at bugs.python.org  Wed Apr  2 02:10:16 2008
From: report at bugs.python.org (Maciek Fijalkowski)
Date: Wed, 02 Apr 2008 00:10:16 +0000
Subject: [issue2532] file that breaks 2to3 (despite being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>


New submission from Maciek Fijalkowski <fijal at genesilico.pl>:

Infinite recursion problem. I know this file is obscure, but it's still
pretty valid python.

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: ssl.py
messages: 64829
nosy: collinwinter, fijal
severity: normal
status: open
title: file that breaks 2to3 (despite being correct python)
Added file: http://bugs.python.org/file9921/ssl.py

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

From report at bugs.python.org  Wed Apr  2 04:23:59 2008
From: report at bugs.python.org (Thomas Dimson)
Date: Wed, 02 Apr 2008 02:23:59 +0000
Subject: [issue2533] Invalid TypeError with class method decorator and class
	method parameter
In-Reply-To: <1207103039.83.0.312467912668.issue2533@psf.upfronthosting.co.za>
Message-ID: <1207103039.83.0.312467912668.issue2533@psf.upfronthosting.co.za>


New submission from Thomas Dimson <tdimson at gmail.com>:

Having a peculiar issue (exception raised despite being valid) when
defining a decorator that takes a class method as a callback. Here is a
cooked example:

def decorator( callback ):
    def inner(func):
        def application( *args, **kwargs ):
            callback(*args,**kwargs)
            func(*args,**kwargs)
        return application
    return inner

class DecorateMe:
    @decorator( callback=DecorateMe.callback )
    def youBet( self ):
        pass
    def callback( self ):
        print "Hello!"

>>> DecorateMe().youBet()
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    DecorateMe().youBet()
  File "C:\Python25\badpython.py", line 4, in application
    callback(*args,**kwargs)
TypeError: unbound method callback() must be called with DecorateMe
instance as first argument (got DecorateMe instance instead)

If you change the line "callback=DecorateMe.callback" to
"callback=lambda x: DecorateMe.callback(x)" python gives you:

>>> DecorateMe().youBet()
Hello!

Mysteriously, I did encounter this during my coding with a non-cooked
decorator.

----------
components: None
messages: 64830
nosy: tdimson
severity: normal
status: open
title: Invalid TypeError with class method decorator and class method parameter
type: behavior
versions: Python 2.4, Python 2.5

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

From report at bugs.python.org  Wed Apr  2 04:31:17 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 02 Apr 2008 02:31:17 +0000
Subject: [issue1631171] implement warnings module in C
In-Reply-To: <1207055676.43.0.961222308102.issue1631171@psf.upfronthosting.co.za>
Message-ID: <ee2a432c0804011931kd17a109ie500930c52d8d070@mail.gmail.com>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

On Tue, Apr 1, 2008 at 6:14 AM, Brett Cannon <report at bugs.python.org> wrote:
>
>  Brett Cannon <brett at python.org> added the comment:
>
>  Neal's issues are addressed in this patch. I also finally filled out
>  warnings.h. The only thing that I didn't deal with is Neal's worry of
>  exposing _PyWarnings_Init(). It is not explicitly exported anywhere as
>  part of the API so I am not sure what he is worrying about.

I wasn't so worried about exposing it, I didn't like the name
pollution (we're talking about init_warnings, right?).  I know that we
have other modules that use init*, but those are broken too.  I'm not
sure we should fix those in 2.6, but 3.0 we should.

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

From report at bugs.python.org  Wed Apr  2 04:55:43 2008
From: report at bugs.python.org (Diego Manenti Martins)
Date: Wed, 02 Apr 2008 02:55:43 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1207104943.69.0.966853900607.issue2531@psf.upfronthosting.co.za>


Changes by Diego Manenti Martins <dmmartins at gmail.com>:


----------
keywords: +patch
versions: +Python 2.6
Added file: http://bugs.python.org/file9922/decimal.patch

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

From report at bugs.python.org  Wed Apr  2 05:02:20 2008
From: report at bugs.python.org (Jeffrey Yasskin)
Date: Wed, 02 Apr 2008 03:02:20 +0000
Subject: [issue1068268] subprocess is not EINTR-safe
Message-ID: <1207105340.86.0.506861428829.issue1068268@psf.upfronthosting.co.za>


Jeffrey Yasskin <jyasskin at gmail.com> added the comment:

I think the proper behavior on EINTR may depend on which subprocess call
we're in. For example, the user can easily loop on .wait() herself if
she wants to ignore EINTR. But it's a lot harder to loop on Popen() if
the read() in _execute_child is interrupted. So my inclination would be
to let EINTR be raised in the first case, and use a loop to handle it in
the second.

Regarding the patch, a wrapper function called as
"retry_on_eintr(obj.write, data)" might be a cleaner way to do it.

----------
nosy: +jyasskin

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

From report at bugs.python.org  Wed Apr  2 05:08:42 2008
From: report at bugs.python.org (Jeremy Dunck)
Date: Wed, 02 Apr 2008 03:08:42 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1207105722.13.0.933013243721.issue2531@psf.upfronthosting.co.za>


Changes by Jeremy Dunck <jdunck at gmail.com>:


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

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

From report at bugs.python.org  Wed Apr  2 06:03:45 2008
From: report at bugs.python.org (HiroakiKawai)
Date: Wed, 02 Apr 2008 04:03:45 +0000
Subject: [issue2518] smtpd.py to handle huge email
In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za>
Message-ID: <1207109025.06.0.102579678204.issue2518@psf.upfronthosting.co.za>


Changes by HiroakiKawai <kawai at apache.org>:


Added file: http://bugs.python.org/file9923/smtpd.patch

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

From report at bugs.python.org  Wed Apr  2 06:04:00 2008
From: report at bugs.python.org (HiroakiKawai)
Date: Wed, 02 Apr 2008 04:04:00 +0000
Subject: [issue2518] smtpd.py to handle huge email
In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za>
Message-ID: <1207109040.59.0.725484497216.issue2518@psf.upfronthosting.co.za>


Changes by HiroakiKawai <kawai at apache.org>:


Removed file: http://bugs.python.org/file9910/smtpd.patch

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

From report at bugs.python.org  Wed Apr  2 07:19:02 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Wed, 02 Apr 2008 05:19:02 +0000
Subject: [issue2510] Bazaar ignore file
In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za>
Message-ID: <1207113542.77.0.121728107285.issue2510@psf.upfronthosting.co.za>


Jeroen Ruigrok van der Werven <asmodai at in-nomine.org> added the comment:

Go ahead. I'm not a committer, merely a person on the side.

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

From report at bugs.python.org  Wed Apr  2 07:26:09 2008
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 02 Apr 2008 05:26:09 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207113969.86.0.981258331102.issue2513@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Hi guys, have been on holiday since PyCon ended, only getting back into 
the swing of things now.  With regards to the x64 Windows build, 
indeed, PCbuild/readme.txt is definitely in need of an update, 
especially with the details of the slightly new build system I checked 
in a few weeks ago.

As it currently stands, the Professional version of Visual Studio 2008 
is required for a complete x64 build, however, this is because a cross-
compilation 'vsvars32.bat'-type file needs to be called in order to do 
command line (i.e. nmake) x64 builds.

(The particular file I'm referring to is "C:\Program Files (x86)
\Microsoft Visual Studio 9.0\VC\vcvarsall.bat", which needs to be 
invoked with 'x86_amd64' as the first parameter.  This is only shipped 
with the Professional version of Visual Studio 2008 -- the buildbots 
currently rely on it to produce x64 builds, see 
http://svn.python.org/projects/python/trunk/Tools/buildbot/build-
amd64.bat.)

We need to invoke this particular batch file in order to build x64 
versions tcl/tk and openssl because we're currently reliant on the 
nmake-oriented builds each of these projects ship with.  

That said, the next step in my build-related improvements is to remove 
this reliance and mimick the nmake-oriented builds with custom .vcproj 
builds that inherit all of our property sheets -- this is the approach 
I took with bsddb and sqlite3 and it worked *very*, *very* well.  (See 
_bsddb44.vcproj and sqlite3.vcproj in the PCbuild directory.)

There are many advantages with this approach.  To name a few: the 
release versions of the modules will benefit from profile guided 
optimisation, just like the rest of the python build, the modules are 
significantly easier to debug, and there is no chance for conflicting 
compiler/linker flags (which was a continual source of pain with 
bsddb/sqlite3 when they were built with the vendor-supplied build 
system).

So, eventually, you should be able to build and entire release version 
of Python x64 with just the Express edition of Visual Studio 2008 (note 
that the Express edition won't support a PGO build though).  
The 'official' release though will be built with a Professional version 
though, as Mark states, thus allowing us to take advantage of profile 
guided optimisation.

Hopefully this isn't too much off topic.  (I can't comment on the 
patches Mark has provided just yet as I haven't had a chance to review 
them -- just wanted to clear up the x64 cross-compilation questions.)

Perhaps I should create a separate issue to track the work needed to 
cross compile an x64 build with the Express edition only.  Any 
objections?

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

From report at bugs.python.org  Wed Apr  2 07:33:37 2008
From: report at bugs.python.org (Christian Theune)
Date: Wed, 02 Apr 2008 05:33:37 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207114417.74.0.348831890973.issue2513@psf.upfronthosting.co.za>


Christian Theune <ct at gocept.com> added the comment:

Mark, I think you mixed me up with Christian Heimes, so I'm removing
myself here (at least for now).

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

From report at bugs.python.org  Wed Apr  2 07:34:31 2008
From: report at bugs.python.org (Christian Theune)
Date: Wed, 02 Apr 2008 05:34:31 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207114471.69.0.97355642437.issue2513@psf.upfronthosting.co.za>


Changes by Christian Theune <ct at gocept.com>:


----------
nosy:  -ctheune

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

From report at bugs.python.org  Wed Apr  2 07:35:10 2008
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 02 Apr 2008 05:35:10 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207114510.46.0.196007894602.issue2513@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Humm, just saw the MSDN page Marc-Andre referred to, which indeed seems 
to indicate the Express edition doesn't support x64 cross-compilation 
*at all*.  AFAICT the latest Platform SDK (6.1) ships with an x64 cross 
compilation environment, but it's command line only, so unless there's 
a way to hook it up such that 'vcbuild' uses it with the Express 
edition as well -- it seems like you do need Standard edition or higher 
for x64 builds.

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

From report at bugs.python.org  Wed Apr  2 07:56:33 2008
From: report at bugs.python.org (James Henstridge)
Date: Wed, 02 Apr 2008 05:56:33 +0000
Subject: [issue2422] Automatically disable pymalloc when running under valgrind
In-Reply-To: <1205925069.41.0.603933745456.issue2422@psf.upfronthosting.co.za>
Message-ID: <1207115793.76.0.372335212105.issue2422@psf.upfronthosting.co.za>


James Henstridge <james at jamesh.id.au> added the comment:

There are probably a few other performance optimisations that would be
good to turn off when running under valgrind.

A big one is the tuple cache: if there are tuple reference counting
issues, they won't necessarily be seen by valgrind if the tuple is kept
and reused rather than being freed.

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

From report at bugs.python.org  Wed Apr  2 08:42:08 2008
From: report at bugs.python.org (Peter Otten)
Date: Wed, 02 Apr 2008 06:42:08 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207052027.28.0.27225375953.issue2527@psf.upfronthosting.co.za>
Message-ID: <1207118528.05.0.332732541321.issue2527@psf.upfronthosting.co.za>


Peter Otten <__peter__ at web.de> added the comment:

Alexander, I'm fine with a more specific argument name. ns was what 
the Timer already used internally.

Antoine, from __main__ import name1, ..., nameN works fine on the 
command line, but inside a function you'd have to declare the names 
you want to pass to the Timer as globals which I find a bit clumsy. 
Apart from giving a syntax warning a star-import affects the generated 
bytecode and produces the (slower) LOAD_NAME instead of LOAD_FAST.

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

From report at bugs.python.org  Wed Apr  2 09:37:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Apr 2008 07:37:18 +0000
Subject: [issue2533] Invalid TypeError with class method decorator and class
	method parameter
In-Reply-To: <1207103039.83.0.312467912668.issue2533@psf.upfronthosting.co.za>
Message-ID: <1207121838.61.0.524598318419.issue2533@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

First, your code does not compile: when compiling the DecorateMe class
body, the DecorateMe class does not yet exist, and
"callback=DecorateMe.callback" is an error!

And this explains your surprise: certainly there is a previous version
of a DecorateMe class in your module (or interactive session). This
other class has the same name, but it is still a different class, hence
the message.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Apr  2 11:42:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Apr 2008 09:42:44 +0000
Subject: [issue2532] file that breaks 2to3 (despite being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1207129364.85.0.0428297553655.issue2532@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Testing with a much simpler file ("a = 0\n" * 1000), there is a limit to
the number of statements in one file, around (sys.recursionlimit - 24).

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

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

From report at bugs.python.org  Wed Apr  2 11:42:44 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 02 Apr 2008 09:42:44 +0000
Subject: [issue2422] Automatically disable pymalloc when running under valgrind
In-Reply-To: <1207115793.76.0.372335212105.issue2422@psf.upfronthosting.co.za>
Message-ID: <47F35642.9090001@cheimes.de>


Christian Heimes <lists at cheimes.de> added the comment:

James Henstridge schrieb:
> James Henstridge <james at jamesh.id.au> added the comment:
> 
> There are probably a few other performance optimisations that would be
> good to turn off when running under valgrind.
> 
> A big one is the tuple cache: if there are tuple reference counting
> issues, they won't necessarily be seen by valgrind if the tuple is kept
> and reused rather than being freed.

The tuple cache can't be disabled entirely. Some parts of Python and
some third party modules may depend on the fact that an empty tuple ()
is a singleton in Python.

The tuple cache could be reduced to empty tuple and some other caches
like the list and dict cache could be disabled entirely.

Christian

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

From report at bugs.python.org  Wed Apr  2 11:47:48 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 02 Apr 2008 09:47:48 +0000
Subject: [issue2534] Speed up isinstance and issubclass
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements type.__instancecheck__ and type.__subclasscheck__,
which speeds up isinstance and issubclass calls quite a bit.

See also issue #2303.

Here are the performance figures for the current trunk version:

Current SNV trunk:

Using 2.6a1+ (trunk:62102, Apr  2 2008, 11:30:16) [MSC v.1500 32 bit
(Intel)]
isinstance(42, int)	   1000000 loops, best of 3: 0.28 usec per loop
isinstance(42, type)	   1000000 loops, best of 3: 0.974 usec per loop
issubclass(object, type)   1000000 loops, best of 3: 1.1 usec per loop
issubclass(object, int)    1000000 loops, best of 3: 1.1 usec per loop
issubclass(float, int)     1000000 loops, best of 3: 1.15 usec per loop

Current trunk, patch applied:

Using 2.6a1+ (trunk:62102M, Apr  2 2008, 11:21:32) [MSC v.1500 32 bit
(Intel)]
isinstance(42, int)	   1000000 loops, best of 3: 0.274 usec per loop
isinstance(42, type)	   1000000 loops, best of 3: 0.524 usec per loop
issubclass(object, type)   1000000 loops, best of 3: 0.661 usec per loop
issubclass(object, int)    1000000 loops, best of 3: 0.662 usec per loop
issubclass(float, int)     1000000 loops, best of 3: 0.731 usec per loop

Python 2.5.2, for comparison:

Using 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
isinstance(42, int)	   1000000 loops, best of 3: 0.292 usec per loop
isinstance(42, type)	   1000000 loops, best of 3: 0.417 usec per loop
issubclass(object, type)   1000000 loops, best of 3: 0.626 usec per loop
issubclass(object, int)    1000000 loops, best of 3: 0.648 usec per loop
issubclass(float, int)     1000000 loops, best of 3: 0.752 usec per loop

----------
files: type_instancecheck.diff
keywords: patch, patch
messages: 64842
nosy: theller
severity: normal
status: open
title: Speed up isinstance and issubclass
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file9924/type_instancecheck.diff

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

From report at bugs.python.org  Wed Apr  2 11:48:06 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 02 Apr 2008 09:48:06 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207129686.79.0.222045683442.issue2513@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Could somebody with a 64bit CPU please extend the PCbuild/README.txt? I
don't have the means to test 64bit builds or cross compilation of a
32bit build on a 64bit system. I only have 32bit CPUs at home.

+1 for nmake if you can get it to work.

A while ago I suggested to ship both 32bit and 64bit lib files with
every flavor of Python. With both library sets developers could cross
compile Windows extensions. Comments?

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

From report at bugs.python.org  Wed Apr  2 11:48:55 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 02 Apr 2008 09:48:55 +0000
Subject: [issue2303] isinstance is 4x as slow as in 2.5 because the common
	case raises
In-Reply-To: <1205682342.69.0.872031501346.issue2303@psf.upfronthosting.co.za>
Message-ID: <1207129735.9.0.908769169662.issue2303@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Issue #2534 has a patch which speeds up isinstance and issubclass by
implementing type.__instancecheck__ and type.__subclasscheck__.

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

From report at bugs.python.org  Wed Apr  2 12:40:04 2008
From: report at bugs.python.org (Matthias Kievernagel)
Date: Wed, 02 Apr 2008 10:40:04 +0000
Subject: [issue2535] duplicate Misc.lower
In-Reply-To: <1207132804.52.0.0603076560404.issue2535@psf.upfronthosting.co.za>
Message-ID: <1207132804.52.0.0603076560404.issue2535@psf.upfronthosting.co.za>


New submission from Matthias Kievernagel <mkiever at web.de>:

ron longo posted this remark in the Tkinter list:
>Don't know if this is the place to report this.  Not really a 
bug, >however,
>method lower() is defined twice in class Misc in the module 
Tkinter.py. 
>Both definitions are identical.

So I created a patch (against rev62104 which removes the first
occurrence which seems a bit out of order
(second one is grouped with raise).

Matthias.

----------
components: Tkinter
files: duplicateLower.patch
keywords: patch
messages: 64845
nosy: mkiever
severity: normal
status: open
title: duplicate Misc.lower
versions: Python 2.6
Added file: http://bugs.python.org/file9925/duplicateLower.patch

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

From report at bugs.python.org  Wed Apr  2 12:48:04 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 10:48:04 +0000
Subject: [issue2536] itertools.permutations docstring is misleading
In-Reply-To: <1207133284.49.0.529226014419.issue2536@psf.upfronthosting.co.za>
Message-ID: <1207133284.49.0.529226014419.issue2536@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu2 at users.sourceforge.net>:

Currently, Modules/itertoolsmodule.c lines 2471-2475 are:

PyDoc_STRVAR(permutations_doc,
"permutations(iterables[, r]) --> permutations object\n\
\n\
Return successive r-length permutations of elements in the iterable.\n\n\
permutations(range(4), 3) --> (0,1,2), (0,1,3), (0,2,3), (1,2,3)");

but that describes  behavior of itertools.combinations. The correct
example is in a comment on line 2254 of the same file:

'permutations(range(3), 2) --> (0,1) (0,2) (1,0) (1,2) (2,0) (2,1)'


I used "misleading" instead of "wrong" because the current docstring
does show a subset of the real output and could be said to be
incomplete. If that is the case, I suggest being explicit:

'permutations(range(4), 3) --> (0, 1, 2), (0, 1, 3), (0, 2, 1), (0, 2,
3), (0, 3, 1), (0, 3, 2), (1, 0, 2), (1, 0, 3), (1, 2, 0), (1, 2, 3),
(1, 3, 0), (1, 3, 2), (2, 0, 1), (2, 0, 3), (2, 1, 0), (2, 1, 3), (2, 3,
0), (2, 3, 1), (3, 0, 1), (3, 0, 2), (3, 1, 0), (3, 1, 2), (3, 2, 0),
(3, 2, 1)'

----------
components: Library (Lib)
messages: 64846
nosy: ajaksu2, rhettinger
severity: normal
status: open
title: itertools.permutations docstring is misleading
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  2 12:53:36 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 02 Apr 2008 10:53:36 +0000
Subject: [issue2510] Bazaar ignore file
In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za>
Message-ID: <1207133616.87.0.0265684531679.issue2510@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

the same is true for me.

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

From report at bugs.python.org  Wed Apr  2 13:11:15 2008
From: report at bugs.python.org (Matthias Kievernagel)
Date: Wed, 02 Apr 2008 11:11:15 +0000
Subject: [issue1602742] itemconfigure returns incorrect text property of text
	items
Message-ID: <1207134675.04.0.307726798965.issue1602742@psf.upfronthosting.co.za>


Matthias Kievernagel <mkiever at web.de> added the comment:

I no longer know what I meant with "document string is 
broken".
It is not very clear, but not broken.
It does not specify clearly the return value
in the case of 'without arguments'.

The problem is still present in trunk.
Problem is as far as I understand it:
Some return values from tcl are strings
that may contain spaces (or are even certain to contain 
spaces).
They are nonetheless translated to a Python tuple by
Tcl_SplitList in _tkinter.c.
There is no difference in syntax between tcl lists
and tcl strings (with spaces).
You have to have contextual knowledge to do the right thing.
This knowledge cannot be attached to itemconfigure alone
(for reconstitution of strings) because then information
about whitespace is already lost.
For return values known to be strings _tkinter/TkApp_SplitList
must not be used.

So I think it's a more general bug related to tcl string
return values.
Other Tkinter bugs may have the same explanation.
Don't know how to resolve this without a lot of work.

Matthias.

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

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

From report at bugs.python.org  Wed Apr  2 14:13:09 2008
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 02 Apr 2008 12:13:09 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207138389.96.0.636845368965.issue2513@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Christian, regarding shipping x64 .lib files as well as 32-bit ones -- 
sensible idea, but where would we place the x64 version libs?  In Python
[xx]\libs\amd64?  (This would mirror the approach used with PCbuild and 
PCbuild\amd64 -- although there's currently an ongoing discussion on 
this topic in python-dev.)

With regards to updating PCbuild/readme.txt, I'm planning on doing that 
by EOD today.

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

From report at bugs.python.org  Wed Apr  2 14:23:45 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 12:23:45 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207139025.65.0.642897966245.issue2525@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

This patch updates the behavior as per "The Energy Policy Act of 2005":

      Start: Second Sunday in March
          End: First Sunday in November
          Time: 2 am local time

----------
keywords: +patch
nosy: +ajaksu2
Added file: http://bugs.python.org/file9926/tzinfo-examples.patch

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

From report at bugs.python.org  Wed Apr  2 15:08:47 2008
From: report at bugs.python.org (Shawn Morel)
Date: Wed, 02 Apr 2008 13:08:47 +0000
Subject: [issue2444] Adding __iter__ to class Values of module optparse
In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za>
Message-ID: <1207141727.86.0.829053679893.issue2444@psf.upfronthosting.co.za>


Shawn Morel <shawn at technosmores.com> added the comment:

gpolo: The argument still doesn't hold. As you point out, it's the 
Values class output from __str__ and other behaviour that is being un-
pythonic and leading you to believe it's a dictionary. Adding the 
__itter__ method would only make this worse. Then someone else would 
surely ask to have another __*__ method added since dictionaries support 
it but values don't.

The question then is one for optik. Why doesn't values simply inherit 
from dict and why does it insist on using __setattr__ rather than 
actually behaving completely like a dictionary. I know I was completely surprised by the following:

>>> (opts, args) = parser.parse_args(values={})
>>> print opts
{}
>>>

----------
nosy: +shawnmorel

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

From report at bugs.python.org  Wed Apr  2 15:14:28 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 02 Apr 2008 13:14:28 +0000
Subject: [issue2444] Adding __iter__ to class Values of module optparse
In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za>
Message-ID: <1207142068.61.0.205927391296.issue2444@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I have asked that myself, shawnmore. Why not let Value subclass dict ?

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

From report at bugs.python.org  Wed Apr  2 15:17:18 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 02 Apr 2008 13:17:18 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1207142237.97.0.704394599034.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Agreed that section of the docs should be more explicit in pointing out
that __getattr__ and __getattribute__ won't work for proxying special
methods for new-style classes.

It's also true that there are quite a few special methods where nothing
special is needed to correctly proxy the methods. That said, defining
all of the methods blindly is also bad (as a lot of informal type
testing is done by checking for certain special methods as attributes).

Perhaps it would be useful to have a method on type instances that could
be explicitly invoked to tell the type to run through all the tp_* slots
and populate them based on doing getattr(self, "__slotname__").

(Note that it's only those methods with dedicated slots in the C type
structure that are a problem here - those which are implemented solely
as normal Python methods like __enter__, __exit__ or the pickle module's
special methods can typically be overridden as expected through the use
of __getattr__ and __getattribute__)

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

From report at bugs.python.org  Wed Apr  2 15:32:23 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 02 Apr 2008 13:32:23 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1207143143.19.0.202455201751.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I've started a discussion on the Py3k development list regarding the
possibility of adding a new method to type to aid in converting proxy
classes from classic- to new-style.

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

From report at bugs.python.org  Wed Apr  2 15:47:26 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 02 Apr 2008 13:47:26 +0000
Subject: [issue2531] float compared to decimal is silently incorrect.
In-Reply-To: <1207087897.38.0.261389881483.issue2531@psf.upfronthosting.co.za>
Message-ID: <1207144046.3.0.123322577916.issue2531@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Which version of 2.4 are you talking about?

This line in the tests...

  self.assertNotEqual(da, 32.7)

is there since almost 4 years ago (release 36325, and 2.4 is tagged in
release 37906).

Anyway, this behaviour is ok, as is the following:

>>> 2 < "1.9"
True

----------
keywords: +easy -patch
nosy: +facundobatista
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  2 15:59:51 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 13:59:51 +0000
Subject: [issue2210] Nested module import clutters package namespace
In-Reply-To: <1204286639.84.0.689580155696.issue2210@psf.upfronthosting.co.za>
Message-ID: <1207144791.23.0.0672784045608.issue2210@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

Not a bug IMHO, but a gotcha. Change x.py to "from pack import y as q"
and you get the desired result. Check
http://effbot.org/zone/import-confusion.htm

----------
nosy: +ajaksu2

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

From report at bugs.python.org  Wed Apr  2 16:01:25 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 02 Apr 2008 14:01:25 +0000
Subject: [issue2527] Pass a namespace to timeit
In-Reply-To: <1207118528.05.0.332732541321.issue2527@psf.upfronthosting.co.za>
Message-ID: <d38f5330804020701n57ac61fbt2089dd1d189ec952@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 2, 2008 at 2:42 AM, Peter Otten <report at bugs.python.org> wrote:

>  Alexander, I'm fine with a more specific argument name. ns was what
>  the Timer already used internally.
>

Maybe it should be "locals" after all.  It does not look like the
conflict with builtin locals() is an issue.  Note that this is what
__import__ uses.  I still recommend adding globals argument as well
for completeness and more accurate timings when timed code uses
globals.

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

From report at bugs.python.org  Wed Apr  2 16:13:41 2008
From: report at bugs.python.org (Alain Spineux)
Date: Wed, 02 Apr 2008 14:13:41 +0000
Subject: [issue1733757] RuntimeWarning: tp_compare didn't return -1 or -2
Message-ID: <1207145621.69.0.810790965802.issue1733757@psf.upfronthosting.co.za>


Alain Spineux <alain.spineux at gmail.com> added the comment:

This has chnaged with python-2.5.2.
runing python openpkg under linux centos-5.1, 
the test case case4.py don't give any error message anymore, but
still block like with 2.5.1:
# strace -p 937
Process 937 attached - interrupt to quit
futex(0x9b9cc78, FUTEX_WAIT, 0, NULL

Hope this help

----------
nosy: +aspineux
title: RuntimeWarning: tp_compare didn't return -1 or -2  -> RuntimeWarning: tp_compare didn't return -1 or -2

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

From report at bugs.python.org  Wed Apr  2 17:06:09 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 02 Apr 2008 15:06:09 +0000
Subject: [issue2534] Speed up isinstance and issubclass
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1207148769.76.0.759041191465.issue2534@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

I find similar speedups:

isinstance(42, int)       -2%
isinstance(42, type)      45%
isinstance(object, type)  -1%
isinstance(object, int)   42%
isinstance(float, int)    44%

(both negative ones are actually lower than original, but so low that it
could be considered timing glitches)

However, also I have an error in the test_exceptions.py suite:
facundo at pomcat:~/devel/reps/python/trunk$ ./python
Lib/test/test_exceptions.py
testAttributes (__main__.ExceptionTests) ... ok
testInfiniteRecursion (__main__.ExceptionTests) ... FAIL
testKeywordArgs (__main__.ExceptionTests) ... ok
testRaising (__main__.ExceptionTests) ... ok
testReload (__main__.ExceptionTests) ... ok
testSettingException (__main__.ExceptionTests) ... ok
testSlicing (__main__.ExceptionTests) ... ok
testSyntaxErrorMessage (__main__.ExceptionTests) ... ok
testUnicodeStrUsage (__main__.ExceptionTests) ... ok
test_WindowsError (__main__.ExceptionTests) ... ok

======================================================================
FAIL: testInfiniteRecursion (__main__.ExceptionTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "Lib/test/test_exceptions.py", line 336, in testInfiniteRecursion
    self.assertRaises(RuntimeError, g)
AssertionError: RuntimeError not raised

----------------------------------------------------------------------
Ran 10 tests in 0.031s

FAILED (failures=1)
Traceback (most recent call last):
  File "Lib/test/test_exceptions.py", line 351, in <module>
    test_main()
  File "Lib/test/test_exceptions.py", line 348, in test_main
    run_unittest(ExceptionTests)
  File "/home/facundo/devel/reps/python/trunk/Lib/test/test_support.py",
line 577, in run_unittest
    _run_suite(suite)
  File "/home/facundo/devel/reps/python/trunk/Lib/test/test_support.py",
line 560, in _run_suite
    raise TestFailed(err)
test.test_support.TestFailed: Traceback (most recent call last):
  File "Lib/test/test_exceptions.py", line 336, in testInfiniteRecursion
    self.assertRaises(RuntimeError, g)
AssertionError: RuntimeError not raised

----------
nosy: +facundobatista

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

From report at bugs.python.org  Wed Apr  2 17:07:43 2008
From: report at bugs.python.org (Trent Nelson)
Date: Wed, 02 Apr 2008 15:07:43 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207148863.75.0.15516419293.issue2513@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Updated PCbuild/readme.txt in r62105 and r62106 for trunk and py3k
respectively.

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

From report at bugs.python.org  Wed Apr  2 17:33:03 2008
From: report at bugs.python.org (Nick Guenther)
Date: Wed, 02 Apr 2008 15:33:03 +0000
Subject: [issue2529] list/generator comprehension parser doesn't match spec
In-Reply-To: <1207077549.89.0.118557412226.issue2529@psf.upfronthosting.co.za>
Message-ID: <1207150383.23.0.188261578637.issue2529@psf.upfronthosting.co.za>


Nick Guenther <kousu at users.sourceforge.net> added the comment:

Oh, okay. That's really confusing because I expect "in" to always return
a bool, but in the spirit of python there's no reason it should I guess.

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

From report at bugs.python.org  Wed Apr  2 17:34:30 2008
From: report at bugs.python.org (Steven Bethard)
Date: Wed, 02 Apr 2008 15:34:30 +0000
Subject: [issue2444] Adding __iter__ to class Values of module optparse
In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za>
Message-ID: <1207150470.41.0.456486068876.issue2444@psf.upfronthosting.co.za>


Steven Bethard <steven.bethard at gmail.com> added the comment:

Subclassing dict seems like a bad idea. The options value returned by
.parse_args() is not supposed to be dict-like, it's supposed to be
object-like. That is, the natural way of accessing values from it is
through dotted attribute access, not dict-indexing access. All the
documentation for the module makes this clear. Giving it both attribute
access and dict-indexing access would violate TOOWTDI. The One Obvious
way to get dict-indexing access from an attribute oriented object is
already vars().

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

From report at bugs.python.org  Wed Apr  2 17:34:46 2008
From: report at bugs.python.org (Collin Winter)
Date: Wed, 02 Apr 2008 15:34:46 +0000
Subject: [issue2532] file that breaks 2to3 (despite being correct python)
In-Reply-To: <1207095014.88.0.392837207981.issue2532@psf.upfronthosting.co.za>
Message-ID: <1207150486.69.0.705300699511.issue2532@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Yes, this is a known problem with the pattern matching system.

----------
priority:  -> normal

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

From report at bugs.python.org  Wed Apr  2 17:37:50 2008
From: report at bugs.python.org (Karen Tracey)
Date: Wed, 02 Apr 2008 15:37:50 +0000
Subject: [issue1555570] email parser incorrectly breaks headers with a CRLF at
	8192
Message-ID: <1207150670.35.0.572485002245.issue1555570@psf.upfronthosting.co.za>


Karen Tracey <kmtracey at gmail.com> added the comment:

Opening the file in universal newline mode doesn't work for cases where
the 'file' contains multipart MIME data (eg. multipart/form-data) where
one of the included parts is binary data (eg. application/octet-stream).
 In that case, blind translation of CRLF to LF may corrupt the binary
data.  (Thanks to Thomas Guettler for pointing that out to me.)

FeedParser goes to considerable trouble to split on any conceivable line
boundary but retain whatever line boundary existed in the stream when
putting things back together.  (Look at BufferedSubFile's push() code in
feedparser.py.)  It was not written on the assumption that it would be
getting LFs only.  

The only code that knows enough to know which CRLFs are really line
breaks is the code that is breaking the stream up based on the boundary
markers -- that is the FeedParser code.  It isn't safe for the caller to
do any CRLF conversions before calling the Parser.  Therefore I believe
the fix needs to be made to the parser.py code, not the docs.

Two people that I know of independently re-discovered this bug in the
last couple of weeks (running Django), after I re-discovered it about
three months ago after Jeremy Dunck re-discovered it a year earlier,
three months after it was originally opened.  Maybe a corner case, but
it would be nice, since it is quite difficult for people to track down,
and the fix is so trivial, if the fix could be put in.

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

From report at bugs.python.org  Wed Apr  2 19:36:06 2008
From: report at bugs.python.org (Jason Orendorff)
Date: Wed, 02 Apr 2008 17:36:06 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>


New submission from Jason Orendorff <jason.orendorff at gmail.com>:

Below, the second regexp seems just as guilty as the first to me.

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 re
>>> re.compile(r'((x|y)*)*')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py",
line 180, in compile
    return _compile(pattern, flags)
  File
"/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/re.py",
line 233, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat
>>> re.compile(r'((x|y+)*)*')
<_sre.SRE_Pattern object at 0x18548>

I don't know if that error is to protect the sre engine from bad
patterns or just a courtesy to users.  If the former, it could be a
serious bug.

----------
messages: 64865
nosy: jorendorff
severity: normal
status: open
title: re.compile(r'((x|y+)*)*') should fail
versions: Python 2.6

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

From report at bugs.python.org  Wed Apr  2 19:42:25 2008
From: report at bugs.python.org (Christoph Burgmer)
Date: Wed, 02 Apr 2008 17:42:25 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207158145.11.0.790103659567.issue2517@psf.upfronthosting.co.za>


Christoph Burgmer <cburgmer at ira.uka.de> added the comment:

JFTR:
> print unicode(e.message).encode("utf-8")
only works for Python 2.5, not downwards.

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

From report at bugs.python.org  Wed Apr  2 19:43:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 02 Apr 2008 17:43:40 +0000
Subject: [issue1733757] RuntimeWarning: tp_compare didn't return -1 or -2
Message-ID: <1207158220.65.0.198328200717.issue1733757@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The "funny" errors around trace & exceptions have been corrected with
issue1265.

The remaining problem is a livelock: when the interpreter exits, 
threading.Thread.__delete is called, and this calls
"_active_limbo_lock.acquire".

But the sys.settrace is still enabled... and threading.currentThread()
can also call "_active_limbo_lock.acquire" when the main thread cannot
be found...

A solution could be to clear sys.settrace when closing the interpreter.

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

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

From report at bugs.python.org  Wed Apr  2 20:08:00 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Apr 2008 18:08:00 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207159680.18.0.646160723035.issue2525@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hi Daniel,

Can you change it so that the start and end values are chosen
dynamically based on the year?  I.e. if year < 2007 use the old values
otherwise use the new ones.  A tzinfo object is supposed to (within
reason) handle historical times accurately.

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

From report at bugs.python.org  Wed Apr  2 20:37:43 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 18:37:43 +0000
Subject: [issue2534] Speed up isinstance and issubclass
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1207161463.53.0.473940633223.issue2534@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

The test fails on this:

def g():
    try:
        return g()
    except ValueError:
        return -1
self.assertRaises(RuntimeError, g)


Changing that "return -1" to "return sys.exc_info()" shows that a
RuntimeError was raised indeed. Also, using TypeError or TabError
instead of ValueError gives the same result.

Shallow testing of the new methods seem to show normal results,

[Runtime,Value]Error.__[subclass,instance]check__([Runtime,Value]Error)

is False for cross-checks and True otherwise.

----------
nosy: +ajaksu2

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

From report at bugs.python.org  Wed Apr  2 20:47:18 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 02 Apr 2008 18:47:18 +0000
Subject: [issue2534] Speed up isinstance and issubclass
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1207162038.42.0.208443122783.issue2534@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Running Daniels code interactively, with a debug build on Windows,
additionally prints 'XXX undetected error' before the Runtime error is
raised.

I cannot see anything that is wrong with my code.  Maybe this, and the
test failure, has to do with the fact that the new
'type___subclasscheck__' function is sometimes called with the error
indicator already set?  Maybe some PyErr_Fetch() and PyErr_Restore()
calls are needed inside this function, similar to what
PyObject_IsSubclass() does?  I must admit that I do not really
understand the purpose of these calls...

Anyway, I attach a new, cleaner patch although this one still behaves in
the same, buggy, way: type_instancecheck-2.diff.

Added file: http://bugs.python.org/file9927/type_instancecheck-2.diff

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

From report at bugs.python.org  Wed Apr  2 20:56:23 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 02 Apr 2008 18:56:23 +0000
Subject: [issue2444] Adding __iter__ to class Values of module optparse
In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za>
Message-ID: <1207162583.68.0.742767845889.issue2444@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Given the disagreement found here, I suggest closing this rfe and moving
further discussions to c.l.p.
Thanks djc and rhettinger for your support, and, bethard and shawnmorel
for your different p.o.v.

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

From report at bugs.python.org  Wed Apr  2 21:30:13 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 19:30:13 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207164613.05.0.14730358737.issue2525@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

That was a such silly mistake, sorry :)

Updated patch tries to keep the old behavior, but I just found out it's
mostly wrong too (DST start and end days changed a bit in the last 80
years).

>From http://aa.usno.navy.mil/faq/docs/daylight_time.php (quoted below),
I believe the best correctness/simplicity compromise would be:

 1966-1986: from the last Sunday in April to the last Sunday in October
1987-2006: from the first  Sunday in April to the last Sunday in October
2007-: from the last Sunday in March  to the second Sunday in November

Should I try it like that? Or would more attention to detail be better?

quote:
"Although standard time in time zones was instituted in the U.S. and
Canada by the railroads in 1883, it was not established in U.S. law
until the Act of March 19, 1918, sometimes called the Standard Time Act.
The act also established daylight saving time, a contentious idea then.
Daylight saving time was repealed in 1919, but standard time in time
zones remained in law. Daylight time became a local matter. It was
re-established nationally early in World War II, and was continuously
observed from 9 February 1942 to 30 September 1945. After the war its
use varied among states and localities. The Uniform Time Act of 1966
provided standardization in the dates of beginning and end of daylight
time in the U.S. but allowed for local exemptions from its observance.
The act provided that daylight time begin on the last Sunday in April
and end on the last Sunday in October, with the changeover to occur at 2
a.m. local time.

During the "energy crisis" years, Congress enacted earlier starting
dates for daylight time. In 1974, daylight time began on 6 January and
in 1975 it began on 23 February. After those two years the starting date
reverted back to the last Sunday in April. In 1986, a law was passed
that shifted the starting date of daylight time to the first Sunday in
April, beginning in 1987. The ending date of daylight time was not
subject to such changes, and remained the last Sunday in October. The
Energy Policy Act of 2005 changed both the starting and ending dates.
Beginning in 2007, daylight time starts on the second Sunday in March
and ends on the first Sunday in November."

Added file: http://bugs.python.org/file9928/tzinfo-examples2.patch

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

From report at bugs.python.org  Wed Apr  2 21:31:28 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 19:31:28 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207164688.84.0.0128115566511.issue2525@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

Er...
2007- : from the second Sunday in March to the first Sunday in November.

:/

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

From report at bugs.python.org  Wed Apr  2 21:11:33 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 19:11:33 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207163493.19.0.570847668357.issue2525@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu2 at users.sourceforge.net>:


Removed file: http://bugs.python.org/file9926/tzinfo-examples.patch

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

From report at bugs.python.org  Wed Apr  2 21:50:08 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 02 Apr 2008 19:50:08 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207164688.84.0.0128115566511.issue2525@psf.upfronthosting.co.za>
Message-ID: <ca471dc20804021250j6e6c1229jff92f5a9866c9fd0@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

I'd be okay with only covering 1987 and later. But it's probably good
to have a table-based solution anway, to make it easy to handle future
changes -- I'm sure 2007 is not the last year this is changing. :-)

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

From report at bugs.python.org  Wed Apr  2 22:13:15 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 02 Apr 2008 20:13:15 +0000
Subject: [issue2534] Speed up isinstance and issubclass
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1207167195.85.0.921951767671.issue2534@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

Thomas: I confirm your patch triggers this behavior.  I can reliably get
a __subclasscheck__ error by trying to "import sys" after the bogus
catching happens:

>>> def g():
...   try:
...     return g()
...   except ValueError:
...     return sys.exc_info()
...
>>> g()
(<type 'exceptions.RuntimeError'>, 'maximum recursion depth exceeded
while calling a Python object', <traceback object at 0xb7d9ba04>)
>>> import sys
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded in __subclasscheck__

I hope this helps...

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

From report at bugs.python.org  Wed Apr  2 22:57:54 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Apr 2008 20:57:54 +0000
Subject: [issue2517] Error when printing an exception containing a Unicode
	string
In-Reply-To: <1206918832.8.0.542354120577.issue2517@psf.upfronthosting.co.za>
Message-ID: <1207169874.3.0.882154740257.issue2517@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

We can't do much about that because only security fixes are backported
to version < 2.5.

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

From report at bugs.python.org  Wed Apr  2 23:00:08 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 02 Apr 2008 21:00:08 +0000
Subject: [issue2424] Logging module hides user code errors (bare except)
In-Reply-To: <1205945727.95.0.106408430921.issue2424@psf.upfronthosting.co.za>
Message-ID: <1207170008.12.0.465344688587.issue2424@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This has already been fixed in trunk.

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

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

From report at bugs.python.org  Wed Apr  2 23:12:55 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 02 Apr 2008 21:12:55 +0000
Subject: [issue2316] TimedRotatingFileHandler names files incorrectly if
	nothing is logged during an interval
In-Reply-To: <1205741875.35.0.669932771172.issue2316@psf.upfronthosting.co.za>
Message-ID: <1207170775.73.0.591498494169.issue2316@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Updated SVN, but not backported to 2.5 or earlier maintenance branches.

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

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

From report at bugs.python.org  Wed Apr  2 23:11:58 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 02 Apr 2008 21:11:58 +0000
Subject: [issue2317] TimedRotatingFileHandler logic for removing files wrong
In-Reply-To: <1205742576.84.0.607022841001.issue2317@psf.upfronthosting.co.za>
Message-ID: <1207170718.38.0.962265114095.issue2317@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Updated SVN, but not backported to 2.5 or earlier maintenance branches.

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

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

From report at bugs.python.org  Wed Apr  2 23:13:27 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 02 Apr 2008 21:13:27 +0000
Subject: [issue2315] TimedRotatingFileHandler does not account for daylight
	savings time
In-Reply-To: <1205740809.7.0.649649150956.issue2315@psf.upfronthosting.co.za>
Message-ID: <1207170807.8.0.179761646759.issue2315@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Updated SVN, but not backported to 2.5 or earlier maintenance branches.

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

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

From report at bugs.python.org  Wed Apr  2 23:10:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 02 Apr 2008 21:10:49 +0000
Subject: [issue2444] Adding __iter__ to class Values of module optparse
In-Reply-To: <1206114097.48.0.657635538411.issue2444@psf.upfronthosting.co.za>
Message-ID: <1207170648.95.0.456059981259.issue2444@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Closing on OP's request.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Wed Apr  2 23:15:36 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Wed, 02 Apr 2008 21:15:36 +0000
Subject: [issue2318] TimedRotatingFileHandler: rotate every month,
	or every year
In-Reply-To: <1205742779.64.0.634680353877.issue2318@psf.upfronthosting.co.za>
Message-ID: <1207170936.91.0.143927170862.issue2318@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

I'm not sure how much of a need there is for this, and I don't have much
think time I can devote to it, but I'll be happy to consider a patch ;-)

----------
resolution:  -> later
status: open -> closed

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

From report at bugs.python.org  Thu Apr  3 00:03:58 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Wed, 02 Apr 2008 22:03:58 +0000
Subject: [issue2507] Exception state lives too long in 3.0
In-Reply-To: <1206800918.45.0.478667091266.issue2507@psf.upfronthosting.co.za>
Message-ID: <1207173838.02.0.8075745112.issue2507@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Knocking the priority down to critical for the next alpha release.  This
can be readdressed once the release is made.

----------
nosy: +barry
priority: release blocker -> critical

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

From report at bugs.python.org  Thu Apr  3 01:39:16 2008
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 02 Apr 2008 23:39:16 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207179556.62.0.434827925195.issue2513@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I'd like to keep this issue specifically about cross-compilation in the
current tree, and while some of the other ideas may have merit, let's
not bog this issue down with them unless they directly impact the patch.

Does anyone have any comments or concerns about my patch?  Anything
people would like to see changed before I check it in?

Martin - my patch creates a new executable in Lib\distutils\command, and
IMO it should be included in binary builds for all windows platforms. 
Is there something I should change in the MSI process?

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

From report at bugs.python.org  Thu Apr  3 02:18:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Apr 2008 00:18:44 +0000
Subject: [issue1561] py3k: test_mailbox fails on Windows
In-Reply-To: <1196937492.24.0.0620025474702.issue1561@psf.upfronthosting.co.za>
Message-ID: <1207181924.18.0.391740062877.issue1561@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Applied 2nd solution as r61951

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

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

From report at bugs.python.org  Thu Apr  3 02:26:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Apr 2008 00:26:22 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>


New submission from Amaury Forgeot d'Arc <amauryfa at gmail.com>:

Bytes should be immutable, but in test_socket.py:
    buf = b" "*1024
    nbytes = self.cli_conn.recv_into(buf)

This patch attempts to enforce readonly buffer on bytes

----------
components: Interpreter Core
files: buffer.patch
keywords: patch
messages: 64886
nosy: amaury.forgeotdarc
severity: normal
status: open
title: memoryview of bytes is not readonly
versions: Python 3.0
Added file: http://bugs.python.org/file9929/buffer.patch

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

From report at bugs.python.org  Thu Apr  3 03:17:53 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 03 Apr 2008 01:17:53 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1207185473.49.0.344611868777.issue2538@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Thu Apr  3 04:16:26 2008
From: report at bugs.python.org (Jason)
Date: Thu, 03 Apr 2008 02:16:26 +0000
Subject: [issue2539] Windows Registry issue with 2.5.2 AMD64 msi
In-Reply-To: <1207188986.33.0.533862298048.issue2539@psf.upfronthosting.co.za>
Message-ID: <1207188986.33.0.533862298048.issue2539@psf.upfronthosting.co.za>


New submission from Jason <iggyboo at bestmail.us>:

I have tried multiple times and even checking manually, but the
Python 2.5.2 AMD64 msi installer does not register Python correctly, or
it doesn't enter it into the registry correctly.  I'm not sure.  I
install it after uninstalling 2.5.1 and and when I try to install
wxPython2.8 and pygtk-2.10.6 both give me an error that they cannot find
Python or its path in the registry.  I reinstall 2.5.1 and it all works
perfectly.  I'm using all default selections and just clicking
"Next,Next,Next, etc."

----------
components: Installation
messages: 64887
nosy: iggyboo
severity: normal
status: open
title: Windows Registry issue with 2.5.2 AMD64 msi
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr  3 06:00:32 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 03 Apr 2008 04:00:32 +0000
Subject: [issue2540] If HAVE_LONG_LONG is not defined,
	longval will not be initialized (_sqlite)
In-Reply-To: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>
Message-ID: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

I noticed compiler warned "'longval' is not used anywhere."
And I found 'longval' was not initialized where HAVE_LONG_LONG
was not defined. Is attached patch intended behavior? Thanks.

----------
components: Extension Modules
files: fix.patch
keywords: easy, patch, patch
messages: 64888
nosy: ocean-city
severity: normal
status: open
title: If HAVE_LONG_LONG is not defined, longval will not be initialized (_sqlite)
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9930/fix.patch

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

From report at bugs.python.org  Thu Apr  3 06:02:28 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 03 Apr 2008 04:02:28 +0000
Subject: [issue2540] If HAVE_LONG_LONG is not defined,
	longval will not be initialized (_sqlite)
In-Reply-To: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>
Message-ID: <1207195348.79.0.931546385555.issue2540@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

Oh, I forgot this. When I debuged with
#undef HAVE_LONG_LONG
I noticed test_sqlite.py failed with this error message.

======================================================================
ERROR: CheckLargeInt (sqlite3.test.types.SqliteTypeTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\sqlite3\test\types.py", line 52, in
CheckLargeInt

    self.cur.execute("insert into test(i) values (?)", (num,))
OverflowError: Python int too large to convert to C long

======================================================================
ERROR: CheckLargeInt (sqlite3.test.types.DeclTypesTests)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "e:\python-dev\py3k\lib\sqlite3\test\types.py", line 146, in
CheckLargeIn
t
    self.cur.execute("insert into test(i) values (?)", (num,))
OverflowError: Python int too large to convert to C long

Maybe some fix for test is needed?

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

From report at bugs.python.org  Thu Apr  3 06:14:49 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Thu, 03 Apr 2008 04:14:49 +0000
Subject: [issue2540] If HAVE_LONG_LONG is not defined,
	longval will not be initialized (_sqlite)
In-Reply-To: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>
Message-ID: <1207196089.06.0.0709999942356.issue2540@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


----------
keywords:  -easy

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

From report at bugs.python.org  Thu Apr  3 06:19:06 2008
From: report at bugs.python.org (John Millikin)
Date: Thu, 03 Apr 2008 04:19:06 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

According to
<http://docs.python.org/dev/3.0/reference/lexical_analysis.html#id9>,
raw strings with \u and \U escape sequences should have these sequences
parsed as usual. However, they are currently escaped.

>>> r'\u0020'
'\\u0020'

Expected:
>>> r'\u0020'
' '

----------
components: Unicode
messages: 64890
nosy: jmillikin
severity: normal
status: open
title: Unicode escape sequences not parsed in raw strings.
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Apr  3 09:01:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Apr 2008 07:01:40 +0000
Subject: [issue2539] Windows Registry issue with 2.5.2 AMD64 msi
In-Reply-To: <1207188986.33.0.533862298048.issue2539@psf.upfronthosting.co.za>
Message-ID: <1207206100.5.0.212638703532.issue2539@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Do you perform a per-user or per-machine installation?

When you look at the Python registry keys, which ones get written?

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

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

From report at bugs.python.org  Thu Apr  3 09:09:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 03 Apr 2008 07:09:53 +0000
Subject: [issue2540] If HAVE_LONG_LONG is not defined,
	longval will not be initialized (_sqlite)
In-Reply-To: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>
Message-ID: <1207206593.48.0.863469240556.issue2540@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Gerhard, what do you think?

----------
assignee:  -> ghaering
nosy: +ghaering, loewis

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

From report at bugs.python.org  Thu Apr  3 10:08:59 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Thu, 03 Apr 2008 08:08:59 +0000
Subject: [issue2540] If HAVE_LONG_LONG is not defined,
	longval will not be initialized (_sqlite)
In-Reply-To: <1207195232.04.0.450444474106.issue2540@psf.upfronthosting.co.za>
Message-ID: <1207210139.34.0.33958054715.issue2540@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

My problem is that I can't really test (better than #undefining
HAVE_LONG_LONG) this, because I have no platform to test on that doesn't
have long longs.

I'm not even sure SQLite *really* works when there is no 64-bit type.
I'll ask on the SQLite mailing list. If that is so, then I'd like to get
rid of the superfluous #ifdefs.

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

From report at bugs.python.org  Thu Apr  3 11:08:35 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 09:08:35 +0000
Subject: [issue2534] Speed up isinstance and issubclass
In-Reply-To: <1207129668.4.0.43832609305.issue2534@psf.upfronthosting.co.za>
Message-ID: <1207213715.11.0.822674556828.issue2534@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Problem found.  See issue #2542, which contains a patch that fixes the
failure in test_exceptions; this test now additionally prints

  Exception RuntimeError: 'maximum recursion depth exceeded in
    __subclasscheck__' in <type 'exceptions.RuntimeError'> ignored
  Exception RuntimeError: 'maximum recursion depth exceeded while
    calling a Python object' in <type 'exceptions.RuntimeError'> ignored

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

From report at bugs.python.org  Thu Apr  3 10:59:00 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 08:59:00 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

PyErr_ExceptionMatches must not fail, according to the docs.  So an
error code from PyObject_IsSubclass() cannot be returned.

The attached patch calls PyErr_WriteUnraisable in this case, and returns
an arbitrary value (0 was chosen in the patch).

See also issue #2534.

----------
components: Interpreter Core
files: errors.diff
keywords: patch, patch
messages: 64894
nosy: theller
severity: normal
status: open
title: PyErr_ExceptionMatches must not fail
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9931/errors.diff

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

From report at bugs.python.org  Thu Apr  3 14:13:58 2008
From: report at bugs.python.org (djc)
Date: Thu, 03 Apr 2008 12:13:58 +0000
Subject: [issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails
Message-ID: <1207224838.72.0.986978535625.issue1424152@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +djc

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

From report at bugs.python.org  Thu Apr  3 14:54:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Apr 2008 12:54:50 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207227290.21.0.731324242142.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

You use the "ur" string mode.

>>> print ur"\u0020"
" "

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Thu Apr  3 15:15:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Apr 2008 13:15:01 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207228501.85.0.984522915147.issue2541@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, it's about python 3.0. I confirm the problem, and propose a patch:

--- Python/ast.c.original       2008-04-03 15:12:15.548389400 +0200
+++ Python/ast.c        2008-04-03 15:12:28.359475800 +0200
@@ -3232,7 +3232,7 @@
             return NULL;
         }
     }
-    if (!*bytesmode && !rawmode) {
+    if (!*bytesmode) {
         return decode_unicode(s, len, rawmode, encoding);
     }
     if (*bytesmode) {

----------
nosy: +amaury.forgeotdarc
resolution: invalid -> 
status: closed -> open

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

From report at bugs.python.org  Thu Apr  3 15:22:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Apr 2008 13:22:52 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207228972.72.0.643786643263.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for noticing, Amaury, and your patch works for me.

----------
priority:  -> critical

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

From report at bugs.python.org  Thu Apr  3 17:51:15 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Thu, 03 Apr 2008 15:51:15 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1207237875.11.0.615915047809.issue2542@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

The tests pass and prints the ignores. But I still see an issue:

import sys
def g():
    try:
        return g()
    except:
        return sys.exc_info()
>>> g()
(<type 'exceptions.RuntimeError'>, 'maximum recursion depth exceeded
while calling a Python object', <traceback object at 0xb7d3d75c>)
>>> import sys
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: maximum recursion depth exceeded

Then, I can raise that RuntimeError and clear things:

>>> sys.excepthook(*g())
Traceback (most recent call last):
  File "<stdin>", line 3, in g
RuntimeError: maximum recursion depth exceeded while calling a Python object
>>> import sys
>>> 

The attached patch adds a test for this condition, I hope someone more
test-savvy than I can review it.

----------
nosy: +ajaksu2
Added file: http://bugs.python.org/file9932/test_exceptions.diff

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

From report at bugs.python.org  Thu Apr  3 18:27:41 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Apr 2008 16:27:41 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207240061.31.0.608001462652.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r62128.

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

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

From report at bugs.python.org  Thu Apr  3 19:39:03 2008
From: report at bugs.python.org (roudkerk)
Date: Thu, 03 Apr 2008 17:39:03 +0000
Subject: [issue2475] Popen.poll always returns None
In-Reply-To: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za>
Message-ID: <1207244343.46.0.112571954585.issue2475@psf.upfronthosting.co.za>


roudkerk <r.m.oudkerk at gmail.com> added the comment:

The problem is that os.wait() does not play nicely with subprocess.py.
Popen.poll() and Popen.wait() use os.waitpid(pid, ...)  which will
raise OSError if pid has already been reported by os.wait().
Popen.poll() swallows OSError and by default returns None.

You can (sort of) fix your program by using
"p.popen(_deadstate='dead')" in place of "p.popen()".  This will make
poll() return 'dead' instead of None if OSError gets caught, but this
is undocumented.

Maybe a subprocess.wait() function could be added which would return a
tuple

    (pid, exitcode, popen_object)

where popen_object is None if the process is "foreign" (i.e. it was
not created by the subprocess module).

It would not be hard to implement this on unix if you don't care about
thread safety.  (On unix Popen.wait() is not thread-safe either, so
maybe thread safety does not matter.)

To implement something similar on windows you would probably need to
use WaitForMultipleObjects() to check whether any process handles are
signalled, but that would involve patching _subprocess.c or using
ctypes or pywin32.

----------
nosy: +roudkerk

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

From report at bugs.python.org  Thu Apr  3 21:46:48 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 03 Apr 2008 19:46:48 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1207252008.63.0.427411744855.issue2516@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I am uploading another work in progress patch because the problem proved
to be more difficult than I thought in the beginning.  The new patch
addresses two issues.

1. a.f(..) -> A.f(a, ..) transformation is performed is several places
in the current code.  I have streamlined CALL_* opcodes processing to
make all calls go through PyObject_Call. This eliminated some
optimizations that can be put back in once the general framework is
accepted.

2. The only solution I could find to fixing reporting from
instancemethod_call was to add expected number of arguments information
to the exception raised in ceval and use it to reraise with a proper
message.  Obviously, putting the necessary info into the argument tuple
 is a hack and prevents reproducing original error messages from the
regular function calls.  I see two alternatives: (a) parsing the error
string to extract the needed information (feels like even a bigger
hack), and (b) creating an ArgumentError subclass of TypeError and have
its instances store needed information in additional attributes (talking
about a canon and a mosquito!)

3. If a solution that requires extra information in an exception is
accepted, PyArg_Parse* functions should be similarly modified to add the
extra info when raising an error.

Finally, let's revisit whether this mosquito deserves to die.  After
all, anyone looking at method definition sees the self argument, so
saying that a.f(1, 2) provides 3 arguments to f() is not such a stretch
of the truth.

It is also possible that I simply fail to see a simpler solution.  It
this case, please enlighten me!

PS: The patch breaks cProfile and several other tests that check error
messages.  I am making it available for discussion only.

Added file: http://bugs.python.org/file9933/issue2516poc1.diff

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

From report at bugs.python.org  Thu Apr  3 22:04:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 03 Apr 2008 20:04:25 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1207253065.57.0.256570373193.issue2516@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Guido, what's your opinion on this? Is this a bug, and should it be fixed?

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

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

From report at bugs.python.org  Thu Apr  3 22:10:36 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 20:10:36 +0000
Subject: [issue2543] Make ctypes compatible with Python 2.3, 2.4, and 2.5,
	as per PEP291
In-Reply-To: <1207253436.39.0.0138012996371.issue2543@psf.upfronthosting.co.za>
Message-ID: <1207253436.39.0.0138012996371.issue2543@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

To be committed after the current release is out.

----------
assignee: theller
components: ctypes
files: ctypes-compat-py23.diff
keywords: patch, patch
messages: 64904
nosy: theller
severity: normal
status: open
title: Make ctypes compatible with Python 2.3, 2.4, and 2.5, as per PEP291
type: compile error
versions: Python 2.6
Added file: http://bugs.python.org/file9934/ctypes-compat-py23.diff

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

From report at bugs.python.org  Thu Apr  3 22:22:17 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 03 Apr 2008 20:22:17 +0000
Subject: [issue2455] stat.ST_CTIME and stat.ST_ATIME problem
In-Reply-To: <1206152716.81.0.392707028584.issue2455@psf.upfronthosting.co.za>
Message-ID: <1207254137.57.0.681654948914.issue2455@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Not here, ST_CTIME is 9 and ST_ATIME is 7, both are the correct indices
at the tuple returned by os.stat.

Could you recheck that and then and include some output (if it is really
incorrect) ?

----------
nosy: +gpolo

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

From report at bugs.python.org  Thu Apr  3 23:08:06 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 21:08:06 +0000
Subject: [issue2544] link with "gcc -shared" on HP systems
In-Reply-To: <1207256886.04.0.563563345586.issue2544@psf.upfronthosting.co.za>
Message-ID: <1207256886.04.0.563563345586.issue2544@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

As discussed in issue #1582742, this patch uses 'gcc -shared' as linker
on HP systems when compiling with gcc.  It fixes a problem in the ctypes
test-suite, that _ctypes_test.so cannot be dynloaded because of missing
symbols.

To be committed after the current alpha-release is out.

----------
assignee: theller
components: Build
files: configure.diff
keywords: patch, patch
messages: 64906
nosy: theller
severity: normal
status: open
title: link with "gcc -shared" on HP systems
versions: Python 2.6
Added file: http://bugs.python.org/file9935/configure.diff

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

From report at bugs.python.org  Thu Apr  3 23:09:44 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 03 Apr 2008 21:09:44 +0000
Subject: [issue1582742] Python is dumping core after the test test_ctypes
Message-ID: <1207256984.67.0.155136305408.issue1582742@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

See issue #2544, this problem will be solved in Python 2.6.  In Python
2.5, ctypes does not work on HPUX.

----------
assignee:  -> theller
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Fri Apr  4 01:10:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 03 Apr 2008 23:10:11 +0000
Subject: [issue1733757] RuntimeWarning: tp_compare didn't return -1 or -2
Message-ID: <1207264211.15.0.0304993271495.issue1733757@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The deadlock was resolved by r62136.
I think I was lucky this time. I was close to disable sys.settrace
before interpreter shutdown. But is would disallow debugging inside the
finalization procedures.

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

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

From report at bugs.python.org  Fri Apr  4 03:06:51 2008
From: report at bugs.python.org (Rick Harris)
Date: Fri, 04 Apr 2008 01:06:51 +0000
Subject: [issue2116] weakref copy module interaction
In-Reply-To: <1203024154.91.0.456074381022.issue2116@psf.upfronthosting.co.za>
Message-ID: <1207271211.91.0.638059909399.issue2116@psf.upfronthosting.co.za>


Rick Harris <rconradharris at gmail.com> added the comment:

Sorry about forgetting the -c arg! The patch is intended for
python/trunk/Lib/copy.py.

It looks like Raymond Hettinger has made a similar-ish change recently
to make Ellipsis copyable.

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

From report at bugs.python.org  Fri Apr  4 03:39:58 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 04 Apr 2008 01:39:58 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1206915815.51.0.55915619351.issue2516@psf.upfronthosting.co.za>
Message-ID: <1207273198.91.0.597175319604.issue2516@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

It's definitely a bug, but I think the reason it has been around so 
long is that no-one has offerred a clean solution.  

I was hoping for something along the lines of functions raising an 
ArgumentError (a new subclass of TypeError) that could be trapped by 
the __call__ slot for bound methods and then reraised with a new 
argument count.  The key is to find a *very* lightweight and minimal 
solution; otherwise, we should just live with it for another 18 years :-
)

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

From report at bugs.python.org  Fri Apr  4 05:33:29 2008
From: report at bugs.python.org (Josh Cogliati)
Date: Fri, 04 Apr 2008 03:33:29 +0000
Subject: [issue2475] Popen.poll always returns None
In-Reply-To: <1206392349.51.0.854683862843.issue2475@psf.upfronthosting.co.za>
Message-ID: <1207280009.39.0.637702912959.issue2475@psf.upfronthosting.co.za>


Josh Cogliati <jjcogliati-r1 at yahoo.com> added the comment:

Hm.  Well, after filing the bug, I created a thread for each subprocess,
and had that thread do an wait on the process, and that worked fine. 
So, I guess at minimum it sounds like the documentation for poll could
be improved to mention that it will not catch the state if something
else does.  I think a better fix would be for poll to return some kind
of UnknownError instead of None if the process was finished, but python
did not catch it for some reason (like using os.wait() :)

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

From report at bugs.python.org  Fri Apr  4 06:29:14 2008
From: report at bugs.python.org (John Millikin)
Date: Fri, 04 Apr 2008 04:29:14 +0000
Subject: [issue2545] sphinx.ext.autodoc fails to expand tabs in docstrings
In-Reply-To: <1207283352.64.0.672793099333.issue2545@psf.upfronthosting.co.za>
Message-ID: <1207283352.64.0.672793099333.issue2545@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

Sphinx seems to need tabs expanded in reST, but the autodoc extension
doesn't do so. The following patch is very small, and fixes the issue on
my system.

Oddly, I can reproduce this on a Linux system with doctools and docutils
trunk, but not on a Mac with doctools and docutils trunk vOv.

Index: ext/autodoc.py
===================================================================
--- ext/autodoc.py      (revision 62140)
+++ ext/autodoc.py      (working copy)
@@ -41,7 +41,8 @@
     """
     if not s or s.isspace():
         return ['']
-    nl = s.expandtabs().rstrip().find('\n')
+    s = s.expandtabs ()
+    nl = s.rstrip().find('\n')
     if nl == -1:
         # Only one line...
         return [s.strip(), '']

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 64912
nosy: georg.brandl, jmillikin
severity: normal
status: open
title: sphinx.ext.autodoc fails to expand tabs in docstrings
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr  4 06:29:29 2008
From: report at bugs.python.org (John Millikin)
Date: Fri, 04 Apr 2008 04:29:29 +0000
Subject: [issue2545] sphinx.ext.autodoc fails to expand tabs in docstrings
In-Reply-To: <1207283352.64.0.672793099333.issue2545@psf.upfronthosting.co.za>
Message-ID: <1207283369.75.0.761893241099.issue2545@psf.upfronthosting.co.za>


Changes by John Millikin <jmillikin at gmail.com>:


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

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

From report at bugs.python.org  Fri Apr  4 06:59:59 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 04 Apr 2008 04:59:59 +0000
Subject: [issue2138] Add a factorial function
In-Reply-To: <1203329368.91.0.915653416666.issue2138@psf.upfronthosting.co.za>
Message-ID: <1207285199.4.0.216597383385.issue2138@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

The fact that other languages have factorial does not in itself impress
me.  What is the actual use case other than illustrating computational
induction (whether by iteration or recursion) and for calculating
binomial coefficients?

I don't really like the idea of making factorial a method for the same
reason that exp, sin, ....... are not methods of float: there is no end.
 People should be able to learn basic classes without specialized
functions attached.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Fri Apr  4 07:17:27 2008
From: report at bugs.python.org (Jason)
Date: Fri, 04 Apr 2008 05:17:27 +0000
Subject: [issue2539] Windows Registry issue with 2.5.2 AMD64 msi
In-Reply-To: <1207206100.5.0.212638703532.issue2539@psf.upfronthosting.co.za>
Message-ID: <47F5BA1A.8080804@bestmail.us>


Jason <iggyboo at bestmail.us> added the comment:

I did a per-machine installation (Install for all users).  I don't have 
the registry information at the moment, but I'll do some more 
uninstalling and reinstalling and get that information to you.

Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Do you perform a per-user or per-machine installation?
>
> When you look at the Python registry keys, which ones get written?
>
> ----------
> nosy: +loewis
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2539>
> __________________________________
>

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

From report at bugs.python.org  Fri Apr  4 07:29:00 2008
From: report at bugs.python.org (George Verbitsky)
Date: Fri, 04 Apr 2008 05:29:00 +0000
Subject: [issue2546] Python-2.5.2: crash in visit_decref () at
	Modules/gcmodule.c:270
In-Reply-To: <1207286940.13.0.627787350916.issue2546@psf.upfronthosting.co.za>
Message-ID: <1207286940.13.0.627787350916.issue2546@psf.upfronthosting.co.za>


New submission from George Verbitsky <garikvm at yahoo.com>:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208408368 (LWP 2816)]
0x080edccd in visit_decref (op=0xbf9289ff, data=0x0) at
Modules/gcmodule.c:270
270             if (PyObject_IS_GC(op)) {
(gdb) bt
#0  0x080edccd in visit_decref (op=0xbf9289ff, data=0x0) at
Modules/gcmodule.c:270
#1  0x08099e19 in tupletraverse (o=0xb7f2380c, visit=0x80edcc0
<visit_decref>, arg=0x0)
    at Objects/tupleobject.c:443
#2  0x080ee63e in collect (generation=0) at Modules/gcmodule.c:295
#3  0x080ef159 in _PyObject_GC_NewVar (tp=0x8170700, nitems=14) at
Modules/gcmodule.c:897
#4  0x08111f10 in PyFrame_New (tstate=0x8bdd128, code=0xb7d04410,
globals=0xb7cd3934, locals=0x0)
    at Objects/frameobject.c:614
#5  0x080c521a in PyEval_EvalFrameEx (f=0x8cf0fb4, throwflag=0) at
Python/ceval.c:3639
#6  0x080c5265 in PyEval_EvalFrameEx (f=0x8ced7bc, throwflag=0) at
Python/ceval.c:3650
#7  0x080c5265 in PyEval_EvalFrameEx (f=0x8ced484, throwflag=0) at
Python/ceval.c:3650
#8  0x080c5265 in PyEval_EvalFrameEx (f=0x8ce7dbc, throwflag=0) at
Python/ceval.c:3650
#9  0x080c5265 in PyEval_EvalFrameEx (f=0x8ce7c5c, throwflag=0) at
Python/ceval.c:3650
#10 0x080c6075 in PyEval_EvalCodeEx (co=0xb7c2d608, globals=0xb7c18e84,
locals=0x0, args=0xb7f28378, 
    argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2831
#11 0x08112871 in function_call (func=0xb7c2af44, arg=0xb7f2836c,
kw=0x0) at Objects/funcobject.c:517
#12 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f2836c, kw=0x0) at
Objects/abstract.c:1860
#13 0x08067937 in instancemethod_call (func=0xb7f1302c, arg=0xb7f2836c,
kw=0x0) at Objects/classobject.c:2497
#14 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f5202c, kw=0x0) at
Objects/abstract.c:1860
#15 0x0809d7cb in slot_tp_init (self=0xb7c3442c, args=0xb7f5202c,
kwds=0x0) at Objects/typeobject.c:4862
#16 0x080a0393 in type_call (type=0x8c5d04c, args=0xb7f5202c, kwds=0x0)
at Objects/typeobject.c:436
#17 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f5202c, kw=0x0) at
Objects/abstract.c:1860
#18 0x080c1149 in PyEval_EvalFrameEx (f=0x8ce7afc, throwflag=0) at
Python/ceval.c:3775
#19 0x080c6075 in PyEval_EvalCodeEx (co=0xb7c2d4a0, globals=0xb7c83934,
locals=0x0, args=0xb7f23818, 
    argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/ceval.c:2831
#20 0x08112871 in function_call (func=0xb7c2ae64, arg=0xb7f2380c,
kw=0x0) at Objects/funcobject.c:517
#21 0x08061a17 in PyObject_Call (func=0x7, arg=0xb7f2380c, kw=0x0) at
Objects/abstract.c:1860
#22 0x080be26c in PyEval_CallObjectWithKeywords (func=0xb7c2ae64,
arg=0xb7f2380c, kw=0x0)
    at Python/ceval.c:3433
#23 0x08061c30 in PyObject_CallObject (o=0xb7c2ae64, a=0xb7f2380c) at
Objects/abstract.c:1851
#24 0x08061879 in C2py (func=0x81380c5 "backend", nargs=1) at C2py.c:52
#25 0x0806191d in backend (output_filename=0xbf9289ff "cla") at backend.c:5
#26 0x08056fa5 in main (argc=3, argv=0xbf9271b4) at main.c:33
(gdb)

----------
components: Interpreter Core
messages: 64915
nosy: garikvm
severity: normal
status: open
title: Python-2.5.2: crash in visit_decref () at Modules/gcmodule.c:270
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr  4 07:42:38 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 04 Apr 2008 05:42:38 +0000
Subject: [issue2385] run_setup can fail if the setup script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1207287758.75.0.987615225083.issue2385@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

I don't think these are the right thing to do.

1. Your run_setup() changes add a os.chdir(), but then uses the path to
   the script as passed in; this assumes that the provided path is
   absolute, which is not a good assumption.  That is not currently
   required.  The effect is that a path that works currently may not
   work after the change.  A relative path will not be usable to locate
   support files in this case, since it no longer refers to the
   directory is used to.

   Also, the way you restore the current directory doesn't work;
   os.curdir isn't what you think it is.  This isn't covered in the
   test, either.

2. Apparently there are setup.py scripts that test __name__ (this
   surprised me, but Google Code Search says there are many:
   http://www.google.com/codesearch?q=file%3Asetup.py+%22__main__%22).
   This change would affect those that are currently seeing
   "__builtin__" (picked up from the built-in namespace).

Arguably, it's reasonable to expect run_setup() to restore the current
directory if a setup.py script does change it, but it's not clear that
the change in behavior wouldn't cause problems for existing scripts.

I've adjusted the patch so that the __file__ is supported, but the other
behaviors are omitted.  This has been commited in revision 62142 on the
trunk.

----------
assignee:  -> fdrake
nosy: +fdrake
priority:  -> low

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

From report at bugs.python.org  Fri Apr  4 07:52:12 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 04 Apr 2008 05:52:12 +0000
Subject: [issue2385] run_setup can fail if the setup script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1207288332.96.0.179070311495.issue2385@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Here's a patch that restores the current directory after running the
script.  The distutils-sig should probably determine if that's the right
thing to do.  Includes test.

Added file: http://bugs.python.org/file9936/run_script-restores-cwd.patch

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

From report at bugs.python.org  Fri Apr  4 08:29:48 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 04 Apr 2008 06:29:48 +0000
Subject: [issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2
In-Reply-To: <1207290588.7.0.806597302139.issue2547@psf.upfronthosting.co.za>
Message-ID: <1207290588.7.0.806597302139.issue2547@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

The 30a4 RELNOTES file doesn't cover 30a3 or 30a4.

----------
assignee: georg.brandl
components: Documentation
messages: 64918
nosy: georg.brandl, mark
severity: normal
status: open
title: Py30a4 RELNOTES only cover 30a1 and 30a2
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Fri Apr  4 09:20:31 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Apr 2008 07:20:31 +0000
Subject: [issue2546] Python-2.5.2: crash in visit_decref () at
	Modules/gcmodule.c:270
In-Reply-To: <1207286940.13.0.627787350916.issue2546@psf.upfronthosting.co.za>
Message-ID: <1207293631.04.0.756092249692.issue2546@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Without a single hint about the code your are running, no investigation
is possible. And since the traceback shows that the python interpreter
is embedded in another application, it could very well be an error in
your C code.

Please provide a way to reproduce the problem.

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

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

From report at bugs.python.org  Fri Apr  4 10:16:42 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 04 Apr 2008 08:16:42 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

[Found by Daniel Diniz (ajaksu2), see issue #2542]

The following code triggers an undetected error with a debug build:

"""
import sys
def g():
  try:
    return g()
  except:
    return sys.exc_info()
g()
print 42
"""

Running the code prints this:

C:\svn\trunk\PCbuild>python_d test2.py
42
XXX undetected error
Traceback (most recent call last):
  File "test2.py", line 8, in <module>
    print 42
RuntimeError: maximum recursion depth exceeded
[8826 refs]

C:\svn\trunk\PCbuild>

----------
components: Interpreter Core
messages: 64920
nosy: theller
severity: normal
status: open
title: Undetected error in exception handling
type: crash
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 10:17:24 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 04 Apr 2008 08:17:24 +0000
Subject: [issue2542] PyErr_ExceptionMatches must not fail
In-Reply-To: <1207213140.65.0.87653801468.issue2542@psf.upfronthosting.co.za>
Message-ID: <1207297044.64.0.120975848473.issue2542@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Daniel, IMO you've found a separate bug.  I added it as issue #2548.

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

From report at bugs.python.org  Fri Apr  4 10:36:10 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 04 Apr 2008 08:36:10 +0000
Subject: [issue2543] Make ctypes compatible with Python 2.3, 2.4, and 2.5,
	as per PEP291
In-Reply-To: <1207253436.39.0.0138012996371.issue2543@psf.upfronthosting.co.za>
Message-ID: <1207298170.53.0.100143949044.issue2543@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Committed as rev 62143.

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

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

From report at bugs.python.org  Fri Apr  4 12:08:27 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 04 Apr 2008 10:08:27 +0000
Subject: [issue2544] link with "gcc -shared" on HP systems
In-Reply-To: <1207256886.04.0.563563345586.issue2544@psf.upfronthosting.co.za>
Message-ID: <1207303707.64.0.325630007955.issue2544@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Committed as rev 62145.

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

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

From report at bugs.python.org  Fri Apr  4 13:34:49 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 04 Apr 2008 11:34:49 +0000
Subject: [issue2385] run_setup can fail if the setup script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1207308889.01.0.504102733933.issue2385@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Of course, my previous commit did what I said it should not in #1 above:
it changed the current directory to the directory in which the setup.py
script lived (which made __file__ wrong).

Fixed in revision 62147, including test that checks that the script is
run in the current directory of the caller.

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

From report at bugs.python.org  Fri Apr  4 13:43:08 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Fri, 04 Apr 2008 11:43:08 +0000
Subject: [issue2385] run_setup can fail if the setup script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1207309388.28.0.441850284055.issue2385@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

right, I misused os.curdir, I wanted the current working directory.
(getcwd())

Thanks for correcting it and making it a separate patch

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

From report at bugs.python.org  Fri Apr  4 13:43:54 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 04 Apr 2008 11:43:54 +0000
Subject: [issue2385] run_setup can fail if the setup script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1207309434.91.0.864513943142.issue2385@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

Updated patch to add restoring the current directory after running the
setup.py script in run_script.

Added file: http://bugs.python.org/file9937/run_script-restores-cwd.patch

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

From report at bugs.python.org  Fri Apr  4 13:44:14 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 04 Apr 2008 11:44:14 +0000
Subject: [issue2385] run_setup can fail if the setup script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1207309454.76.0.981942913262.issue2385@psf.upfronthosting.co.za>


Changes by Fred L. Drake, Jr. <fdrake at acm.org>:


Removed file: http://bugs.python.org/file9936/run_script-restores-cwd.patch

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

From report at bugs.python.org  Fri Apr  4 14:34:36 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Fri, 04 Apr 2008 12:34:36 +0000
Subject: [issue2385] run_setup can fail if the setup script uses __file__
In-Reply-To: <1205835874.17.0.090976046813.issue2385@psf.upfronthosting.co.za>
Message-ID: <1207312476.42.0.959609560334.issue2385@psf.upfronthosting.co.za>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

It's also arguable that not providing __file__ was a bug, in which case
that should be backported to Python 2.5.x.

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

From report at bugs.python.org  Fri Apr  4 14:43:56 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 04 Apr 2008 12:43:56 +0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1207313036.07.0.946026369915.issue799428@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

While we are at it, can't we revamp nametowidget too ?
Patch attached

----------
nosy: +gpolo
Added file: http://bugs.python.org/file9938/bugfix_and_revamp_nametowidget.diff

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

From report at bugs.python.org  Fri Apr  4 14:49:06 2008
From: report at bugs.python.org (jan matejek)
Date: Fri, 04 Apr 2008 12:49:06 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1207313346.64.0.848742285948.issue1179@psf.upfronthosting.co.za>


Changes by jan matejek <jmatejek at suse.cz>:


----------
nosy: +matejcik

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

From report at bugs.python.org  Fri Apr  4 16:44:19 2008
From: report at bugs.python.org (Chabod)
Date: Fri, 04 Apr 2008 14:44:19 +0000
Subject: [issue2549] shutil: NameError (WindowsWrror) when moving from ext3 to
	fat32 under linux
In-Reply-To: <1207320258.84.0.0564229805861.issue2549@psf.upfronthosting.co.za>
Message-ID: <1207320258.84.0.0564229805861.issue2549@psf.upfronthosting.co.za>


New submission from Chabod <jerome.chabod at ifrance.com>:

shutil generate a NameError (WindowsError) exception when moving a
directory from an ext3 to a fat32 under linux

To reproduce it: 
under linux, current path on an ext3 filesytem, try to enter following
commands: 
mkdir toto #on an ext3 partition
python
import shutil
shutil.move("toto", "/media/fat32/toto") # /media/fat32 is mounted on a
fat32 filesystem

You will produce following error:
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/shutil.py", line 196, in move
    copytree(src, dst, symlinks=True)
  File "/usr/lib/python2.5/shutil.py", line 132, in copytree
    except WindowsError:
NameError: global name 'WindowsError' is not defined

Tested on ubuntu Feisty and a newly installed Hardy-beta.

----------
components: Library (Lib)
messages: 64930
nosy: jerome.chabod
severity: normal
status: open
title: shutil: NameError (WindowsWrror) when moving from ext3 to fat32 under linux
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Fri Apr  4 16:47:27 2008
From: report at bugs.python.org (Chabod)
Date: Fri, 04 Apr 2008 14:47:27 +0000
Subject: [issue2549] shutil: NameError (WindowsError) when moving from ext3 to
	fat32 under linux
In-Reply-To: <1207320258.84.0.0564229805861.issue2549@psf.upfronthosting.co.za>
Message-ID: <1207320447.83.0.956249280773.issue2549@psf.upfronthosting.co.za>


Changes by Chabod <jerome.chabod at ifrance.com>:


----------
title: shutil: NameError (WindowsWrror) when moving from ext3 to fat32 under linux -> shutil: NameError (WindowsError) when moving from ext3 to fat32 under linux

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

From report at bugs.python.org  Fri Apr  4 16:50:56 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 04 Apr 2008 14:50:56 +0000
Subject: [issue2549] shutil: NameError (WindowsError) when moving from ext3 to
	fat32 under linux
In-Reply-To: <1207320258.84.0.0564229805861.issue2549@psf.upfronthosting.co.za>
Message-ID: <1207320656.26.0.956136012114.issue2549@psf.upfronthosting.co.za>


Changes by Trent Nelson <tnelson at onresolve.com>:


----------
assignee:  -> Trent.Nelson
keywords: +easy
nosy: +Trent.Nelson

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

From report at bugs.python.org  Fri Apr  4 16:54:19 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Fri, 04 Apr 2008 14:54:19 +0000
Subject: [issue2549] shutil: NameError (WindowsError) when moving from ext3 to
	fat32 under linux
In-Reply-To: <1207320258.84.0.0564229805861.issue2549@psf.upfronthosting.co.za>
Message-ID: <1207320859.26.0.68500484007.issue2549@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

This problem has been noticed as part of issue1545 and a patch with the
fix has been proposed but has a small problem with it. Do you want to
take a look?

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

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

From report at bugs.python.org  Fri Apr  4 17:11:05 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 04 Apr 2008 15:11:05 +0000
Subject: [issue2516] Instance methods are misreporting the number of arguments
In-Reply-To: <1207273198.91.0.597175319604.issue2516@psf.upfronthosting.co.za>
Message-ID: <d38f5330804040754s45ee192ha308e7818be8c1f4@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 3, 2008 at 9:39 PM, Raymond Hettinger
<report at bugs.python.org> wrote:

> It's definitely a bug

What would you say to the following:

def f(x):
    pass
class X:
    xf = f

x = X()
x.xf(1,2)

--> TypeError: f() takes exactly 1 argument (3 given)

Is this correct?

..
>  I was hoping for something along the lines of functions raising an
>  ArgumentError (a new subclass of TypeError) that could be trapped by
>  the __call__ slot for bound methods and then reraised with a new
>  argument count.

This would be my first choice for a clean solution as well.  Since it
will require a change to the exception hierarchy, should we discuss a
modification to PEP 348 on python-dev?   I would rather finish the
patch first and then make a concrete proposal.

> The key is to find a *very* lightweight and minimal solution;

.. according to what metric?  Are you talking about the amount of code
that needs to be changed, the number of API changes or run-time
overhead?  I don't think run-time overhead is an issue: argument
errors are rarely used for flow control  because it is hard to predict
what a failed attempt to call a function would do.

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

From report at bugs.python.org  Fri Apr  4 17:58:00 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 04 Apr 2008 15:58:00 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>


New submission from Trent Nelson <tnelson at onresolve.com>:

Background: I came across this issue when trying to track down why 
test_asynchat would periodically wedge python processes on the Windows 
buildbots, to the point that they wouldn't even respond to SIGKILL (or 
ctrl-c on the console).

What I found after a bit of digging is that Windows doesn't raise 
EADDRINUSE socket.errors when you bind() two sockets to identical 
host/ports *IFF* SO_REUSEADDR has been set as a socket option.

Decided to brighten up my tube journey into work this morning by 
reading the Gospel's take on the situation.  As per the 'SO_REUSEADDR 
and SO_REUSEPORT Socket Options' section in chapter 7.5 of Stevens' 
UNIX Network Programming Volume 1 (2nd Ed):

"With TCP, we are never able to start multiple servers that bind
 the same IP address and same port: a completely duplicate binding.
 That is, we cannot start one server that binds 198.69.10.2 port 80
 and start another that also binds 198.69.10.2 port 80, even if we
 set the SO_REUSEADDR socket option for the second server."

So, it seems at least Windows isn't adhering to this, at least on XP 
and Server 2008 with 2.5-2.6.  I've patched test_socket.py to 
explicitly test for this situation -- as expected, it passes on Unix 
(tested on FreeBSD in particular), and fails on Windows.  I'd like to 
commit this to trunk to see if any of the buildbots for different 
platforms match the behaviour of Windows.

----------
assignee: Trent.Nelson
components: Library (Lib), Windows
files: test_socket.py.patch
keywords: 26backport, patch
messages: 64933
nosy: Trent.Nelson
priority: high
severity: normal
status: open
title: SO_REUSEADDR doesn't have the same semantics on Windows as on Unix
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9939/test_socket.py.patch

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

From report at bugs.python.org  Fri Apr  4 19:42:09 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 04 Apr 2008 17:42:09 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1207330928.97.0.909826058579.issue2537@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I'm almost tempted to call the first of these a bug:  isn't '((x|y)*)*'
a perfectly valid (albeit somewhat redundant) regular expression?  What
am I missing here?

Even if there are issues with capturing, shouldn't the version without
capturing subexpressions still work?

I get:

>>> re.compile(r'(?:(?:x|y)*)*')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.5/re.py", line 180, in compile
    return _compile(pattern, flags)
  File "/usr/lib/python2.5/re.py", line 233, in _compile
    raise error, v # invalid expression
sre_constants.error: nothing to repeat

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

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

From report at bugs.python.org  Fri Apr  4 19:58:45 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 04 Apr 2008 17:58:45 +0000
Subject: [issue2296] [PATCH] Tcl/Tk 8.4.16 patches needed to get an x64
	Windows build
In-Reply-To: <1205620533.13.0.0700129427319.issue2296@psf.upfronthosting.co.za>
Message-ID: <1207331925.12.0.178562119788.issue2296@psf.upfronthosting.co.za>


Changes by Trent Nelson <tnelson at onresolve.com>:


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

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

From report at bugs.python.org  Fri Apr  4 20:07:10 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Fri, 04 Apr 2008 18:07:10 +0000
Subject: [issue2221] Py30a3: eval in threaded code raises SystemError
In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
Message-ID: <1207332430.78.0.176123776579.issue2221@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

I don't think that this is an IDLE error.  It 
can be more generally exhibited as follows:

Without the subprocess we get the expected:

IDLE 3.0a4      ==== No Subprocess ====
>>> eval('a')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    eval('a')
  File "<string>", line 1, in <module>
NameError: name 'a' is not defined

With the subprocess there is an interpreter 
error when IDLE applies eval to 'a':

IDLE 3.0a4      
>>> eval('a')
Traceback (most recent call last):
  File "<pyshell#0>", line 1, in <module>
    eval('a')
SystemError: error return without exception set

I did a cutdown where I ran the eval in a 
subprocess and didn't reproduce the error.  I 
suspect it's thread related (the subprocess 
uses its main thread to execute user code, and 
another thread to manage the socket connection 
to the GUI process).

issue1733757 is suggestive.

This is a 3.0 issue, it doesn't occur in the 
trunk.

----------
assignee: kbk -> 
components: +Interpreter Core -IDLE
nosy: +amaury.forgeotdarc
priority: normal -> high
title: Py30a3: calltip produces error output to stderr -> Py30a3: eval in threaded code raises SystemError

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

From report at bugs.python.org  Fri Apr  4 20:07:24 2008
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 04 Apr 2008 18:07:24 +0000
Subject: [issue2250] rlcompleter raises Exception on bad input
In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za>
Message-ID: <1207332444.69.0.347556220159.issue2250@psf.upfronthosting.co.za>


Lorenz Quack <don at amberfisharts.com> added the comment:

I confirmed that the rlcompleter can raise a SyntaxError on bad input.
Upon further investigation I found that a ReferenceError could also be
raised. I didn't check on other Exceptions.

I attached a new version of the patch where I catch all Errors derived
from Exceptions (not SystemError and KeyboardInterrupt).

while this seems rather drastic I really feel that this step should in
no case raise an Exception. I can't possibly think of a situation where
someone would want that.

Concerning the docs:
"...it will try to evaluate anything without obvious side-effects..."
I would consider raising an exception as a major side-effect so this
patch rather brings the code into accordance with the docs than it
contradicts them.

Added file: http://bugs.python.org/file9940/rlcompleter_Exception.patch

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

From report at bugs.python.org  Fri Apr  4 20:55:04 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 18:55:04 +0000
Subject: [issue2551] Python 2.6a2 on Solaris 10 built with SUN C
In-Reply-To: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>
Message-ID: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

Below is the tail of the output of 'make test' for 32-bit Python 2.6a2 
on Solaris 10 (Opteron) built with the SUN C compiler.

310 tests OK.
1 test failed:
    test_ioctl
41 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_epoll test_gdbm test_gl test_imageop test_imgfile
    test_kqueue test_linuxaudiodev test_macostools test_normalization
    test_ossaudiodev test_pep277 test_py3kwarn test_scriptpackages
    test_socket_ssl test_socketserver test_sqlite test_ssl
    test_startfile test_tcl test_timeout test_unicode_file
    test_urllib2net test_urllibnet test_winreg test_winsound
    test_zipfile64
3 skips unexpected on sunos5:
    test_tcl test_ssl test_ctypes


The ctypes test failed since the _ctypes module did not compile.
...
cc -KPIC -xtarget=native -DNDEBUG -xO5 -I. -I/.../tools/Python-
2.6a2/./Include -Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include -
Ibuild/temp.solaris-2.10-i86pc-2.6/libffi -I/.../tools/Python-
2.6a2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -
I/.../tools/Python-2.6a2/Include -I/.../tools/Python-2.6a2 -c 
.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c -o build/temp.solaris-
2.10-i86pc-2.6/.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.o
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 67: 
undefined symbol: FFI_DEFAULT_ABI
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 68: 
non-constant enumerator value
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
syntax error before or at: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: old-style declaration or incorrect type for: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: syntax error:  empty declaration
".../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c", line 155: cannot 
recover from previous errors
cc: acomp failed for /.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c
...


The test_ioctl failures seems test related.
...
test test_ioctl failed -- Traceback (most recent call last):
  File "/.../tools/Python-2.6a2/Lib/test/test_ioctl.py", line 56, in 
test_ioctl_signed_unsigned_code_param
    saved_winsz = fcntl.ioctl(mfd, termios.TIOCGWINSZ, "\0"*8)
IOError: [Errno 22] Invalid argument
...

There is no SSL support and Tcl is not installed on this machine.  

Finally, this failure does not show up in the summary:
...
test_parser
Expecting 's_push: parser stack overflow' in next line
s_push: parser stack overflow
...

----------
components: Tests
messages: 64937
nosy: MrJean1
severity: normal
status: open
title: Python 2.6a2 on Solaris 10 built with SUN C
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 21:06:17 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 04 Apr 2008 19:06:17 +0000
Subject: [issue2551] Python 2.6a2 on Solaris 10 built with SUN C
In-Reply-To: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>
Message-ID: <1207335977.16.0.197945020722.issue2551@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

On *nix-like systems, ctypes will most likely only compile with gcc. 
Since I do not have access to such systems, neither the expertise for
them, this will not change unless someone provides patches.

----------
nosy: +theller

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

From report at bugs.python.org  Fri Apr  4 21:34:47 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 04 Apr 2008 19:34:47 +0000
Subject: [issue1517495] memory leak threading or socketserver module
Message-ID: <1207337686.99.0.383412153987.issue1517495@psf.upfronthosting.co.za>


Robert Schuppenies <okkotonushi at googlemail.com> added the comment:

I can *not* confirm the leak. I tested using the provided scripts (with
little modifications to log memory usage), using 1000 instead of 20
runs. I am running on Debian Linux and checked the reported Python
2.4.2 and the current trunk (2.6a2). I attached my results for
both. For me it looks like the average memory variations.

----------
nosy: +okkoto
Added file: http://bugs.python.org/file9941/memory2.4.2.csv

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

From report at bugs.python.org  Fri Apr  4 21:37:36 2008
From: report at bugs.python.org (Robert Schuppenies)
Date: Fri, 04 Apr 2008 19:37:36 +0000
Subject: [issue1517495] memory leak threading or socketserver module
Message-ID: <1207337856.38.0.266862889564.issue1517495@psf.upfronthosting.co.za>


Changes by Robert Schuppenies <okkotonushi at googlemail.com>:


Added file: http://bugs.python.org/file9942/memory2.6a2.csv

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

From report at bugs.python.org  Fri Apr  4 21:47:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 04 Apr 2008 19:47:15 +0000
Subject: [issue2551] Python 2.6a2 on Solaris 10 built with SUN C
In-Reply-To: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>
Message-ID: <1207338435.06.0.472150535556.issue2551@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Please create one report per issue.

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

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

From report at bugs.python.org  Fri Apr  4 22:01:52 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:01:52 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The ctypes test failed since the _ctypes module did not compile for 32-
bit Python 2.6a2 on Solaris 10 (Opteron) built with the SUN C compiler.

...
cc -KPIC -xtarget=native -DNDEBUG -xO5 -I. -I/.../tools/Python-
2.6a2/./Include -Ibuild/temp.solaris-2.10-i86pc-2.6/libffi/include -
Ibuild/temp.solaris-2.10-i86pc-2.6/libffi -I/.../tools/Python-
2.6a2/Modules/_ctypes/libffi/src -I. -IInclude -I./Include -
I/.../tools/Python-2.6a2/Include -I/.../tools/Python-2.6a2 -c 
.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c -o build/temp.solaris-
2.10-i86pc-2.6/.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.o
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 67: 
undefined symbol: FFI_DEFAULT_ABI
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffitarget.h", line 68: 
non-constant enumerator value
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
syntax error before or at: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: old-style declaration or incorrect type for: __attribute__
"build/temp.solaris-2.10-i86pc-2.6/libffi/include/ffi.h", line 255: 
warning: syntax error:  empty declaration
".../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c", line 155: cannot 
recover from previous errors
cc: acomp failed for /.../tools/Python-2.6a2/Modules/_ctypes/_ctypes.c
...

----------
components: Tests
messages: 64941
nosy: MrJean1
severity: normal
status: open
title: test_ctypes failed Python 2.6a2 Solaris 10 SUN C
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 22:05:45 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:05:45 +0000
Subject: [issue2554] test_ioctl failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za>
Message-ID: <1207339545.74.0.114757625359.issue2554@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The test_ioctl failed in 32-bit Python 2.6a2 built on Solaris 10 with 
the SUNC C compiler.

...
test test_ioctl failed -- Traceback (most recent call last):
  File "/.../tools/Python-2.6a2/Lib/test/test_ioctl.py", line 56, in 
test_ioctl_signed_unsigned_code_param
    saved_winsz = fcntl.ioctl(mfd, termios.TIOCGWINSZ, "\0"*8)
IOError: [Errno 22] Invalid argument
...

----------
components: Tests
messages: 64943
nosy: MrJean1
severity: normal
status: open
title: test_ioctl failed Python 2.6a2 Solaris 10 SUN C
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 22:08:05 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:08:05 +0000
Subject: [issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>
Message-ID: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

For 32-bit Python 2.6a2 on Solaris 10 (Opteron) built with the SUN C 
compiler this test_parser failure does not show up in the summary.

...
test_parser
Expecting 's_push: parser stack overflow' in next line
s_push: parser stack overflow
...

----------
components: Tests
messages: 64944
nosy: MrJean1
severity: normal
status: open
title: test_parser failed Python 2.6a2 Solaris 10 SUN C
versions: Python 2.6

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

From report at bugs.python.org  Fri Apr  4 22:11:26 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:11:26 +0000
Subject: [issue2553] test_ioctrl failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339420.13.0.8802001202.issue2553@psf.upfronthosting.co.za>
Message-ID: <1207339886.18.0.3232984843.issue2553@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

This is a duplicate.  Please ignore.  My apologies.

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

From report at bugs.python.org  Fri Apr  4 22:12:30 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 04 Apr 2008 20:12:30 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207339950.18.0.213761255008.issue2552@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Are you interested in working on a patch?

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

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

From report at bugs.python.org  Fri Apr  4 22:16:47 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:16:47 +0000
Subject: [issue2551] Python 2.6a2 on Solaris 10 built with SUN C
In-Reply-To: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>
Message-ID: <1207340207.83.0.448686473144.issue2551@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Done, see issues 2552, 2554 and 2555.  Please ignore, close duplicate 
2553.

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

From report at bugs.python.org  Fri Apr  4 22:18:11 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 04 Apr 2008 20:18:11 +0000
Subject: [issue802310] tkFont may reuse font names
Message-ID: <1207340291.05.0.252557762756.issue802310@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This still happens, but around 2000 iterations here on newer Python
versions (trunk, 3alpha, 2.5.x, 2.4.x). Using Python 1.6 I've got it at
2 iterations (min), but.. is this going to be fixed or given the amount
of iterations needed nowadays this is no longer a problem ? If it should
be fixed, are there any suggestions on how to proceed ?

----------
nosy: +gpolo

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

From report at bugs.python.org  Fri Apr  4 22:03:40 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Fri, 04 Apr 2008 20:03:40 +0000
Subject: [issue2553] test_ioctrl failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339420.13.0.8802001202.issue2553@psf.upfronthosting.co.za>
Message-ID: <1207339420.13.0.8802001202.issue2553@psf.upfronthosting.co.za>


New submission from Jean Brouwers <MrJean1 at Gmail.com>:

The test_ioctl failed in Python 2.6a2 built on Solaris 10 with the SUNC 
C compiler.

...
test test_ioctl failed -- Traceback (most recent call last):
  File "/.../tools/Python-2.6a2/Lib/test/test_ioctl.py", line 56, in 
test_ioctl_signed_unsigned_code_param
    saved_winsz = fcntl.ioctl(mfd, termios.TIOCGWINSZ, "\0"*8)
IOError: [Errno 22] Invalid argument
...

----------
messages: 64942
nosy: MrJean1
severity: normal
status: open
title: test_ioctrl failed Python 2.6a2 Solaris 10 SUN C

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

From report at bugs.python.org  Fri Apr  4 22:38:57 2008
From: report at bugs.python.org (Jason Orendorff)
Date: Fri, 04 Apr 2008 20:38:57 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1207341537.41.0.695666739868.issue2537@psf.upfronthosting.co.za>


Jason Orendorff <jason.orendorff at gmail.com> added the comment:

Huh.  Maybe you're right.  JavaScript, Ruby, and Perl all accept both
regexes, although no two agree on what should be captured:

js> "xyyzy".replace(/((x|y)*)*/, "($1, $2)") 
(xyy, y)zy
js> "xyyzy".replace(/((x|y+)*)*/, "($1, $2)")
(xyy, yy)zy

>> "xyyzy".sub(/((x|y)*)*/, "(\\1, \\2)")
=> "(, y)zy"
>> "xyyzy".sub(/((x|y+)*)*/, "(\\1, \\2)")
=> "(, yy)zy"

  DB<1> $_ = 'xyyzy'; s/((x|y)*)*/(\1 \2)/; print
( )zy
  DB<2> $_ = 'xyyzy'; s/((x|y+)*)*/(\1 \2)/; print
( yy)zy

Ruby's behavior seems best to me.

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

From report at bugs.python.org  Sat Apr  5 00:13:37 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 04 Apr 2008 22:13:37 +0000
Subject: [issue869780] curselection() in Tkinter.py should return ints
Message-ID: <1207347217.19.0.354785965957.issue869780@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Indeed, it should call self._getints, not sure why it was never done.
Fixing this gives curselection the correct behavior according to the Tk
Reference Manual: http://tmml.sourceforge.net/doc/tk/listbox.html

----------
nosy: +gpolo

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

From report at bugs.python.org  Sat Apr  5 00:57:01 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Apr 2008 22:57:01 +0000
Subject: [issue2221] Py30a3: eval in threaded code raises SystemError
In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
Message-ID: <1207349821.12.0.571644754959.issue2221@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The problem is just that in Python/pythonrun.c, the function run_mod()
calls flush_io() after executing the code. In our testcase, there is a
pending exception.
But flush_io() silently ignore errors (which is fine), and clears all
exception info (which is bad).
To correct the problem, I it is enough to calls to
PyErr_Fetch/PyErr_Restore.

This happens only with Idle, probably because the subprocess redirected
its stdout to a pseudo-file that does not support flush().

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

From report at bugs.python.org  Sat Apr  5 01:26:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 04 Apr 2008 23:26:33 +0000
Subject: [issue2221] Py30a3: eval in threaded code raises SystemError
In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
Message-ID: <1207351593.28.0.812030351398.issue2221@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r62157.

Will also investigate why exec() needs to flush sys.stdout...

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

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

From report at bugs.python.org  Sat Apr  5 02:34:25 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Apr 2008 00:34:25 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1207355665.67.0.0182416277925.issue2548@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Analysis: the primary recursion error is correctly raised, but then
there is a call to PyErr_NormalizeException, which calls
PyEval_CallObject, which increases the stack depth and hit the recursion
limit again...
python2.5 don't have the problem because PyEval_CallObject did not check
the recursion limit.

Different solutions I can think of:
- use a prebuilt exception: not possible if we still want an error
message containing the context.
- in PyErr_NormalizeException, "PyEval_CallObject" is too generic. We
could have a special path for exception types deriving from
BaseException: directly call the constructor.

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

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

From report at bugs.python.org  Sat Apr  5 03:04:06 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 05 Apr 2008 01:04:06 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1207357446.15.0.647356132902.issue1179@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

I think this was a module that I skipped.  I think Anthony might have
had a patch, but if we have a fix, I'm not sure it matters.  We need to
fix this for 2.5.3, upping the priority.

----------
nosy: +anthonybaxter
priority: high -> release blocker

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

From report at bugs.python.org  Sat Apr  5 04:03:40 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sat, 05 Apr 2008 02:03:40 +0000
Subject: [issue2221] Py30a3: eval in threaded code raises SystemError
In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
Message-ID: <1207361020.69.0.69170026233.issue2221@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Thanks, that does appear to fix the IDLE problem!

The pseudofile does have a flush method and I was able to 
call it from the IDLE subprocess; it returns None.  So I'm
not clear on why PyObject_CallMethod was returning False, or
why the problem only occurred when IDLE was running its subprocess.

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

From report at bugs.python.org  Sat Apr  5 04:05:40 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sat, 05 Apr 2008 02:05:40 +0000
Subject: [issue2506] Line tracing of continue after always-taken if is
	incorrect
In-Reply-To: <1206797921.05.0.258043023613.issue2506@psf.upfronthosting.co.za>
Message-ID: <1207361140.74.0.636062738252.issue2506@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

While I agree with Raymond that the interpreter should be left alone,
this could be reclassified (and reopened) as a doc issue.  The current
trace doc (Lib Ref 25.10) says rather tersely "The trace module allows
you to trace program execution, generate annotated statement coverage
listings, print caller/callee relationships and list functions executed
during a program run."  This could be augmented with a general statement
that the effect of certain statements may get computed during
compilation and not appear in the runtime trace -- or a more specific
statement about continue, break, and whatever else.

AS for continue.py, it seems that the apparent non-execution of a
continue line indicates one of two possible problems.

1. The if statement is equivalent to 'if True:', at least for the
intended domain of input, hence redundant, and hence could/should be
removed.
2. Otherwise, the inputs are incomplete as far as testing the effect of
not taking the if-branch, and hence could/should be augmented.

Either way, it seems to me that the lack of runtime execution of
continue, coupled with better documentation, could usefully point to
possible action.

----------
nosy: +tjreedy

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

From report at bugs.python.org  Sat Apr  5 04:59:13 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 05 Apr 2008 02:59:13 +0000
Subject: [issue2515] Segfault while operating on closed sqlite3 cursor.
In-Reply-To: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za>
Message-ID: <1207364353.11.0.102734863637.issue2515@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Gerhard, could you take a look?

----------
assignee:  -> ghaering
nosy: +ghaering, nnorwitz

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

From report at bugs.python.org  Sat Apr  5 04:59:49 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 05 Apr 2008 02:59:49 +0000
Subject: [issue2515] Segfault while operating on closed sqlite3 cursor.
In-Reply-To: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za>
Message-ID: <1207364389.37.0.323869670382.issue2515@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
priority:  -> release blocker

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

From report at bugs.python.org  Sat Apr  5 05:00:06 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 05 Apr 2008 03:00:06 +0000
Subject: [issue2526] str.format() :n format does not appear to work
In-Reply-To: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>
Message-ID: <1207364406.39.0.685367215185.issue2526@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Eric, could you take a look?

----------
assignee:  -> eric.smith
nosy: +eric.smith, nnorwitz
priority:  -> high

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

From report at bugs.python.org  Sat Apr  5 05:03:33 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 05 Apr 2008 03:03:33 +0000
Subject: [issue2546] Python-2.5.2: crash in visit_decref () at
	Modules/gcmodule.c:270
In-Reply-To: <1207286940.13.0.627787350916.issue2546@psf.upfronthosting.co.za>
Message-ID: <1207364613.85.0.495673594075.issue2546@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

I'm setting the priority to release blocker for now.  George, please
provide a way for us to reproduce with a stock python (ie, no third
party extensions).  Thanks.

----------
nosy: +nnorwitz
priority:  -> release blocker

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

From report at bugs.python.org  Sat Apr  5 05:05:20 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 05 Apr 2008 03:05:20 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1207364720.69.0.41022302854.issue2548@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Brett, didn't you have a similar problem you fixed a while ago?  I
assigned to you for more input, feel free to reset to nobody.

----------
assignee:  -> brett.cannon
nosy: +brett.cannon, nnorwitz
priority:  -> release blocker

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

From report at bugs.python.org  Sat Apr  5 06:02:49 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 05 Apr 2008 04:02:49 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1207368169.0.0.840620675042.issue2548@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu2 at users.sourceforge.net>:


----------
nosy: +ajaksu2

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

From report at bugs.python.org  Sat Apr  5 06:18:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 04:18:44 +0000
Subject: [issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>
Message-ID: <1207369124.6.0.75591331551.issue2555@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is not a bug. How should we phrase the first line to make that
unobviously clear?

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

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

From report at bugs.python.org  Sat Apr  5 06:28:00 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 04:28:00 +0000
Subject: [issue2551] Python 2.6a2 on Solaris 10 built with SUN C
In-Reply-To: <1207335304.42.0.0614697010409.issue2551@psf.upfronthosting.co.za>
Message-ID: <1207369679.91.0.242113897126.issue2551@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Thanks!

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

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

From report at bugs.python.org  Sat Apr  5 06:29:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 04:29:43 +0000
Subject: [issue2553] test_ioctrl failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339420.13.0.8802001202.issue2553@psf.upfronthosting.co.za>
Message-ID: <1207369783.77.0.991315348434.issue2553@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Sat Apr  5 06:55:51 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sat, 05 Apr 2008 04:55:51 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1207371351.27.0.30346891758.issue2538@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Travis, could you take a look?

----------
assignee:  -> teoliphant
nosy: +nnorwitz, teoliphant

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

From report at bugs.python.org  Sat Apr  5 07:25:29 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 05 Apr 2008 05:25:29 +0000
Subject: [issue2384] [Py3k] line number is wrong after encoding declaration
In-Reply-To: <1205825319.07.0.115749100037.issue2384@psf.upfronthosting.co.za>
Message-ID: <1207373128.99.0.326121813793.issue2384@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

I've written testcase for lineno problem.

----------
keywords: +patch
Added file: http://bugs.python.org/file9943/test_traceback.patch

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

From report at bugs.python.org  Sat Apr  5 10:01:46 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sat, 05 Apr 2008 08:01:46 +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: <1207382506.15.0.676700347934.issue2065@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

I don't know why, but
/D "MODULE_NAME=\"sqlite3\""
is troublesome. VC6 IDE expands this to
#define MODULE_NAME " sqlite3".

To workaround this, I used
/D MODULE_NAME=\"sqlite3\"
instead in sqlite3.dsp.

Added file: http://bugs.python.org/file9946/ocean.zip

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

From report at bugs.python.org  Sat Apr  5 12:49:52 2008
From: report at bugs.python.org (Eric Smith)
Date: Sat, 05 Apr 2008 10:49:52 +0000
Subject: [issue2526] str.format() :n format does not appear to work
In-Reply-To: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>
Message-ID: <1207392592.3.0.11467912406.issue2526@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I'm looking into it.

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

From report at bugs.python.org  Sat Apr  5 14:03:04 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 05 Apr 2008 12:03:04 +0000
Subject: [issue1164742] Tkdnd.py crashes due to read-only attributes
Message-ID: <1207396984.79.0.481371504993.issue1164742@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

This was fixed on rev 39219 (2 years and 8 months ago)
This surely could be closed by now.

----------
nosy: +gpolo

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

From report at bugs.python.org  Sat Apr  5 14:08:02 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Apr 2008 12:08:02 +0000
Subject: [issue2546] Python-2.5.2: crash in visit_decref () at
	Modules/gcmodule.c:270
In-Reply-To: <1207286940.13.0.627787350916.issue2546@psf.upfronthosting.co.za>
Message-ID: <1207397282.65.0.182368069305.issue2546@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The crash is because of an error in your C code:
in backend.c::
    void backend(char *output_filename)
    {
        C2py("backend", 1, output_filename);
    }

But your C2py function expects a variable number of PyObject*.

I found this by disabling the garbage collector: then the program
crashes in C2py.c at the instruction "Py_DECREF(pArgs);"

----------
priority: release blocker -> normal
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Apr  5 15:38:48 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 13:38:48 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207402728.8.0.992287771691.issue2530@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Great!

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

From report at bugs.python.org  Sat Apr  5 16:20:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 14:20:40 +0000
Subject: [issue1164742] Tkdnd.py crashes due to read-only attributes
Message-ID: <1207405240.81.0.890447585341.issue1164742@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr  5 16:26:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 14:26:28 +0000
Subject: [issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>
Message-ID: <1207405588.88.0.329726171647.issue2555@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

*testing stack overflow:* maybe?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sat Apr  5 16:30:25 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Apr 2008 14:30:25 +0000
Subject: [issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>
Message-ID: <1207405825.46.0.479299007281.issue2555@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Don't change that line.  It is obviously clear already, if someone does 
read it.  I obviously did not.

/Jean

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

From report at bugs.python.org  Sat Apr  5 16:31:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 14:31:15 +0000
Subject: [issue2555] test_parser failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339685.46.0.658522235222.issue2555@psf.upfronthosting.co.za>
Message-ID: <1207405875.63.0.0989531036707.issue2555@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Apr  5 16:35:34 2008
From: report at bugs.python.org (Eric Smith)
Date: Sat, 05 Apr 2008 14:35:34 +0000
Subject: [issue2526] str.format() :n format does not appear to work for int
	and float
In-Reply-To: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>
Message-ID: <1207406134.41.0.448138926268.issue2526@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The same issue exists with floats:
# continuing the example

>>> locale.format("%g", 12345, True)
'12,345'
>>> "{0:n}".format(12345.0)
'12345'

The same issue exists in 2.6.

----------
title: str.format() :n format does not appear to work -> str.format() :n format does not appear to work for int and float
versions: +Python 2.6

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

From report at bugs.python.org  Sat Apr  5 16:42:08 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Apr 2008 14:42:08 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207406528.52.0.512033034045.issue2552@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned.  The 
only thing which can be done is avoid building the _ctypes module if the 
compiler is not gcc.  I did look at fixing that but have not found the 
proper way to do that.

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

From report at bugs.python.org  Sat Apr  5 16:43:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 14:43:09 +0000
Subject: [issue2556] changing sys.dont_write_bytecode has not effect
In-Reply-To: <1207406589.36.0.590521129385.issue2556@psf.upfronthosting.co.za>
Message-ID: <1207406589.36.0.590521129385.issue2556@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

According to the 2.6 docs, says you can set it yourself to control
bytecode generation. That doesn't work because the dont_write_bytecode
flag is set from command option and never looked at again. Either we
should remove this misleading information or use PySys_GetObject in
pythonrun.c where the flag is used.

----------
assignee: georg.brandl
components: Documentation, Interpreter Core
messages: 64976
nosy: benjamin.peterson, georg.brandl
priority: high
severity: normal
status: open
title: changing sys.dont_write_bytecode has not effect
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr  5 16:45:36 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Apr 2008 14:45:36 +0000
Subject: [issue2557] \u and \U in raw strings have reverted
In-Reply-To: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>
Message-ID: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

In 2.x, \uDDDD and \UDDDDDDDD are interpreted as Unicode escapes in
raw Unicode strings. That was a mistake, but we can't fix it (except
when using "from __future__ import unicode_literals"). In 3.0, \u or
\U in a raw string should have no special meaning -- it's just a
backslash followed by 'u' or 'U'.

This was fixed in 3.0a3. It seems to have reverted to the old (2.x)
behavior in 3.0a4.

THIS MUST BE FIXED!

----------
messages: 64977
nosy: gvanrossum
priority: release blocker
severity: normal
status: open
title: \u and \U in raw strings have reverted
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Sat Apr  5 16:53:00 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Apr 2008 14:53:00 +0000
Subject: [issue2557] \u and \U in raw strings have regressed in 3.0a4
In-Reply-To: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>
Message-ID: <1207407180.06.0.39328412913.issue2557@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
title: \u and \U in raw strings have reverted -> \u and \U in raw strings have regressed in 3.0a4

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

From report at bugs.python.org  Sat Apr  5 16:53:12 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Apr 2008 14:53:12 +0000
Subject: [issue2557] \u and \U in raw strings have regressed in 3.0a4
In-Reply-To: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>
Message-ID: <1207407192.13.0.461081388125.issue2557@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
components: +Interpreter Core

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

From report at bugs.python.org  Sat Apr  5 16:53:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 14:53:17 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207407197.89.0.580572255953.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Sorry, Guido said this is not allowed:
http://mail.python.org/pipermail/python-3000/2008-April/012952.html. I
reverted it in r62165.

----------
resolution: fixed -> rejected

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

From report at bugs.python.org  Sat Apr  5 16:56:11 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 14:56:11 +0000
Subject: [issue2557] \u and \U in raw strings have regressed in 3.0a4
In-Reply-To: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>
Message-ID: <1207407371.82.0.756578051252.issue2557@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

fixed in r62165.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Apr  5 17:18:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 15:18:52 +0000
Subject: [issue2349] Py3K warn against assigning to True/False
In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za>
Message-ID: <1207408732.61.0.508619423919.issue2349@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Brett, shall I apply?

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

From report at bugs.python.org  Sat Apr  5 17:26:01 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Apr 2008 15:26:01 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207409161.41.0.195692181828.issue2541@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

The docs still need to be updated!  An entry in what's new in 3.0 should
also be added.

----------
assignee:  -> georg.brandl
components: +Documentation -Unicode
nosy: +georg.brandl, gvanrossum
status: closed -> open

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

From report at bugs.python.org  Sat Apr  5 17:32:03 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 05 Apr 2008 15:32:03 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1207409523.23.0.0484852685798.issue2548@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Neal has the memory of an elephant or something.

Yes, I dealt with a similar issue where the recursion limit was hit, but 
then normalizing the exception just caused it to hit it again. I thought 
I changed it such that normalizing an exception actually turned off the 
depth check or to raise a pre-defined exception for the recursion depth 
limit.

I don't have time to look at this right now (still on holiday in 
Brussels), but if I remember correctly the last time this came up I 
liked the pre-allocated recursion limit exception.

----------
assignee: brett.cannon -> 

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

From report at bugs.python.org  Sat Apr  5 17:35:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 15:35:20 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207409720.68.0.845199616838.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

How's this?

----------
keywords: +patch
Added file: http://bugs.python.org/file9947/py3k_raw_strings_unicode_escapes.patch

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

From report at bugs.python.org  Sat Apr  5 18:30:16 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sat, 05 Apr 2008 16:30:16 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207413016.55.0.303106128164.issue2541@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Instead of "ignored" (which might be read ambiguously) how about "not
treated specially"?

You also still need to add some words to whatsnew.

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

From report at bugs.python.org  Sat Apr  5 18:50:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 16:50:25 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207414225.32.0.764861225512.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

"not treated specially" it is!

Added file: http://bugs.python.org/file9948/py3k_raw_strings_unicode_escapes2.patch

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

From report at bugs.python.org  Sat Apr  5 18:52:57 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sat, 05 Apr 2008 16:52:57 +0000
Subject: [issue2557] \u and \U in raw strings have regressed in 3.0a4
In-Reply-To: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>
Message-ID: <1207414377.6.0.719890925693.issue2557@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

The was not a mistake, it was done on purpose since there would
otherwise have been no way to add non-ASCII Unicode code points to a raw
Unicode literal, rendering raw Unicode literals pretty useless.

Even if you use UTF-8 as source code encoding, there's no way to add
half a surrogate to a raw Unicode literal without the Unicode literals.

If you need to write a Unicode literal escape using the raw Unicode
escape encoding, you can use '\x1234'.

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

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

From report at bugs.python.org  Sat Apr  5 18:53:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 16:53:21 +0000
Subject: [issue2556] changing sys.dont_write_bytecode has not effect
In-Reply-To: <1207406589.36.0.590521129385.issue2556@psf.upfronthosting.co.za>
Message-ID: <1207414401.49.0.56057550494.issue2556@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Sorry, I can't see what's wrong here. See import.c which indeed uses
PySys_GetObject to retrieve the value of dont_write_bytecode.

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

From report at bugs.python.org  Sat Apr  5 19:00:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 17:00:03 +0000
Subject: [issue2556] changing sys.dont_write_bytecode has not effect
In-Reply-To: <1207406589.36.0.590521129385.issue2556@psf.upfronthosting.co.za>
Message-ID: <1207414803.2.0.696736079626.issue2556@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Sat Apr  5 19:03:42 2008
From: report at bugs.python.org (George Verbitsky)
Date: Sat, 05 Apr 2008 17:03:42 +0000
Subject: [issue2546] Python-2.5.2: crash in visit_decref () at
	Modules/gcmodule.c:270
In-Reply-To: <1207397282.65.0.182368069305.issue2546@psf.upfronthosting.co.za>
Message-ID: <865997.19505.qm@web56304.mail.re3.yahoo.com>


George Verbitsky <garikvm at yahoo.com> added the comment:

Thank you, Amaury, very much for helping me with this one.
George

Amaury Forgeot d'Arc <report at bugs.python.org> wrote: 
Amaury Forgeot d'Arc  added the comment:

The crash is because of an error in your C code:
in backend.c::
    void backend(char *output_filename)
    {
        C2py("backend", 1, output_filename);
    }

But your C2py function expects a variable number of PyObject*.

I found this by disabling the garbage collector: then the program
crashes in C2py.c at the instruction "Py_DECREF(pArgs);"

----------
priority: release blocker -> normal
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker 

__________________________________

---------------------------------
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.

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

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

From report at bugs.python.org  Sat Apr  5 19:03:53 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 17:03:53 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207415032.95.0.25662657047.issue2541@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The segment "use different rules for interpreting backslash escape
sequences." should be killed entirely, and the whole rule told here.

Also, a few paragraphs later there are more references to raw strings,
e.g. "When an ``'r'`` or ``'R'`` prefix is used in a string literal,"
which need to be fixed too.

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

From report at bugs.python.org  Sat Apr  5 19:28:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 17:28:58 +0000
Subject: [issue2545] sphinx.ext.autodoc fails to expand tabs in docstrings
In-Reply-To: <1207283352.64.0.672793099333.issue2545@psf.upfronthosting.co.za>
Message-ID: <1207416538.86.0.140819293011.issue2545@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thank you, fixed in r62171.

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

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

From report at bugs.python.org  Sat Apr  5 19:03:39 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 17:03:39 +0000
Subject: [issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2
In-Reply-To: <1207290588.7.0.806597302139.issue2547@psf.upfronthosting.co.za>
Message-ID: <1207415019.87.0.288095821076.issue2547@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> gvanrossum
nosy: +gvanrossum

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

From report at bugs.python.org  Sat Apr  5 19:35:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 17:35:59 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207406528.52.0.512033034045.issue2552@psf.upfronthosting.co.za>
Message-ID: <47F7B87A.6090805@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Yes, but the _ctypes module requires gcc, as Thomas Heller mentioned.

So the proper fix for that would be to port it to SunPro, of course.

> The 
> only thing which can be done is avoid building the _ctypes module if the 
> compiler is not gcc.

I'm not sure whether that would be much better than the status quo,
though. People would continue to complain that the ctypes module is not
built.

Why do you consider the current behaviour incorrect?

> I did look at fixing that but have not found the 
> proper way to do that.

There are several ways. One is to skip compilation in setup.py, for
which you should then determine whether the compiler is gcc. For
that, you could look at ac_compiler_gnu in configure.in, and
set a variable in Makefile.pre.in if the compiler is GCC. Then,
in setup.py, you could look for that variable as parsed from
the Makefile, and skip _ctypes accordingly.

Alternatively, you could check for __GNUC__ when compiling
ctypes, and make the compiler produce a better-understandable
#error.

Regards,
Martin

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

From report at bugs.python.org  Sat Apr  5 19:42:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 17:42:32 +0000
Subject: [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

A new pickle protocol was added to Py3k; it needs to be mentioned in the
docs.

----------
assignee: georg.brandl
components: Documentation
messages: 64993
nosy: georg.brandl
severity: normal
status: open
title: Document pickle protocol 3
versions: Python 3.0

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

From report at bugs.python.org  Sat Apr  5 19:43:00 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 05 Apr 2008 17:43:00 +0000
Subject: [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1207417380.72.0.512398566133.issue2558@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> gvanrossum
nosy: +gvanrossum

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

From report at bugs.python.org  Sat Apr  5 20:08:13 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Apr 2008 18:08:13 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207418893.48.0.135358069548.issue2552@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

For ctypes to compile with the SUN's C compiler, there is quite a bit of 
tricky asm code which needs to be ported (and tested).  Most of that is 
in libffi and that library is only supported with gcc, it seems.  But 
that is not mentioned explicitly anywhere either, see 
<http://sources.redhat.com/libffi/>.

In any case, the _ctypes module does not compile with SUN C in the 
current situation.  And it is not obvious why.  Making that clear with 
some message that ctypes (rather _ctypes) requires gcc would help and 
might be sufficient.

However, leaving the _ctypes module out altogether would be better. Just 
like other modules which have environment-specific dependencies, for 
example _tkinter.  I'll take a look how that is handled.

/Jean

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

From report at bugs.python.org  Sat Apr  5 20:44:35 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 05 Apr 2008 18:44:35 +0000
Subject: [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1207421075.31.0.626449814065.issue2558@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

There.

----------
nosy: +gpolo
Added file: http://bugs.python.org/file9950/pickle_protocol3.rst

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

From report at bugs.python.org  Sat Apr  5 20:46:59 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 05 Apr 2008 18:46:59 +0000
Subject: [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1207421219.4.0.688150446692.issue2558@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9950/pickle_protocol3.rst

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

From report at bugs.python.org  Sat Apr  5 20:48:07 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 05 Apr 2008 18:48:07 +0000
Subject: [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1207421287.04.0.177852144403.issue2558@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Sent wrong file before, this is the correct one.

----------
keywords: +patch
Added file: http://bugs.python.org/file9951/pickle_protocol3.rst.diff

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

From report at bugs.python.org  Sat Apr  5 20:52:22 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 05 Apr 2008 18:52:22 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207421542.48.0.0212496337066.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I made the requested improvements and mentioned it in NEWS. Is there
worth putting in the tutorial, since it mentions Unicode strings and raw
strings?

Added file: http://bugs.python.org/file9952/py3k_raw_strings_unicode_escapes3.patch

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

From report at bugs.python.org  Sat Apr  5 20:53:45 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Apr 2008 18:53:45 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207421625.6.0.751181856506.issue2552@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

The setup.py module contains method  detect_ctypes on line 1546 which 
handles the ctypes module building and testing.  Would it be OK to not 
do any of that on Solaris, if the compiler is not gcc? 

Also, SUN Studio 12, the latest edition of the SUN C compiler has "... 
increased GCC __asm__ and __attribute__ compatibility ...", see 
<http://blogs.sun.com/tatkar/entry/sunstudio_12_is_released> and 
<http://developers.sun.com/sunstudio/documentation/ss12/whatsnew.html>.  Maybe that one could compile libffi as is, for x86[_64]?

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

From report at bugs.python.org  Sat Apr  5 20:55:45 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 18:55:45 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1207421745.17.0.903826354083.issue2240@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Reopening. Apparently, the tests fail on FreeBSD; see

http://www.python.org/dev/buildbot/trunk/x86%20FreeBSD%203%20trunk/builds/77/step-test/0

Can you please look into this?

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

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

From report at bugs.python.org  Sat Apr  5 21:02:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 19:02:33 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207421625.6.0.751181856506.issue2552@psf.upfronthosting.co.za>
Message-ID: <47F7CCB3.3050705@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Would it be OK to not 
> do any of that on Solaris, if the compiler is not gcc? 

That would be fine.

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

From report at bugs.python.org  Sat Apr  5 21:27:08 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sat, 05 Apr 2008 19:27:08 +0000
Subject: [issue2559] atom sorting error when buiding ctypes
In-Reply-To: <1207423627.95.0.288324472301.issue2559@psf.upfronthosting.co.za>
Message-ID: <1207423627.95.0.288324472301.issue2559@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

I recently started getting the following error when building the
trunk on Mac OS X Leopard:

  ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o

I tried rm'ing my build directory then rerunning configure.  Same
result.  Here's the make output after simply removing all '*ctypes*'
files from the build directory:

% find build -name '*ctypes*' | xargs rm -r
% make
running build
running build_ext
building '_ctypes_test' extension
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I. -I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include -I. -IInclude -I./Include
-I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.o
gcc -L/Users/skip/local/lib -L/opt/local/lib -bundle -undefined
dynamic_lookup
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes_test.o
-L/Users/skip/local/lib -L/opt/local/lib -o
build/lib.macosx-10.3-i386-2.6/_ctypes_test.so
building '_ctypes' extension
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/darwin
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86
creating
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/callproc.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callproc.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/cfield.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/cfield.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/malloc_closure.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/malloc_closure.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/darwin/dlfcn_simple.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/darwin/dlfcn_simple.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/ffi.c -o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/ffi.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.c
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi64.c
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi64.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin_closure.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin_closure.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.o
-DMACOSX
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -I_ctypes/darwin -I.
-I/Users/skip/src/python/trunk/./Include
-I/Users/skip/src/python/trunk/./Mac/Include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/include
-I/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc -I.
-IInclude -I./Include -I/Users/skip/local/include -I/opt/local/include
-I/Users/skip/src/python/trunk/Include -I/Users/skip/src/python/trunk -c
/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.S
-o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.o
-DMACOSX
gcc -L/Users/skip/local/lib -L/opt/local/lib -bundle -undefined
dynamic_lookup
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/_ctypes.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callbacks.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/callproc.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/stgdict.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/cfield.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/malloc_closure.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/darwin/dlfcn_simple.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/ffi.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi_darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-ffi64.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-darwin_closure.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.o
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/powerpc/ppc64-darwin_closure.o
-L/Users/skip/local/lib -L/opt/local/lib -o
build/lib.macosx-10.3-i386-2.6/_ctypes.so
ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o
ld: atom sorting error for .LFE1 and .ffi_call_SYSV_end in
build/temp.macosx-10.3-i386-2.6/Users/skip/src/python/trunk/Modules/_ctypes/libffi_osx/x86/x86-darwin.o

----------
assignee: theller
components: ctypes
messages: 65001
nosy: skip.montanaro, theller
severity: normal
status: open
title: atom sorting error when buiding ctypes
type: compile error
versions: Python 2.6

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

From report at bugs.python.org  Sat Apr  5 21:31:37 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 05 Apr 2008 19:31:37 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1207423897.78.0.339076102781.issue2240@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I'm investigating the problem loewis, thanks for reporting. But it would
be better if someone with running FreeBSD could help me there, in case I
find the cause for this.

Also some changes were made to the original patch:

neal.norwitz did a commit where he says:
"Using a negative time causes Linux to treat it as zero, so disable that
test."
That is not what I get here, maybe a very different kernel, anyway, I
believe he could have mentioned this here.

jeffrey.yasskin said:
".. fix some flakiness in test_itimer_prof, which could detect that the
timer had reached 0 before the signal arrived announcing that fact."

followed by these changes:

signal.setitimer(self.itimer, 0.2)        (old)
signal.setitimer(self.itimer, 0.2, 0.2)   (new) -> not sure the reason
for this change

and added:
self.assertEquals(signal.getitimer(self.itimer), (0.0, 0.0)) -> this is
the same test I did for itimer_virtual, and it is a bit questionable it
is really useful at all. I don't understand how these changes matches
what he comments on his commit.

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

From report at bugs.python.org  Sat Apr  5 21:37:37 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 05 Apr 2008 19:37:37 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207424257.03.0.86192387631.issue2525@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

New patch. I added the new rule and changed the old behavior to be wrong
(a bit) less often. It may mess with code that depended on the previous
wrong results. Given the (AFAIK) exemplificative nature of this file,
this should not be a big problem.

I was going to add a complete table for US DSTs rules, but that is
already available in pytz (http://sourceforge.net/projects/pytz/ ) and
there are many special cases for different US states.

Changes:
Added a four periods approach (the three in my last msg plus "before
1967" -> no DST).
Added links to the Olson Database and pytz (which IMHO would be a great
addition to the std-lib).
Tried to explain the rules, but I think the resulting text is pretty bad.
Corrected a UnboundLocalError bug in my previous patch.

Added file: http://bugs.python.org/file9953/tzinfo-examples3.patch

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

From report at bugs.python.org  Sat Apr  5 21:55:05 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 05 Apr 2008 19:55:05 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1207425305.51.0.956014466641.issue2240@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

FreeBSD's man page for setitimer/getitimer doesn't look different from
the one in Linux. 
But.. both tests assumes the computer is not so fast that it finishes
"for i in xrange(100000000)" before the timer expire, maybe it was not
the case in that machine. Both timers (virtual and prof) are set to
expire after 0.2 seconds, and for itimer_virtual it restarts the timer 3
times before setting it to 0.
If someone has a freebsd machine (a fast one apparently) that could run
some tests and help me on this, it would be very nice.

Also sorry for various typos in my last message.

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

From report at bugs.python.org  Sat Apr  5 22:42:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 20:42:43 +0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1207428163.08.0.848276286802.issue2128@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in r62178 for Py3k. For 2.6, I don't think fixing it
is feasible.

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.6

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

From report at bugs.python.org  Sat Apr  5 23:01:14 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Apr 2008 21:01:14 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207429274.09.0.979713963492.issue2552@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Attached is one attempt to avoid building the _ctypes module if the 
compiler is not gcc: a patch for Python 2.6a2 with just 2 changes for 
setup.py based on the value of config variable CC.

----------
keywords: +patch
Added file: http://bugs.python.org/file9954/setup.py.diff

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

From report at bugs.python.org  Sat Apr  5 23:25:24 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 05 Apr 2008 21:25:24 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207430724.03.0.480149574689.issue2552@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this is incorrect; CC might also be "gcc -pipe" or
"/usr/local/bin/gcc", or some such, and would still be gcc (perhaps even
/usr/local/bin/cc).

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

From report at bugs.python.org  Sat Apr  5 23:20:32 2008
From: report at bugs.python.org (Thomas Heller)
Date: Sat, 05 Apr 2008 21:20:32 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207430431.98.0.950840061129.issue2552@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I'm curious:  Why do you insist on using the sun compiler?  Are there
political or technical reasons?

Another thing: in principle it should be possible to build a libffi
shared library with gcc, and use it in a sun-c compiled python build. 
At least this would avoid the need to port assembler code from gcc to sun c.

Python should be configured with './configure --with-systemffi' for that.

----------
nosy: +theller

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

From report at bugs.python.org  Sat Apr  5 23:46:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Sat, 05 Apr 2008 21:46:20 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207431980.47.0.69726769303.issue2541@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What about the "raw-unicode-escape" codec?
Can we leave it different from raw strings literals?

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

From report at bugs.python.org  Sun Apr  6 00:00:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 05 Apr 2008 22:00:09 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207432809.26.0.772684801158.issue2552@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

agreed, do not check to see if the string is == 'gcc'.  Instead,
actually execute the CC compiler with a -v flag and test if 'gcc
version' in output.

something like this (but split into a few statements for readability):

if 'gcc version' not in os.popen(sysconfig.get_config_vars().get('CC',
'gcc') + ' -v').read():
  # gcc is required for ctypes

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Sun Apr  6 00:19:26 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sat, 05 Apr 2008 22:19:26 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207433966.52.0.90848626663.issue2552@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Well, so much for the first attempt.  I'll see what it takes to use 
something else, like ac_compiler_gnu.  Unless Gregory's suggestion 
qualifies.

Also, I am using SUN's compilers on Solaris 10 for 'political' and some 
technical reasons.  And I am building alpha and beta Python releases 
mainly to help Python move forward.

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

From report at bugs.python.org  Sun Apr  6 02:00:02 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Sun, 06 Apr 2008 00:00:02 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207440001.95.0.079363008299.issue2292@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Updated patch: reworked some internals, and added generalization of
functioncalls after talking with Guido. *args is now considered just
another positional argument, and can occur anywhere in the positional
argument section. It can also occur more than once. Keyword arguments
now have to appear after *args, and **kwargs can now occur multiple
times at any position in the keyword argument list. test_extcall has
some examples.

(The opcodes are largely unaffected; just the order of '*args' and
keyword arguments is changed. Behind the scenes, anything after the
first '*args' argument is collapsed into a single *args, and everything
after the first '**kwargs' is likewise collapsed. The common case
(meaning any currently valid syntax, barring the 2to3 fix to swap *args
and keyword arguments) does not change in meaning or codepath, just the
complex cases are handled differently.)

This is still Work In Progress. To do: implement the dict unpacking
syntax (the mechanics are already there for keyword arguments to
functioncalls), make sure the precendence of * is correct, get more
complete test coverage, iron out the cosmetic bugs in the 2to3 fixer.

Bzr branch for this patch is
http://code.python.org/python/users/twouters/starunpack . There is also
a branch with just the functioncall changes (although the starunpack
changes are a small sprinkling on top of that branch, as it uses the
same new mechanics): http://code.python.org/python/users/twouters/funcargs .

Added file: http://bugs.python.org/file9955/starunpack.diff

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

From report at bugs.python.org  Sun Apr  6 02:02:49 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Sun, 06 Apr 2008 00:02:49 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207440169.54.0.917631858894.issue2292@psf.upfronthosting.co.za>


Changes by Thomas Wouters <thomas at python.org>:


Removed file: http://bugs.python.org/file9673/morestar.diff

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

From report at bugs.python.org  Sun Apr  6 03:42:54 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 06 Apr 2008 01:42:54 +0000
Subject: [issue1753245] Add RegEnableReflectionKey and RegDisableReflectionKey
Message-ID: <1207446173.95.0.662247608314.issue1753245@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Been sitting here for a while without comment, so:
Sending        _winreg.c
Committed revision 62180.

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

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

From report at bugs.python.org  Sun Apr  6 04:00:25 2008
From: report at bugs.python.org (Joseph Armbruster)
Date: Sun, 06 Apr 2008 02:00:25 +0000
Subject: [issue2560] removal of stale code from myreadline.c
In-Reply-To: <1207447225.31.0.495506522061.issue2560@psf.upfronthosting.co.za>
Message-ID: <1207447225.31.0.495506522061.issue2560@psf.upfronthosting.co.za>


New submission from Joseph Armbruster <JosephArmbruster at gmail.com>:

This patch removes a stale for loop from myreadline.c:

http://svn.python.org/projects/python/trunk @ 62180

----------
components: Interpreter Core
files: myreadline.patch
keywords: patch
messages: 65015
nosy: JosephArmbruster
severity: normal
status: open
title: removal of stale code from myreadline.c
versions: Python 2.6
Added file: http://bugs.python.org/file9956/myreadline.patch

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

From report at bugs.python.org  Sun Apr  6 04:40:21 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 06 Apr 2008 02:40: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: <1207449621.67.0.905420309455.issue2065@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

_wstat64 does not exist in VC6, so used GetFileAttributesW instead.

Added file: http://bugs.python.org/file9957/ocean.zip

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

From report at bugs.python.org  Sun Apr  6 05:07:16 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Apr 2008 03:07:16 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1207451236.5.0.96370591865.issue815646@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I'm reviewing this patch now and plan to commit it after some testing.

A couple comments:

I'd rename your sts variables to status.

Also FYI:

Your use of volatile on the int unlocked_count member of PyFileObject
does not do what you think it does and isn't needed here anyways.

Access to the variable is always protected by the GIL unlocking and
locking of which should cause an implicit memory barrier guaranteeing
that all other CPUs in the system will see the same value stored in the
structure in memory.

The C volatile keyword on the other hand does not guarantee this. 
volatile is useful for memory mapped IO but it makes no guarantees about
cache coherent access between multiple CPUs.  (the atomic types in the
recent C++ standards are meant for that)


Both of the above are trivial changes, no need for another patch.

----------
assignee: tim_one -> gregory.p.smith
nosy: +gregory.p.smith
versions: +Python 3.0

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

From report at bugs.python.org  Sun Apr  6 06:34:33 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 06 Apr 2008 04:34:33 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207456472.83.0.613337666388.issue2292@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

What's dict unpacking? I hope it's not an implementation of this sad
idea posted recently:

{'a': x, 'b': y} = {'a': 42, 'b': 'hello'}  # Same as x, y = 42, 'hello'

:-)

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

From report at bugs.python.org  Sun Apr  6 06:46:55 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 06 Apr 2008 04:46:55 +0000
Subject: [issue508157] urllib.urlopen results.readline is slow
Message-ID: <1207457215.08.0.195886138498.issue508157@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

Well, this issue is still hurting performance, the most recent example
was with a developer of a download manager.

I suggest adding a buffer size argument to HTTPResponse.__init__
(defaulting to zero), along with docs that explain the problems that may
arise from using a buffer. If there's any chance this might be accepted,
I'll write a patch.

----------
nosy: +ajaksu2
versions: +Python 2.6 -Python 2.2

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

From report at bugs.python.org  Sun Apr  6 07:41:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Apr 2008 05:41:53 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207433966.52.0.90848626663.issue2552@psf.upfronthosting.co.za>
Message-ID: <47F8629D.7050002@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Well, so much for the first attempt.  I'll see what it takes to use 
> something else, like ac_compiler_gnu.  Unless Gregory's suggestion 
> qualifies.

I would prefer to see the configure test for gcc be recorded and
passed through, over trying to detect gcc from its -v output, yes.
Who knows what other compilers will do when passed the -v option?

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

From report at bugs.python.org  Sun Apr  6 08:07:38 2008
From: report at bugs.python.org (Aren Olson)
Date: Sun, 06 Apr 2008 06:07:38 +0000
Subject: [issue508157] urllib.urlopen results.readline is slow
Message-ID: <1207462058.51.0.129932719068.issue508157@psf.upfronthosting.co.za>


Aren Olson <reacocard at gmail.com> added the comment:

I can indeed confirm that this change creates a HUGE speed difference.
Using the code found at [1] with python2.5 and apache2 under Ubuntu,
changing the buffer size to 4096 improved the time needed to download
10MB from 15.5s to 1.78s, almost 9x faster. Repeat downloads of the same
file (meaning the server now has the file cached in memory), yield times
of 15.5s and 0.03s, a 500x improvement. When fetching from a server on
the local network, rather than from localhost, these times become 15.5s
and 0.9s in both cases, a 17x speedup. Real-world situations will likely
be a mix of these, however it is safe to say the speed improvement will
be substantial. Adding an option to adjust the buffer size would be very
welcome, though the default value should still be zero, to avoid the
issues already mentioned.

[1] - http://pastebin.ca/973578

----------
nosy: +reacocard

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

From report at bugs.python.org  Sun Apr  6 08:25:11 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Apr 2008 06:25:11 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1207463111.88.0.471066510324.issue815646@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I've attached my patch that I want to commit.  The main change from
filethread4 is some cleanup in file_test to make it run a lot faster and
add verbose mode output to indicate how well it is actually testing the
problem (counting the times that close raises IOError).

One concern holding up my commit:

Will this test pass on windows?  It is opening and closing the same file
in 'w+' mode from multiple threads of the same process at once.

Can someone with a windows dev environment please apply this patch and
test it.  If it dislikes the above file behavior, can you propose a fix
for it (set windows file non-exclusive flags or whatever you're supposed
to do... the worse alternative would be to use a new filename on each
open but that could cause a nightmare of thousands of new files being
created by the test which then have to be cleaned up)?

thanks,
-gps

Added file: http://bugs.python.org/file9958/filethread4-gps01.patch

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

From report at bugs.python.org  Sun Apr  6 08:38:08 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Sun, 06 Apr 2008 06:38:08 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207463888.96.0.810361734241.issue2292@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

No, it's what you asked for in msg63551:

> How about dicts?
> kwds = {'z': 0, 'w': 12}
> {'x': 1, 'y': 2, **kwds}  # {'x': 1, 'y': 2, 'z': 0, 'w': 12}

(unpacking of dicts in dicts.)

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

From report at bugs.python.org  Sun Apr  6 09:31:59 2008
From: report at bugs.python.org (Werner Arnhold)
Date: Sun, 06 Apr 2008 07:31:59 +0000
Subject: [issue2561] Instance remembers old values from former life
In-Reply-To: <1207467119.29.0.203167301523.issue2561@psf.upfronthosting.co.za>
Message-ID: <1207467119.29.0.203167301523.issue2561@psf.upfronthosting.co.za>


New submission from Werner Arnhold <warnhold at zedat.fu-berlin.de>:

I don't know if it is a bug or a feature but the result seems to be
wrong for me: A constructor argument remembers its values from the last call

----------
files: class_with_listparamdefault.py
messages: 65024
nosy: warnhold
severity: normal
status: open
title: Instance remembers old values from former life
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9959/class_with_listparamdefault.py

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

From report at bugs.python.org  Sun Apr  6 10:30:51 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Apr 2008 08:30:51 +0000
Subject: [issue2561] Instance remembers old values from former life
In-Reply-To: <1207467119.29.0.203167301523.issue2561@psf.upfronthosting.co.za>
Message-ID: <1207470651.85.0.20913503608.issue2561@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Yes, this is expected. Default values are only evaluated once, at
function creation time. If you need to have a mutable default argument
that is assigned to something and changed, use something like this:

def f(arg=None):
    if arg is None:
        arg = []
    ...

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

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

From report at bugs.python.org  Sun Apr  6 10:39:49 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Apr 2008 08:39:49 +0000
Subject: [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1207471189.36.0.50320949637.issue2558@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed the patch in r62181.

----------
assignee: gvanrossum -> georg.brandl
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sun Apr  6 10:43:47 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Apr 2008 08:43:47 +0000
Subject: [issue980098] Module to dynamically generate structseq objects
Message-ID: <1207471427.13.0.549824240871.issue980098@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I believe this is obsolete now we have namedtuple?

----------
assignee:  -> rhettinger
nosy: +georg.brandl, rhettinger

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

From report at bugs.python.org  Sun Apr  6 11:47:19 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Apr 2008 09:47:19 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

If I try to put my name in the Author field as a string field, 
it will brake because distutils makes the assumption that 
the fields are string encoded in ascii, before it decodes
it into unicode, then encode it in utf8 to send the data.

See in distutils.command.register.post_to_server :

value = unicode(value).encode("utf-8")


One way to avoid this error is to provide unicode for all field,
but will fail farther if setuptools is used, because
this other package makes the assumption that the fields *are* strings::

self.run_command('egg_info')
...
distutils/dist.py", line 1047, in write_pkg_info
    pkg_info.write('Author: %s\n' % self.get_contact() )
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 18: ordinal not in range(128)

So I guess distutils shouldn't guess that it receives ascii strings
and do a raw unicode() call, and should make the assumption that 
it receives unicode fields only.


Since many packages out there use strings, I have left a unicode()
call in my patch, together with a warning. 

test provided.

----------
components: Distutils
files: unicode.patch
keywords: patch
messages: 65028
nosy: tarek
severity: normal
status: open
title: Cannot use non-ascii letters in disutils if setuptools is used.
type: crash
versions: Python 2.6
Added file: http://bugs.python.org/file9960/unicode.patch

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

From report at bugs.python.org  Sun Apr  6 12:14:28 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Apr 2008 10:14:28 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207476868.71.0.42196641493.issue2562@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file9960/unicode.patch

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

From report at bugs.python.org  Sun Apr  6 12:14:38 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Apr 2008 10:14:38 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207476878.73.0.108433389551.issue2562@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Added file: http://bugs.python.org/file9961/unicode.patch

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

From report at bugs.python.org  Sun Apr  6 12:40:52 2008
From: report at bugs.python.org (Trent Nelson)
Date: Sun, 06 Apr 2008 10:40:52 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1207478452.35.0.397365653847.issue815646@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Patched and tested on one of my buildbots, test_file passes without 
error with your latest Patch Greg.

----------
nosy: +Trent.Nelson

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

From report at bugs.python.org  Sun Apr  6 13:06:52 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Sun, 06 Apr 2008 11:06:52 +0000
Subject: [issue2515] Segfault while operating on closed sqlite3 cursor.
In-Reply-To: <1206895424.89.0.255529765862.issue2515@psf.upfronthosting.co.za>
Message-ID: <1207480012.44.0.398067004552.issue2515@psf.upfronthosting.co.za>


Gerhard H?ring <gh at ghaering.de> added the comment:

Thanks for reporting this. It's fixed in r62183 in the 2.5 maintenance
branch.

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

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

From report at bugs.python.org  Sun Apr  6 13:09:27 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 06 Apr 2008 11:09:27 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1207480167.12.0.0854383592567.issue815646@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok Greg, I wasn't sure locking/unlocking the GIL would create a memory
barrier but it sounds logical after all. Your patch looks fine to me.

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

From report at bugs.python.org  Sun Apr  6 13:21:28 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sun, 06 Apr 2008 11:21:28 +0000
Subject: [issue980098] Module to dynamically generate structseq objects
Message-ID: <1207480888.7.0.085599259828.issue980098@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


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

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

From report at bugs.python.org  Sun Apr  6 15:21:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Apr 2008 13:21:07 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207488066.97.0.375041822196.issue2562@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

The official supported way for non-ASCII characters in distutils is to
use Unicode strings. If anything else fails, that's not a bug.

IIUC, in this case, it's setuptools that fails, not distutils. Assuming
I understood correctly, I'm closing this as won't-fix/3rd party.

----------
nosy: +loewis
resolution:  -> wont fix
status: open -> closed
versions: +3rd party -Python 2.6

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

From report at bugs.python.org  Sun Apr  6 15:43:34 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Apr 2008 13:43:34 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207489414.12.0.434488778899.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

In that case, distutils should not do a unicode() call over each field
passed before .encode('utf8') is called, because it makes the assumption
that string type can be used.

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

From report at bugs.python.org  Sun Apr  6 15:52:29 2008
From: report at bugs.python.org (Mark Hammond)
Date: Sun, 06 Apr 2008 13:52:29 +0000
Subject: [issue2563] embed manifest in windows extensions
In-Reply-To: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>
Message-ID: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

The move to vs2008 has caused .manifest files to be created next to
distutils created extensions modules, rather than being embedded as
recommended by Microsoft.

See http://msdn2.microsoft.com/en-us/library/ms235591(VS.80).aspx

The attached patch achieves this by telling the compiler to generate the
manifest in the temp dir, them embeds that manifest using mt.exe

Adding Christian for comment (hopefully the correct Christian this time
  - sorry about that :)

----------
assignee: mhammond
components: Distutils
files: embed_manifest.patch
keywords: patch, patch
messages: 65034
nosy: mhammond, tiran
severity: normal
status: open
title: embed manifest in windows extensions
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file9962/embed_manifest.patch

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

From report at bugs.python.org  Sun Apr  6 15:59:09 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Apr 2008 13:59:09 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207490349.49.0.230981456762.issue2562@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I don't understand. It is *certainly* allowed to use byte strings for
these data, as long as they are ASCII. The Unicode requirement exists
only for non-ASCII characters, and distutils makes explicit, deliberate
use of the default encoding here (hoping that nobody changed it away
from ASCII).

There are tons of setup.py files out there that use plain byte strings,
and there is no reason to break them, e.g. by mandating that the string
is Unicode already.

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

From report at bugs.python.org  Sun Apr  6 16:05:23 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 06 Apr 2008 14:05:23 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207490723.4.0.346832933812.issue2552@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Agreed.  In addition, gcc -v writes to stderr and catching the output 
requires redirecting stderr or using os.popen3 or -4.  The latter fail 
since the select module (needed by subprocess) is still missing at that 
time.

Going back to Thomas' comments and before getting into implementation 
details, the best way to address the issue might be the following.

If the compiler is not gcc then config option --with-system-ffi *must* 
be specified (and a libffi library must exist).

If option --with-system-ffi is not specified and if the compiler is not 
gcc, raise an error.

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

From report at bugs.python.org  Sun Apr  6 16:14:09 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Apr 2008 14:14:09 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207491249.39.0.102895764914.issue2530@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching a draft.

----------
keywords: +patch
Added file: http://bugs.python.org/file9963/io_doc.patch

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

From report at bugs.python.org  Sun Apr  6 16:14:13 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Apr 2008 14:14:13 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207491253.26.0.301609934284.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok I see what you mean, thanks for the explanation

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

From report at bugs.python.org  Sun Apr  6 16:25:26 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Apr 2008 14:25:26 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207490723.4.0.346832933812.issue2552@psf.upfronthosting.co.za>
Message-ID: <47F8DD53.70405@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If option --with-system-ffi is not specified and if the compiler is not 
> gcc, raise an error.

Up to here, it all sounded fine. What do you mean by error? Abort?
That should not happen. Instead, setup.py skips modules if it doesn't
find the proper prerequisites - which here is the pre-existing FFI
implementation.

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

From report at bugs.python.org  Sun Apr  6 16:41:31 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 06 Apr 2008 14:41:31 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207492891.04.0.64514927588.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

oh, hold one, it is more complicated in fact :)

setuptools calls DistributionMetadata.dist.write_pkg_file()
method to write the .egg-info file.

This method make the assertion that the metadata fields are string
so it is not setuptools fault.

This code fail the same way:

dist = Distribution(attrs={'author': u'Mister Caf?'})
dist.metadata.write_pkg_file(file)

 
So I guess the patch needs to be done in
distutils.dist.DistributionMetadata, so it checks upon
the type of field before it runs:

file.write('Author: %s\n' % self.get_contact() ) 

That what I meant when I said that distutils should
decide wheter it works with unicode or str for this fields.

I can re-write a new patch if you agree on this

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

From report at bugs.python.org  Sun Apr  6 16:47:15 2008
From: report at bugs.python.org (Jean Brouwers)
Date: Sun, 06 Apr 2008 14:47:15 +0000
Subject: [issue2552] test_ctypes failed Python 2.6a2 Solaris 10 SUN C
In-Reply-To: <1207339311.94.0.138275170862.issue2552@psf.upfronthosting.co.za>
Message-ID: <1207493235.68.0.627196995233.issue2552@psf.upfronthosting.co.za>


Jean Brouwers <MrJean1 at Gmail.com> added the comment:

Instead of  ... raise an error, it should read  ... report the _ctypes 
module as missing, do not run any tests, etc.

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

From report at bugs.python.org  Sun Apr  6 18:05:15 2008
From: report at bugs.python.org (=?utf-8?q?Taavi_Rep=C3=A4n?=)
Date: Sun, 06 Apr 2008 16:05:15 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
Message-ID: <1207497914.96.0.303661363034.issue2564@psf.upfronthosting.co.za>


Changes by Taavi Rep?n <trepan at gmail.com>:


----------
components: None
nosy: trepan
severity: normal
status: open
title: Python hangs on FreeBSD7 in test_capi
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sun Apr  6 18:07:36 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 06 Apr 2008 16:07:36 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207498056.4.0.538942449773.issue2530@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Looks good already! I can't review the full text now, but can you move
member documentation into the indented block for the class? (I know
other documents don't do this, but this is a legacy and I'd like new
documents to adopt this style.)

Additionally, the function description style is inconsistent ("Flushes
the stream" vs "Return this").

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

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

From report at bugs.python.org  Sun Apr  6 18:08:36 2008
From: report at bugs.python.org (=?utf-8?q?Taavi_Rep=C3=A4n?=)
Date: Sun, 06 Apr 2008 16:08:36 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
In-Reply-To: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>
Message-ID: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>


New submission from Taavi Rep?n <trepan at gmail.com>:

When doing import.test_autotest, test_capi hangs.
It seems that threads 1,2,3 are trying to acquire import lock, which is
owned by thread 4, which is trying to lock some other lock.

Python 2.5.2 (r252:60911, Apr  6 2008, 17:28:23) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7

Added file: http://bugs.python.org/file9964/backtrace

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

From report at bugs.python.org  Sun Apr  6 18:32:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Apr 2008 16:32:14 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207499534.76.0.0397032367074.issue2530@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. attaching an improved patch. Do you think information about
indenting classes and such can be added to the style guide? It'd be very
helpful.

Added file: http://bugs.python.org/file9965/io_doc2.patch

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

From report at bugs.python.org  Sun Apr  6 18:50:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 06 Apr 2008 16:50:36 +0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1207500636.97.0.579231933389.issue2128@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

MvL's recent commit creates compiler warnings for Unicode UCS4 for the
same reason as #2388.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sun Apr  6 19:09:05 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Apr 2008 17:09:05 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207501745.7.0.678709427787.issue2562@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I agree there is a bug in distutils. Before we proceed, I think
distutils-sig needs to be consulted. My proposal would be the one I
suggested earlier: all strings should either be Unicode or ASCII-only
byte strings. This contradicts to the documentation that says that none
of the strings must be Unicode, so it would be an incompatible change
(and would indeed likely break packages that currently use UTF-8, and
sdist, but never register)

----------
resolution: wont fix -> 
status: closed -> open
versions: +Python 2.6 -3rd party

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

From report at bugs.python.org  Sun Apr  6 19:17:39 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 06 Apr 2008 17:17:39 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207502259.36.0.609219531367.issue2562@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

As a follow-up: for compatibility, it might be possible to support
either Unicode or arbitrary plain strings in write_pkg_file. In 3k, such
support can then be dropped.

As that constitutes a new feature, it shouldn't be applied to 2.5.

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

From report at bugs.python.org  Sun Apr  6 20:35:19 2008
From: report at bugs.python.org (Johannes Hoff)
Date: Sun, 06 Apr 2008 18:35:19 +0000
Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition
In-Reply-To: <1192727177.86.0.467865548072.issue1297@psf.upfronthosting.co.za>
Message-ID: <1207506919.71.0.561124070539.issue1297@psf.upfronthosting.co.za>


Johannes Hoff <johshoff+python at gmail.com> added the comment:

This is still the case with Visual Studio Express 2008. It can be fixed 
by downloading the Windows SDK, though it would be nicer if this was 
not necessary.
Download link: http://blogs.msdn.com/windowssdk/archive/2008/02/07/
windows-sdk-rtms.aspx
I recommend the "web install", since only the headers and libraries are 
needed, not the whole 1GB blob that comes with it.

Amaury: The file python.hpp, thus basetsd.h, is used by boost-python.

----------
nosy: +johanneshoff

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

From report at bugs.python.org  Sun Apr  6 20:17:37 2008
From: report at bugs.python.org (Paul Davis)
Date: Sun, 06 Apr 2008 18:17:37 +0000
Subject: [issue2515] Segfault while operating on closed sqlite3 cursor.
In-Reply-To: <1207480012.44.0.398067004552.issue2515@psf.upfronthosting.co.za>
Message-ID: <e2111bbb0804061110i18322ef8yd27f7a869059f209@mail.gmail.com>


Paul Davis <paul.joseph.davis at gmail.com> added the comment:

No prob.

On Sun, Apr 6, 2008 at 7:06 AM, Gerhard H?ring <report at bugs.python.org> wrote:
>
>  Gerhard H?ring <gh at ghaering.de> added the comment:
>
>  Thanks for reporting this. It's fixed in r62183 in the 2.5 maintenance
>  branch.
>
>  ----------
>  resolution:  -> fixed
>  status: open -> closed
>
>
>
>  __________________________________
>  Tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue2515>
>  __________________________________
>

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

From report at bugs.python.org  Sun Apr  6 23:20:27 2008
From: report at bugs.python.org (Trent Nelson)
Date: Sun, 06 Apr 2008 21:20:27 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207516827.65.0.719453068499.issue2550@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

[Updating the issue with relevant mailing list conversation]
Interesting results!  I committed the patch to test_socket.py in 
r62152.  I was expecting all other platforms except for Windows to 
behave consistently (i.e. pass).  That is, given the following:

        import socket
        host = '127.0.0.1'
        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock.bind((host, 0))
        port = sock.getsockname()[1]
        sock.close()
        del sock

        sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        sock1.bind((host, port))
        sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        sock2.bind((host, port))
        ^^^^

....the second bind should fail with EADDRINUSE, at least according to 
the 'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 
7.5 of Stevens' UNIX Network Programming Volume 1 (2nd Ed):

"With TCP, we are never able to start multiple servers that bind
 the same IP address and same port: a completely duplicate binding.
 That is, we cannot start one server that binds 198.69.10.2 port 80
 and start another that also binds 198.69.10.2 port 80, even if we
 set the SO_REUSEADDR socket option for the second server."

The results: both Windows *and* Linux fail the patched test; none of 
the buildbots for either platform encountered an EADDRINUSE 
socket.error after the second bind().  FreeBSD, OS X, Solaris and Tru64 
pass the test -- EADDRINUSE is raised on the second bind.  (Interesting 
that all the ones that passed have a BSD lineage.)

I've just reverted the test in r62156 as planned.  The real issue now 
is that there are tests that are calling test_support.bind_socket() 
with the assumption that the port returned by this method is 'unbound', 
when in fact, the current implementation can't guarantee this:

def bind_port(sock, host='', preferred_port=54321):
    for port in [preferred_port, 9907, 10243, 32999, 0]:
        try:
            sock.bind((host, port))
            if port == 0:
                port = sock.getsockname()[1]
            return port
        except socket.error, (err, msg):
            if err != errno.EADDRINUSE:
                raise
            print >>sys.__stderr__, \
                '  WARNING: failed to listen on port %d, trying 
another' % port

This logic is only correct for platforms other than Windows and Linux.  
I haven't looked into all the networking test cases that rely on 
bind_port(), but I would think an implementation such as this would be 
much more reliable than what we've got for returning an unused port:

def bind_port(sock, host='127.0.0.1', *args):
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.bind((host, 0))
    port = s.getsockname()[1]
    s.close()
    del s

    sock.bind((host, port))
    return port

Actually, FWIW, I just ran a full regrtest.py against trunk on Win32 
with this change in place and all the tests still pass.

Thoughts?

    Trent.

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

From report at bugs.python.org  Sun Apr  6 23:21:03 2008
From: report at bugs.python.org (Trent Nelson)
Date: Sun, 06 Apr 2008 21:21:03 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207516863.78.0.100701112838.issue2550@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

[Updating issue with mailing list discussion; Jean-Paul's reply]
On Fri, 4 Apr 2008 13:24:49 -0700, Trent Nelson <tnelson at onresolve.com> 
wrote:
>Interesting results!  I committed the patch to test_socket.py in 
r62152.  I was expecting all other platforms except for Windows to 
behave consistently (i.e. pass).  That is, given the following:
>
>        import socket
>        host = '127.0.0.1'
>        sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>        sock.bind((host, 0))
>        port = sock.getsockname()[1]
>        sock.close()
>        del sock
>
>        sock1 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>        sock1.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>        sock1.bind((host, port))
>        sock2 = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>        sock2.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
>        sock2.bind((host, port))
>        ^^^^
>
>....the second bind should fail with EADDRINUSE, at least according to 
the 'SO_REUSEADDR and SO_REUSEPORT Socket Options' section in chapter 
7.5 of Stevens' UNIX Network Programming Volume 1 (2nd Ed):
>
>"With TCP, we are never able to start multiple servers that bind
> the same IP address and same port: a completely duplicate binding.
> That is, we cannot start one server that binds 198.69.10.2 port 80
> and start another that also binds 198.69.10.2 port 80, even if we
> set the SO_REUSEADDR socket option for the second server."
>
>The results: both Windows *and* Linux fail the patched test; none of 
the buildbots for either platform encountered an EADDRINUSE 
socket.error after the second bind().  FreeBSD, OS X, Solaris and Tru64 
pass the test -- EADDRINUSE is raised on the second bind.  (Interesting 
that all the ones that passed have a BSD lineage.)

Notice that the quoted text explains that you cannot start multiple 
servers
that etc.  Since you didn't call listen on either socket, it's arguable 
that
you didn't start any servers, so there should be no surprise regarding 
the
behavior.  Try adding listen calls at various places in the example and
you'll see something different happen.

FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote on
Linux/BSD/UNIX/etc.  On Windows, however, that option actually means
something quite different.  It means that the address should be stolen 
from
any process which happens to be using it at the moment.

There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think,
which, AIUI, makes it impossible for another process to steal the port
using SO_REUSEADDR.

Hope this helps,

Jean-Paul

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

From report at bugs.python.org  Sun Apr  6 23:21:35 2008
From: report at bugs.python.org (Trent Nelson)
Date: Sun, 06 Apr 2008 21:21:35 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207516895.54.0.554676067958.issue2550@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

[Updating issue with mailing list discussion; my reply to Jean-Paul]
> >"With TCP, we are never able to start multiple servers that bind
> > the same IP address and same port: a completely duplicate binding.
> > That is, we cannot start one server that binds 198.69.10.2 port 80
> > and start another that also binds 198.69.10.2 port 80, even if we
> > set the SO_REUSEADDR socket option for the second server."

> Notice that the quoted text explains that you cannot start multiple
> servers that etc.  Since you didn't call listen on either socket, it's
> arguable that you didn't start any servers, so there should be no
> surprise regarding the behavior.  Try adding listen calls at various
> places in the example and you'll see something different happen.

I agree in principle, Stevens says nothing about what happens if you 
*do* try and bind two sockets on two identical host/port addresses.  
Even so, test_support.bind_port() makes an assumption that bind() will 
raise EADDRINUSE if the port is not available, which, as has been 
demonstrated, won't be the case on Windows or Linux.

> FWIW, AIUI, SO_REUSEADDR behaves just as described in the above quote
> on Linux/BSD/UNIX/etc.  On Windows, however, that option actually 
means
> something quite different.  It means that the address should be stolen
> from any process which happens to be using it at the moment.

Probably explains why the python process wedges when this happens on 
Windows...

> There is another option, SO_EXCLUSIVEADDRUSE, only on Windows I think,
> which, AIUI, makes it impossible for another process to steal the port
> using SO_REUSEADDR.

Nod, if SO_EXCLUSIVEADDRUSE is used instead in the code I posted, 
Windows raises EADDRINUSE on the second bind().  I don't have access to 
any Linux boxes at the moment, so I can't test what sort of error is 
raised with the example I posted if listen() and accept() are called on 
the two sockets bound to identical addresses.  Can anyone else shed 
some light on this?  I'd be interested in knowing if the process wedges 
on Linux as badly as it does on Windows (to the point where it's not 
respecting ctrl-c or sigkill).


        Trent.

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

From report at bugs.python.org  Sun Apr  6 23:22:39 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sun, 06 Apr 2008 21:22:39 +0000
Subject: [issue2548] Undetected error in exception handling
In-Reply-To: <1207297002.01.0.980429495002.issue2548@psf.upfronthosting.co.za>
Message-ID: <1207516959.33.0.938671641238.issue2548@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

I've identified rev58032 [1] as the one introducing this issue. It's
Brett's code, fixing a nasty crasher and adding a pre-built exception
(PyExc_RecursionErrorInst).


[1] http://svn.python.org/view?rev=58032&view=rev

P.S.: Thanks Thomas for correctly identifying an issue I mis-reported :)

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

From report at bugs.python.org  Sun Apr  6 23:25:03 2008
From: report at bugs.python.org (Trent Nelson)
Date: Sun, 06 Apr 2008 21:25:03 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207517103.11.0.969453173308.issue2550@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

I've attached another patch that fixes test_support.bind_port() as well 
as a bunch of files that used that method.  The new implementation 
always uses an ephemeral port in order to elicit an unused port for 
subsequent binding.  Tested on Windows 32-bit & x64 and FreeBSD 6.2.  
Would like to apply sooner rather than later unless anyone has any 
objections as it'll fix my two Windows buildbots that are on the same 
machine from both hanging if they test asynchat at the same time (which 
happens more often than you'd think).

Added file: http://bugs.python.org/file9966/trunk.2550.patch

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

From report at bugs.python.org  Mon Apr  7 00:04:55 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Sun, 06 Apr 2008 22:04:55 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207519495.89.0.0210849861861.issue2550@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Trent, go ahead and try this out.  We should definitely be moving in
this direction.  So I'd rather fix the problem than keep suffering with
the current problems of not being able to run the test suite
concurrently.  I think bind_port might be documented, so you should
update the docs if so.  Also, please add a Misc/NEWS entry.

----------
nosy: +nnorwitz
resolution:  -> accepted

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

From report at bugs.python.org  Mon Apr  7 01:14:17 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Apr 2008 23:14:17 +0000
Subject: [issue815646] thread unsafe file objects cause crash
Message-ID: <1207523657.11.0.87532716594.issue815646@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Committed to trunk in revision 62195.

Misc/NEWS entry added.

I also added two new C API functions: PyFile_IncUseCount and
PyFile_DecUseCount along with documentation.  They should be used by any
C extension code that uses PyFile_AsFile and wants to make use of the
returned FILE* with the GIL released.

The net effect of not using them is no change from the existing behavior
(crashes would be possible) for those C extension modules.

----------
resolution:  -> accepted
status: open -> closed
versions:  -Python 3.0

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

From report at bugs.python.org  Mon Apr  7 01:23:10 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 06 Apr 2008 23:23:10 +0000
Subject: [issue595601] file (& socket) I/O are not thread safe
Message-ID: <1207524190.17.0.430296849206.issue595601@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Fix committed to trunk in revision 62195 via Issue 815646

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

From report at bugs.python.org  Mon Apr  7 02:30:04 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Apr 2008 00:30:04 +0000
Subject: [issue2565] Change 'type' to 'class' in repr/str(builtin-class)
In-Reply-To: <1207528202.86.0.529083096398.issue2565@psf.upfronthosting.co.za>
Message-ID: <1207528202.86.0.529083096398.issue2565@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

>From py3 devel list today:
------------------------------------------------------------------------
>  r23331 | gvanrossum | 2001-09-25 05:56:29 +0200 (Di, 25 Sep 2001) | 5
lines
>
>  Change repr() of a new-style class to say <class 'ClassName'> rather
>  than <type 'ClassName'>.  Exception: if it's a built-in type or an
>  extension type, continue to call it <type 'ClassName>.
------------------------------------------------------------------------
Well, if we're going to break user code, 3.0 is the time to do it. :-)

----------
components: Extension Modules, Interpreter Core
keywords: easy
messages: 65058
nosy: tjreedy
severity: normal
status: open
title: Change 'type' to 'class' in repr/str(builtin-class)
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 04:00:20 2008
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 07 Apr 2008 02:00:20 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1206860484.75.0.951116061983.issue2513@psf.upfronthosting.co.za>
Message-ID: <1207533620.72.0.424879285478.issue2513@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Checked in r62197, including the patch from Thomas.  Note I expanded the
patch to the distutils doc (noting you need to build Python itself for
the target platform before it works) and added a short entry to Misc/NEWS

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

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

From report at bugs.python.org  Mon Apr  7 05:08:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 03:08:53 +0000
Subject: [issue2388] Compiler warnings when using UCS4
In-Reply-To: <1205848812.38.0.436275134314.issue2388@psf.upfronthosting.co.za>
Message-ID: <1207537733.35.0.633151834766.issue2388@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in r62199

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

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

From report at bugs.python.org  Mon Apr  7 05:27:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 03:27:28 +0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1207538848.54.0.444771724154.issue2128@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What warnings precisely are you seeing? I didn't see anything in the 3k
branch (not even for #2388, as PyErr_Format doesn't have the GCC format
attribute in 3k, unlike 2.x).

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

From report at bugs.python.org  Mon Apr  7 05:29:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 03:29:53 +0000
Subject: [issue2565] Change 'type' to 'class' in repr/str(builtin-class)
In-Reply-To: <1207528202.86.0.529083096398.issue2565@psf.upfronthosting.co.za>
Message-ID: <1207538993.61.0.230597348549.issue2565@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

So which one should it be: type or class?

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

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

From report at bugs.python.org  Mon Apr  7 05:29:55 2008
From: report at bugs.python.org (delimy)
Date: Mon, 07 Apr 2008 03:29:55 +0000
Subject: [issue2566] Py3.0a4 wsgiref simple_server failed to start
In-Reply-To: <1207538995.31.0.628770173127.issue2566@psf.upfronthosting.co.za>
Message-ID: <1207538995.31.0.628770173127.issue2566@psf.upfronthosting.co.za>


New submission from delimy <delimy at exoweb.net>:

Here's the most recent traceback:

  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
116, in finish_response
    self.write(data)
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
199, in write
    self.send_headers()
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
255, in send_headers
    self.send_preamble()
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
178, in send_preamble
    self._write('HTTP/%s %s\r\n' % (self.http_version,self.status))
  File "/home/delimy/temp/Python-3.0a4/Lib/wsgiref/handlers.py", line
385, in _write
    self.stdout.write(data)
  File "/home/delimy/temp/Python-3.0a4/Lib/socket.py", line 222, in write
    return self._sock.send(b)
TypeError: send() argument 1 must be bytes or read-only buffer, not str

It should convert str to bytes before write to stdout.

----------
components: Library (Lib)
messages: 65063
nosy: delimy
severity: normal
status: open
title: Py3.0a4 wsgiref simple_server failed to start
type: crash
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 06:31:43 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Mon, 07 Apr 2008 04:31:43 +0000
Subject: [issue2565] Change 'type' to 'class' in repr/str(builtin-class)
In-Reply-To: <1207528202.86.0.529083096398.issue2565@psf.upfronthosting.co.za>
Message-ID: <1207542702.7.0.588451206881.issue2565@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Finish the change from 'type' to 'class'
(See carefully written title ;-)

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

From report at bugs.python.org  Mon Apr  7 07:39:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 05:39:52 +0000
Subject: [issue2567] Section "New-style and classic classes" needs to be
	removed/rewritten
In-Reply-To: <1207546792.82.0.239101665386.issue2567@psf.upfronthosting.co.za>
Message-ID: <1207546792.82.0.239101665386.issue2567@psf.upfronthosting.co.za>


New submission from Martin v. L?wis <martin at v.loewis.de>:

There are no classic classes anymore in Python.

----------
assignee: georg.brandl
components: Documentation
messages: 65065
nosy: georg.brandl, loewis
severity: normal
status: open
title: Section "New-style and classic classes" needs to be removed/rewritten
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 07:44:15 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 05:44:15 +0000
Subject: [issue2565] Change 'type' to 'class' in repr/str(builtin-class)
In-Reply-To: <1207528202.86.0.529083096398.issue2565@psf.upfronthosting.co.za>
Message-ID: <1207547055.1.0.177783943432.issue2565@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is now fixed in r62203.

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

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

From report at bugs.python.org  Mon Apr  7 08:53:13 2008
From: report at bugs.python.org (Anton Fedorov)
Date: Mon, 07 Apr 2008 06:53:13 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>


New submission from Anton Fedorov <datacompboy at call2ru.com>:

"%S	Second as a decimal number [00,61].	(2)
(2) The range really is 0 to 61; this accounts for leap seconds and the 
(very rare) double leap seconds."

That is wrong. There NEVER can be two leap seconds in one moment, since UTC 
time keep the difference between UTC and UT1 from exceeding ?0.9 s.

Leap seconds occur only at the end of a UTC month, and have only ever been 
inserted at the end of June 30 or December 31.

So, 61 is wrong, real seconds range from 0 to 60 inclusive.

----------
components: Library (Lib)
messages: 65067
nosy: datacompboy
severity: normal
status: open
title: Seconds range in time unit
type: behavior

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

From report at bugs.python.org  Mon Apr  7 09:42:06 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Apr 2008 07:42:06 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1207554126.92.0.939703562138.issue2538@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

This patch looks good.

One question: in Objects/abstract.c in PyBuffer_FillInfo, why is it even
testing for the PyBUF_LOCK flag at all?  PEP 3118 says its valid for
both reading and writing (if the underlying object supports locked access).

BTW, I is someone is going to merge any py3k buffer api related changes
back into the backport that is in 2.6?

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

From report at bugs.python.org  Mon Apr  7 10:06:27 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Apr 2008 08:06:27 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207555587.88.0.937435852453.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

ok, I'll summarize this in distutils-sig sometime today.

If we do use Unicode, I think we might need an extra meta-data,
"encoding", that would default to "utf8", and that could be used when
the class needs to serialize the data in a file.

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

From report at bugs.python.org  Mon Apr  7 10:17:06 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 07 Apr 2008 08:17:06 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207556225.97.0.830156687309.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

adding a sample patch to show a possible implementation, and to point
the problem to people

Added file: http://bugs.python.org/file9967/unicode.metadata.patch

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

From report at bugs.python.org  Mon Apr  7 10:37:56 2008
From: report at bugs.python.org (pk)
Date: Mon, 07 Apr 2008 08:37:56 +0000
Subject: [issue2569] default_scheme in urlparse.urlparse() useless
In-Reply-To: <1207557475.98.0.0117394691364.issue2569@psf.upfronthosting.co.za>
Message-ID: <1207557475.98.0.0117394691364.issue2569@psf.upfronthosting.co.za>


New submission from pk <pk at q-leap.com>:

Hello,

the urlparse() function accepts a parameter default_scheme, to be used
if the address given does not contain one, but I cannot make
use of it, because I would expect these two returning
identical values:

>>> from urlparse import urlparse
>>> urlparse("www","http")
('http', '', 'www', '', '', '')
>>> urlparse("http://www","http")
('http', 'www', '', '', '', '')

This has been reported about six years ago but apparently
the behaviour hasn't changed.  I cannot imagine that this
really is the intended behaviour.

Regards,

    pk

----------
components: Library (Lib)
messages: 65071
nosy: pk
severity: normal
status: open
title: default_scheme in urlparse.urlparse() useless
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Mon Apr  7 10:45:11 2008
From: report at bugs.python.org (pk)
Date: Mon, 07 Apr 2008 08:45:11 +0000
Subject: [issue2569] default_scheme in urlparse.urlparse() useless
In-Reply-To: <1207557475.98.0.0117394691364.issue2569@psf.upfronthosting.co.za>
Message-ID: <1207557911.17.0.370975431567.issue2569@psf.upfronthosting.co.za>


pk <pk at q-leap.com> added the comment:

and this is the url to the old report:

http://mail.python.org/pipermail/python-list/2002-August/157171.html

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

From report at bugs.python.org  Mon Apr  7 13:54:39 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 07 Apr 2008 11:54:39 +0000
Subject: [issue2128] sys.argv is wrong for unicode strings
In-Reply-To: <1203179266.7.0.767749493824.issue2128@psf.upfronthosting.co.za>
Message-ID: <1207569279.73.0.913112101539.issue2128@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Martin, you are right that they are not from the same reason as that issue.

gcc -c -arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk/ 
-fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes 
-I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/main.o Modules/main.c
Modules/main.c: In function 'Py_Main':
Modules/main.c:478: warning: passing argument 1 of 'Py_SetProgramName'
from incompatible pointer type
Modules/main.c: In function 'Py_Main':
Modules/main.c:478: warning: passing argument 1 of 'Py_SetProgramName'
from incompatible pointer type

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

From report at bugs.python.org  Mon Apr  7 16:50:07 2008
From: report at bugs.python.org (Mark Hammond)
Date: Mon, 07 Apr 2008 14:50:07 +0000
Subject: [issue1232947] non-admin install may fail (win xp pro)
Message-ID: <1207579807.35.0.548088401845.issue1232947@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

I can repro this too using python-2.6a2.msi - after selecting "just for
me" on XP running as a non-admin user, I see an error message regarding
permissions.  On vista, I get an elevation prompt (and if I hit "allow",
installation proceeds as if I had selected 'for all users' - ie,
HKLM\Python is written, rather than HKCU, shortcuts are written to "all
users" folder, uninstall requires elevation)

I'm attaching the log after canceling installation at the elevation
prompt under Vista.

----------
nosy: +mhammond
Added file: http://bugs.python.org/file9968/python.log

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

From report at bugs.python.org  Mon Apr  7 17:10:10 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 15:10:10 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207581010.32.0.847357929738.issue2550@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't like that the patch changes the API of a function in
test_support() (in particular changing the return type; adding optional
arguments is not a problem).  This could trip up 3rd party users of this
API.  I recommend creating a new API bind_host_and_port() (or whatever
you'd like to name it) and implement the original API in terms of the
new one.  (You can even add a warning if you think the original API is
always unsafe.)

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

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

From report at bugs.python.org  Mon Apr  7 17:51:07 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Apr 2008 15:51:07 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207583467.65.0.849450197424.issue2562@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Note that 

value = unicode(value).encode("utf-8")

will also work if value is already Unicode, so a backwards compatible
fix would be to allow passing in:

 * ASCII encoded strings
 * Unicode objects

for the meta data keyword parameters and then apply unicode() to all the
meta-data arguments.

I don't think that we should support non-ASCII encodings for meta-data 
strings passed to setup().

If setuptools is broken in this respect, it needs to be fixed. Dito for
other 3rd party tools.

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

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

From report at bugs.python.org  Mon Apr  7 18:03:53 2008
From: report at bugs.python.org (Trent Nelson)
Date: Mon, 07 Apr 2008 16:03:53 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207584232.92.0.612055147909.issue2550@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

To be honest, I wasn't really happy either with having to return HOST, 
it's somewhat redundant given that all these tests should be binding 
against localhost.  What about something like this for bind_port():

def bind_port(sock, host=''):
    """Bind the socket to a free port and return the port number.
    Relies on ephemeral ports in order to ensure we are using an
    unbound port.  This is important as many tests may be running
    simultaneously, especially in a buildbot environment."""

    # Use a temporary socket object to ensure we're not 
    # affected by any socket options that have already 
    # been set on the 'sock' object we're passed. 
    tempsock = socket.socket(sock.family, sock.type)
    tempsock.bind((host, 0))
    port = tempsock.getsockname()[1]
    tempsock.close()
    del tempsock

    sock.bind((host, port))
    return port

The tests would then look something like:

HOST = 'localhost'
PORT = None

class Foo(TestCase):
    def setUp(self):
        sock = socket.socket()
        global PORT
        PORT = test_support.bind_port(sock, HOST)

So, the return value is the port bound to, no change there, but we're 
abolishing preferred_port as an optional argument, which is important, 
IMO, as none of these tests should be stipulating which port they want 
to listen on.  That's actually the root of this entire problem.

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

From report at bugs.python.org  Mon Apr  7 19:20:46 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 17:20:46 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207588845.77.0.95657032029.issue2550@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks, that's much better (though I'm not the authority on all details
of this patch).

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

From report at bugs.python.org  Mon Apr  7 19:45:12 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 17:45:12 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207590312.18.0.938269225928.issue2292@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think we should either get this into the 3.0a5 release planned for May
7, or wait for 3.1.  I'd prefer to see some kind of PEP discussion on
the python-3000 list, rather than just a BDFL approval in a tracker
issue.  I think it's a useful feature (especially now we already have
PEP 3132) but we're getting close to the release, so I'd like to see
some more eyeballs on this code...  I expect the PEP discussion will be
short and sweet -- either most folks like it, or we should not push
through at this point in time.

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

From report at bugs.python.org  Mon Apr  7 19:48:08 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Mon, 07 Apr 2008 17:48:08 +0000
Subject: [issue2159] dbmmodule inquiry function is performance prohibitive
In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>
Message-ID: <1207590488.65.0.823860644969.issue2159@psf.upfronthosting.co.za>


Jes?s Cea Avi?n <jcea at argo.es> added the comment:

Somebody posted a similar issue in pybsddb. The patch I proposed would
be consistent with current "__len__" *internal* use, but the real
intention, I think, is to return True or False if the database is open
or closed, not if the database is empty or not.

Opinions?

See http://mailman.argo.es/pipermail/pybsddb/2008-April/000028.html

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

From report at bugs.python.org  Mon Apr  7 19:51:06 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 17:51:06 +0000
Subject: [issue2159] dbmmodule inquiry function is performance prohibitive
In-Reply-To: <1203640875.82.0.736964888757.issue2159@psf.upfronthosting.co.za>
Message-ID: <1207590666.22.0.196925155631.issue2159@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Assigning anything not related to Py3k design to me is a mistake; I
don't have the bandwidth to handle this, sorry.

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

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

From report at bugs.python.org  Mon Apr  7 19:53:18 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 17:53:18 +0000
Subject: [issue508157] urllib.urlopen results.readline is slow
Message-ID: <1207590798.83.0.570573600369.issue508157@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Please don't add to a closed issue that old.  If you still have an issue
with this, please open a new issue.  If you have a patch, kindly upload
it to the issue.

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

From report at bugs.python.org  Mon Apr  7 19:54:11 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 17:54:11 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207590851.54.0.391555640012.issue2541@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

To be honest, I don't know what the uses are for that codec.

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

From report at bugs.python.org  Mon Apr  7 20:02:55 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 07 Apr 2008 18:02:55 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207591375.43.0.198304722411.issue2541@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

pickle still uses it when protocol=0 (and cPickle as well, but in trunk/
only of course)

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

From report at bugs.python.org  Mon Apr  7 20:13:33 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Mon, 07 Apr 2008 18:13:33 +0000
Subject: [issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2
In-Reply-To: <1207290588.7.0.806597302139.issue2547@psf.upfronthosting.co.za>
Message-ID: <1207592013.83.0.643771574313.issue2547@psf.upfronthosting.co.za>


Barry A. Warsaw <barry at python.org> added the comment:

Setting this to release blocker so I can't forget it for the next alphas.

----------
priority:  -> release blocker

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

From report at bugs.python.org  Mon Apr  7 20:28:33 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 07 Apr 2008 18:28:33 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207592913.36.0.337995879857.issue2292@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

Agreed. A PEP was already on my TODO list (although I don't mind if
someone else picks it up :-) I implemented the
dict-unpacking-in-dict-literal syntax in the mean time; it's pushed to
the starunpack bzr branch, but I'll add some actual tests before I
upload the patch.

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

From report at bugs.python.org  Mon Apr  7 20:02:18 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 18:02:18 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207591338.7.0.894545328713.issue2525@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hm, can you use lowercase for the local variable names dststart and
dstend? Otherwise looks good.

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

From report at bugs.python.org  Mon Apr  7 20:07:52 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 18:07:52 +0000
Subject: [issue2557] \u and \U in raw strings have regressed in 3.0a4
In-Reply-To: <1207406736.51.0.485444430847.issue2557@psf.upfronthosting.co.za>
Message-ID: <1207591671.99.0.0507714457711.issue2557@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

We went over this before.  *I* consider the 2.x behavior a mistake, and
a decision was made to change in 3.0.  It got much worse in 3.0 because
all literals are Unicode (except byte literals).

To add a unicode value to a raw string, just concatenate a raw string
and a non-raw string, e.g.

r'whatever' '\u1234' r'whatever'

I don't understand what you meant by '\x1234' -- the \x escape only
accepts 2 hex digits.

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

From report at bugs.python.org  Mon Apr  7 20:04:05 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 18:04:05 +0000
Subject: [issue2547] Py30a4 RELNOTES only cover 30a1 and 30a2
In-Reply-To: <1207290588.7.0.806597302139.issue2547@psf.upfronthosting.co.za>
Message-ID: <1207591445.05.0.0585077099828.issue2547@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Barry, this sounds like a file you weren't aware of.  Too late for
3.0a4, but perhaps you can add this to the roster of files to be looked
at for each release?

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

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

From report at bugs.python.org  Mon Apr  7 20:29:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 18:29:02 +0000
Subject: [issue2570] backport 3.0-style \u/\U processing in raw strings when
	unicode_literals is imported from __future__
In-Reply-To: <1207592942.81.0.864010115323.issue2570@psf.upfronthosting.co.za>
Message-ID: <1207592942.81.0.864010115323.issue2570@psf.upfronthosting.co.za>


New submission from Guido van Rossum <guido at python.org>:

In 3.0, r'\u1234' is a string of 6 characters (\, u, 1, 2, 3, 4).  In
2.6, after "from __future__ import unicode_literals" it is a string of
one character (code point 0x1234).  IMO the 3.0 behavior should be
imported from the future as well (using the same import).

----------
components: Interpreter Core
keywords: 26backport
messages: 65090
nosy: gvanrossum
severity: normal
status: open
title: backport 3.0-style \u/\U processing in raw strings when unicode_literals is imported from __future__
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr  7 20:42:18 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 07 Apr 2008 18:42:18 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207593738.46.0.966053514042.issue2525@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

Changed the local dststart, dstend variables to lowercase, "dates" to
"times" (in "find start and end times") and the diff was created from
trunk/ this time (as opposed to trunk/Doc/includes/).

Added file: http://bugs.python.org/file9969/tzinfo-examples4.patch

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

From report at bugs.python.org  Mon Apr  7 20:47:27 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 18:47:27 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207594047.27.0.569702055229.issue2525@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Thanks, looks good. Since this is assigned to Georg, can you check it
in, Georg?

Should this be backported to 2.5 docs as well?

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

From report at bugs.python.org  Mon Apr  7 20:53:46 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Apr 2008 18:53:46 +0000
Subject: [issue2525] class USTimeZone in Doc/includes/tzinfo-examples.py is
	out of date
In-Reply-To: <1207022056.84.0.346653024753.issue2525@psf.upfronthosting.co.za>
Message-ID: <1207594426.9.0.666064555027.issue2525@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed as r62214, r62215 (2.5).

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

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

From report at bugs.python.org  Mon Apr  7 20:58:22 2008
From: report at bugs.python.org (Richard King)
Date: Mon, 07 Apr 2008 18:58:22 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>


New submission from Richard King <rickbking at users.sourceforge.net>:

The module global value use_rawinput is initialized to 1 but not reset
when stdin is replaced with a passed-in value.

----------
components: Extension Modules
messages: 65094
nosy: rickbking
severity: normal
status: open
title: cmd.py always uses raw_input, even when another stdin is specified
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Mon Apr  7 21:00:15 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Apr 2008 19:00:15 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207594815.42.0.17940161805.issue2292@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Thomas,

Could you add BUILD_*_UNPACK opcodes documentation to
Doc/library/dis.rst?   It would also help if you modify CALL_FUNCTION_*
opcodes' documentation to explain how they will interact with unpacking
opcodes.

Do I understand correctly that non-starred arguments are packed into
intermediate tuples/sets in the presence of starred arguments so that
{a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
problem for tuples, but with sets, it means that {a,b,c} may behave
subtly differently from {a,*(b,c)}.

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

From report at bugs.python.org  Mon Apr  7 21:07:51 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 19:07:51 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1207594815.42.0.17940161805.issue2292@psf.upfronthosting.co.za>
Message-ID: <ca471dc20804071207g19bd4caco9f756f69861e1ce3@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

>  Do I understand correctly that non-starred arguments are packed into
>  intermediate tuples/sets in the presence of starred arguments so that
>  {a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
>  problem for tuples, but with sets, it means that {a,b,c} may behave
>  subtly differently from {a,*(b,c)}.

Can you show an example where this would be different?

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

From report at bugs.python.org  Mon Apr  7 21:17:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Apr 2008 19:17:32 +0000
Subject: [issue2567] Section "New-style and classic classes" needs to be
	removed/rewritten
In-Reply-To: <1207546792.82.0.239101665386.issue2567@psf.upfronthosting.co.za>
Message-ID: <1207595852.33.0.411679565708.issue2567@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r62216.

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

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

From report at bugs.python.org  Mon Apr  7 21:18:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 07 Apr 2008 19:18:21 +0000
Subject: [issue2572] 3.0 pickle docs -- what about old-style classes?
In-Reply-To: <1207595901.24.0.991437670579.issue2572@psf.upfronthosting.co.za>
Message-ID: <1207595901.24.0.991437670579.issue2572@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Can 3.0 unpickle pickled old-style classes? Which pickling methods are
supported? Etc.

----------
assignee: alexandre.vassalotti
components: Documentation
messages: 65098
nosy: alexandre.vassalotti, georg.brandl
severity: normal
status: open
title: 3.0 pickle docs -- what about old-style classes?
versions: Python 3.0

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

From report at bugs.python.org  Mon Apr  7 21:27:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Apr 2008 19:27:22 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207596442.88.0.303067902446.issue2568@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

OP does not have the reference, but the issue is apparently in the time
and datetime modules documentation:

http://docs.python.org/dev/library/time.html#time.strftime
http://docs.python.org/dev/library/datetime.html#strftime-behavior

Note that datetime's doc is twice incorrect because leap seconds are not
supported by the datetime module at all:

>>> from datetime import *
>>> time(23,59,60)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59
>>> datetime.strptime('20000101T235960', '%Y%m%dT%H%M%S')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +belopolsky, georg.brandl

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

From report at bugs.python.org  Mon Apr  7 21:28:04 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 07 Apr 2008 19:28:04 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1207594815.42.0.17940161805.issue2292@psf.upfronthosting.co.za>
Message-ID: <9e804ac0804071227k297ecc53ud3f655cec9b83bf1@mail.gmail.com>


Thomas Wouters <thomas at python.org> added the comment:

On Mon, Apr 7, 2008 at 9:00 PM, Alexander Belopolsky <report at bugs.python.org>
wrote:

>
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
>
> Thomas,
>
> Could you add BUILD_*_UNPACK opcodes documentation to
> Doc/library/dis.rst?   It would also help if you modify CALL_FUNCTION_*
> opcodes' documentation to explain how they will interact with unpacking
> opcodes.

They don't interact. They're separate opcodes. The CALL_FUNCTION_* opcodes
are almost untouched, except the _VAR and _VAR_KW versions: previously, they
expected, on the stack, positional arguments followed by keyword/argument
pairs followed by the *args sequence followed by the **kwargs mapping (for
_VAR_KW.) I just changed the order so *args is before the keyword/argument
pairs. The change is not related to the BUILD_*_UNPACK opcodes, but rather
to Guido's request that the order of keyword arguments and *args in the
functioncall syntax changes. For the order of execution to remain sane, the
arguments need to be pushed on the stack in that order, and keeping the
_VAR* opcode order the same would mean a large amount of ROT_* opcodes ;-P

Updating the docs is on the TODO list.

>
> Do I understand correctly that non-starred arguments are packed into
> intermediate tuples/sets in the presence of starred arguments so that
> {a,b,*c,d,e} is equivalent to {*{a,b},*c,*{d,e}}? This should not be a
> problem for tuples, but with sets, it means that {a,b,c} may behave
> subtly differently from {a,*(b,c)}.
>

Yes, that's what happens, but only in the presence of *args. For
functioncalls, it only happens to everything after the first *args
(inclusive.) That means '{a, b, c}' does not change, and neither does
'func(a, b, c)' or 'func(a, b, *c)'. As for sets, I don't see why this would
be a problem; there is no difference in the set created by {a, b, c} and the
set created by {a, *{b, c}} or {a, *(b, c)}.  The arguments are all
evaluated in the same order (left to right), and c replaces b, b replaces a
if they are considered equal by sets.

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

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2292>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080407/4483c782/attachment-0001.ksh 

From report at bugs.python.org  Mon Apr  7 21:34:08 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 07 Apr 2008 19:34:08 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207596848.36.0.242879493294.issue2292@psf.upfronthosting.co.za>


Changes by Thomas Wouters <thomas at python.org>:


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

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

From report at bugs.python.org  Mon Apr  7 21:34:51 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Apr 2008 19:34:51 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207596891.62.0.537099539504.issue2568@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the other hand, the time module allows full [00,61] range:

>>> [time.strftime('%S',time.strptime(x, '%S')) for x in ('00', '61')] 
['00', '61']

so this is implementation rather than documentation issue.

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

From report at bugs.python.org  Mon Apr  7 21:37:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 19:37:54 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207555587.88.0.937435852453.issue2562@psf.upfronthosting.co.za>
Message-ID: <47FA780F.1080900@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> If we do use Unicode, I think we might need an extra meta-data,
> "encoding", that would default to "utf8", and that could be used when
> the class needs to serialize the data in a file.

I don't think so. Whenever the data is written to a file, the file
format should specify the encoding.

Regards,
Martin

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

From report at bugs.python.org  Mon Apr  7 21:39:27 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 19:39:27 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207583467.65.0.849450197424.issue2562@psf.upfronthosting.co.za>
Message-ID: <47FA786C.1020407@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't think that we should support non-ASCII encodings for meta-data 
> strings passed to setup().
> 
> If setuptools is broken in this respect, it needs to be fixed. Dito for
> other 3rd party tools.

We do need to support non-ASCII files, as distutils didn't previously
even support Unicode strings, and people still wanted to get their names
right. It's not about setuptools, and not about other 3rd party tools.
It's about distutils packages which we need to continue to support.

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

From report at bugs.python.org  Mon Apr  7 21:42:26 2008
From: report at bugs.python.org (Anton Fedorov)
Date: Mon, 07 Apr 2008 19:42:26 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207597346.71.0.482616903647.issue2568@psf.upfronthosting.co.za>


Anton Fedorov <datacompboy at call2ru.com> added the comment:

There no leap second in 2000th.
But correct time request fails:
>>> datetime.strptime('19951231T235960', '%Y%m%dT%H%M%S')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59

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

From report at bugs.python.org  Mon Apr  7 21:47:25 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Mon, 07 Apr 2008 19:47:25 +0000
Subject: [issue2573] Can't change the framework name on OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>


New submission from Aaron Gallagher <habnabit at gmail.com>:

There is currently no way in the configure script to specify an 
alternate name for Python.framework. If I want to completely separate 
versions of Python (e.g. for 3.0 alphas and/or Stackless), I have to 
manually edit configure.in and configure to change the framework name. 
It would be much more convenient if --with-framework could take an 
optional parameter of the framework name to use.

----------
components: Build, Macintosh
messages: 65105
nosy: habnabit
severity: normal
status: open
title: Can't change the framework name on OS X builds
type: feature request
versions: Python 2.6, Python 3.0

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

From report at bugs.python.org  Mon Apr  7 21:48:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 19:48:49 +0000
Subject: [issue1232947] non-admin install may fail (win xp pro)
In-Reply-To: <1207579807.35.0.548088401845.issue1232947@psf.upfronthosting.co.za>
Message-ID: <47FA7A9D.3080603@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I can repro this too using python-2.6a2.msi - after selecting "just for
> me" on XP running as a non-admin user, I see an error message regarding
> permissions.

I think this is mixing up entirely unrelated issues. 2.6a2 is known to
require admin privileges; see the caveat on the release page.

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

From report at bugs.python.org  Mon Apr  7 21:48:59 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 07 Apr 2008 19:48:59 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1207597739.54.0.851209464691.issue2571@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

I don't think it should stop using raw_input just because you changed
stdin, as you can change it to something that will work with raw_input.
Consider:
>>> import sys
>>> sys.stdin = open("/dev/tty")
>>> raw_input()
a
'a'

You can tie it to any object (e.g. a GUI input) that supports the file
protocol and keep using raw_input. Or change Cmd.use_rawinput to 0 to
use stdin.readline directly.

On a related issue. Cmd.use_rawinput should be "True", not 1...

----------
nosy: +ajaksu2

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

From report at bugs.python.org  Mon Apr  7 21:49:38 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Apr 2008 19:49:38 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207597778.66.0.180924076032.issue2562@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

Agreed, but any change will target the package authors who can easily
upgrade their packages to use Unicode for e.g. names.

If the change were to address distutils users, we'd have to be a lot
more careful.

In any case, if UTF-8 is the defacto standard used in older packages,
then we should probably use that as fallback solution if the ASCII
assumption doesn't work out:

try:
    value = unicode(value)
except UnicodeDecodeError:
    value = unicode(value, 'utf-8')
value = value.encode('utf-8')

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

From report at bugs.python.org  Mon Apr  7 21:53:35 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Apr 2008 19:53:35 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <ca471dc20804071207g19bd4caco9f756f69861e1ce3@mail.gmail.com>
Message-ID: <d38f5330804071253oba1aefew60caf4e8b4920b73@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Apr 7, 2008 at 3:07 PM, Guido van Rossum <report at bugs.python.org> wrote:

>  Can you show an example where this would be different?

Admittedly a contrived example, but

...    def __hash__(self):
...        print('hash', self)
...        return int.__hash__(self)
...
>>> a,b,c = map(X, range(3))
>>> {a,b,c}
hash 2
hash 1
hash 0
{0, 1, 2}
>>> {a,*(b,c)}
hash 0
hash 1
hash 2
{0, 1, 2}

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

From report at bugs.python.org  Mon Apr  7 21:58:40 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Apr 2008 19:58:40 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207598320.1.0.660401759452.issue2292@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I missed the first line copying the class definition into my previous
post.  Class 'X' was defined as follows:

class X(int):
    def __hash__(self):
        print('hash', self)
        return int.__hash__(self)

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

From report at bugs.python.org  Mon Apr  7 22:02:10 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 07 Apr 2008 20:02:10 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207598530.32.0.611014449761.issue2292@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

I'm not sure how this matters. The order of evaluation is the same, the
BUILD_SET implementation just hashes the evaluated items in a different
order. You can't really rely on that particular order as it's tied
closely to the stack representation CPython uses. I also see no
practical reason -- or even practical *way* -- to abuse the hashing
order. But you have given me an idea on how to improve some of the code
in the BUILD_*_UNPACK opcodes, hmm.

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

From report at bugs.python.org  Mon Apr  7 22:04:35 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Apr 2008 20:04:35 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207597346.71.0.482616903647.issue2568@psf.upfronthosting.co.za>
Message-ID: <d38f5330804071304p147049f8qf5d9dc8b22458589@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Apr 7, 2008 at 3:42 PM, Anton Fedorov <report at bugs.python.org> wrote:

>  There no leap second in 2000th.

I was just too lazy too look up the leap second year, but datetime
module knows nothing about leap seconds, so I did not expect different
behavior for years 1995 and 2000.

>  But correct time request fails:
>  >>> datetime.strptime('19951231T235960', '%Y%m%dT%H%M%S')

ditto

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

From report at bugs.python.org  Mon Apr  7 22:07:41 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 20:07:41 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207597778.66.0.180924076032.issue2562@psf.upfronthosting.co.za>
Message-ID: <47FA7F0A.3060903@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Agreed, but any change will target the package authors who can easily
> upgrade their packages to use Unicode for e.g. names.

They can't: that would break their 2.5-and-earlier compatibility.

> If the change were to address distutils users, we'd have to be a lot
> more careful.

We do address distutils users: what else? Why should we be more careful?

> In any case, if UTF-8 is the defacto standard used in older packages,
> then we should probably use that as fallback solution if the ASCII
> assumption doesn't work out:
> 
> try:
>     value = unicode(value)
> except UnicodeDecodeError:
>     value = unicode(value, 'utf-8')
> value = value.encode('utf-8')

For writing the metadata, we don't need to make any assumptions. We
can just write the bytes as-is. This is how distutils has behaved
for many releases now, and this is how users have been using it.

Of course, we (probably) agree that this is conceptually wrong, as
we won't be able to know what the encoding of the metadata file is,
and we (probably) also agree that the metadata should have the
fixed encoding of UTF-8. However, I don't think we should deliberately
break packages before 3.0 (even if they chose to use some other
encoding); instead, such packages will silently start doing the
right thing with 3.0, when their strings become Unicode strings.

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

From report at bugs.python.org  Mon Apr  7 22:10:13 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 07 Apr 2008 20:10:13 +0000
Subject: [issue1232947] non-admin install may fail (win xp pro)
Message-ID: <1207599013.16.0.16093602864.issue1232947@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm closing this as "won't fix". I don't really see a way to support
this kind of setup (i.e. the start menu is on a network drive to which
the installer service cannot write).

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

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

From report at bugs.python.org  Mon Apr  7 22:12:22 2008
From: report at bugs.python.org (bms)
Date: Mon, 07 Apr 2008 20:12:22 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>
Message-ID: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>


New submission from bms <bms at incunabulum.net>:

Hi,

Here is a patch to add RFC 3768 SSM Multicast support to low-level
Python socket module as of 2.5.1.

I have not tested the setsourcefilter()/getsourcefilter() socket member
functions other than compiling the patch on a Gentoo Linux 2008.0 box
w/2.6 Linux kernel.

These APIs should be fairly portable. Note that I haven't added any
other configure glue, like the rest of socket, support is very low level
and getting the arguments to struct.pack() right is the user's problem.

cheers
BMS

----------
components: Extension Modules
files: python-2.5.1-multicast-ssm.patch
keywords: patch
messages: 65115
nosy: bms
severity: normal
status: open
title: Add RFC 3768 SSM Multicast support to "socket"
type: feature request
versions: Python 2.5
Added file: http://bugs.python.org/file9971/python-2.5.1-multicast-ssm.patch

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

From report at bugs.python.org  Mon Apr  7 22:14:32 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 07 Apr 2008 20:14:32 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207599272.64.0.997225614915.issue2292@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I agree with Thomas.  The order in which __hash__() is evaluated
shouldn't matter to your app; if __hash__() isn't a pure function (apart
from possible caching) you've got worse trouble.

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

From report at bugs.python.org  Mon Apr  7 22:15:11 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 07 Apr 2008 20:15:11 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1207598530.32.0.611014449761.issue2292@psf.upfronthosting.co.za>
Message-ID: <d38f5330804071315y8a05763m256dc76c5ef4d47f@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Mon, Apr 7, 2008 at 4:02 PM, Thomas Wouters <report at bugs.python.org> wrote:
> .. The order of evaluation is the same, the
>  BUILD_SET implementation just hashes the evaluated items in a different
>  order. You can't really rely on that particular order as it's tied
>  closely to the stack representation CPython uses.

I agree and that's why I said the difference in behavior is "subtle"
and my example is "contrived."   However, I believe Raymond expressed
a similar concern in msg63065.

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

From report at bugs.python.org  Mon Apr  7 22:22:33 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Mon, 07 Apr 2008 20:22:33 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207599753.22.0.299838762816.issue2562@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

With "distutils users" I'm referring to people that are told to run
"python setup.py install". Changed affecting the way this line behaves
need to be carefully considered.

OTOH, when upgrading a package to a new Python version (and distutils
version), package authors will have to modify their packages anyway, so
it is well possible to ask them to use Unicode strings for meta-information.

Supporting pre-2.6 Python version is also not much of a problem, since
authors could setup the strings in question to be either Unicode or
8-bit strings depending on the Python version.

This change would be really minor (compared to e.g the Py_ssize_t change
;-).

That said, I don't think it's a good idea to make package data more
complicated by allowing multiple encodings. The meta-data file should
have a fixed pre-defined encoding, preferrably UTF-8.

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

From report at bugs.python.org  Mon Apr  7 22:53:59 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Mon, 07 Apr 2008 20:53:59 +0000
Subject: [issue2575] Reference manual: production for integer literals is
	missing "bininteger"
In-Reply-To: <1207601639.49.0.884754538811.issue2575@psf.upfronthosting.co.za>
Message-ID: <1207601639.49.0.884754538811.issue2575@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

The production list for integer literals is missing the `bininteger`
term for binary integer literals.  Patch attached.

----------
assignee: georg.brandl
components: Documentation
files: bininteger.diff
keywords: patch, patch
messages: 65119
nosy: georg.brandl, marketdickinson
severity: normal
status: open
title: Reference manual: production for integer literals is missing "bininteger"
versions: Python 3.0
Added file: http://bugs.python.org/file9972/bininteger.diff

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

From report at bugs.python.org  Mon Apr  7 22:54:40 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 07 Apr 2008 20:54:40 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207594702.67.0.73869549091.issue2571@psf.upfronthosting.co.za>
Message-ID: <1207601680.45.0.174275173321.issue2571@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

The doc for "cmd" at
http://docs.python.org/dev/library/cmd.html#module-cmd says:

"Instances of Cmd subclasses have some public instance variables:
.
.
.
Cmd.use_rawinput?
    A flag, defaulting to true. If true, cmdloop() uses raw_input() to
display a prompt and read the next command; if false, sys.stdout.write()
and sys.stdin.readline() are used. (This means that by importing
readline, on systems that support it, the interpreter will automatically
support Emacs-like line editing and command-history keystrokes.)"

So it is for the user to modify use_rawinput as required. This flag has
been introduced in #405952. BTW, this one and other similar variables
are at class level and are not instance variables. Isn't it?

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

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

From report at bugs.python.org  Mon Apr  7 22:55:11 2008
From: report at bugs.python.org (Aren Olson)
Date: Mon, 07 Apr 2008 20:55:11 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>


New submission from Aren Olson <reacocard at gmail.com>:

This is a reposting of issue 508157, as requested by gvanrossum.

The socket file object in httplib is opened without any buffering
resulting in very slow performance of read().  The specific problem is
in the httplib.HTTPResponse constructor.  It calls sock.makefile() with
a 0 for the buffer size.  changing the buffer size to 4096 improved the
time needed to download 10MB from 15.5s to 1.78s, almost 9x faster.
Repeat downloads of the same file (meaning the server now has the file
cached in memory), yield times of 15.5s and 0.03s, a 500x improvement.
When fetching from a server on the local network, rather than from
localhost, these times become 15.5s and 0.9s in both cases, a 17x
speedup. Real-world situations will likely be a mix of these, however it
is safe to say the speed improvement will be substantial. Adding an
option to adjust the buffer size would be very welcome, though the
default value should still be zero, to avoid the issues already
mentioned in issue 508157.

These speed results were obtained with python2.5 and apache2 under
Ubuntu linux, using the code found here: http://pastebin.ca/973578

----------
components: Library (Lib)
messages: 65121
nosy: reacocard
severity: normal
status: open
title: httplib read() very slow due to lack of socket buffer
versions: Python 2.6

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

From report at bugs.python.org  Mon Apr  7 22:57:15 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 07 Apr 2008 20:57:15 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1207601835.29.0.390783809079.issue2576@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
priority:  -> high

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

From report at bugs.python.org  Mon Apr  7 23:26:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 07 Apr 2008 21:26:14 +0000
Subject: [issue2573] Can't change the framework name on OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1207603574.0.0.238292988305.issue2573@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Would you like to work on a patch?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Apr  7 23:28:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 07 Apr 2008 21:28:16 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1207599142.63.0.703836832788.issue2574@psf.upfronthosting.co.za>
Message-ID: <1207603696.52.0.843420512196.issue2574@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Can you submit a patch against the trunk? There aren't going to be any
new features in 2.5.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Mon Apr  7 23:33:31 2008
From: report at bugs.python.org (Thomas Wouters)
Date: Mon, 07 Apr 2008 21:33:31 +0000
Subject: [issue2292] Missing *-unpacking generalizations
In-Reply-To: <1205595680.3.0.859525264867.issue2292@psf.upfronthosting.co.za>
Message-ID: <1207604011.23.0.720033184855.issue2292@psf.upfronthosting.co.za>


Thomas Wouters <thomas at python.org> added the comment:

I don't think the order in which the items are hashed is really what
Raymond was worried about. Rather, the size of the stack was, and the
effect of having all the items on the stack at the same time. I think
Raymond is wrong in this case; while the stack may grow relatively big,
we're only talking two pointers here. The items will all have to be
created anyway, and in the usual case the number of duplicate keys is low. 

My patch actually includes pretty much the same change to BUILD_MAP,
because it greatly simplifies the compiler code and gets rid of a lot of
extra opcodes -- causing an overal speedup even in the face of large
dict literals. But I guess we should take it up with Raymond at some
point, perhaps as part of the PEP discussion.

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

From report at bugs.python.org  Mon Apr  7 23:51:28 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 07 Apr 2008 21:51:28 +0000
Subject: [issue2572] 3.0 pickle docs -- what about old-style classes?
In-Reply-To: <1207595901.24.0.991437670579.issue2572@psf.upfronthosting.co.za>
Message-ID: <1207605087.98.0.523055395041.issue2572@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Python 3.0 shouldn't have any problem unpickling old-style classes.
However, they will be unpickled as new-style classes. Therefore, there
might be a few corner-cases that might cause some problems. For example,
if an old-style class contains a __slots__:

Python 2.5.1 (r251:54863, Mar  7 2008, 04:10:12) 
>>> import pickle
>>> class A:
...   __slots__ = []
... 
>>> pickle.dumps(A())
'(i__main__\nA\np0\n(dp1\nb.'

Python 3.0a3+ (py3k:62050M, Mar 30 2008, 17:29:33) 
>>> class A:
...   __slots__ = []
... 
>>> pickle.loads(b'(i__main__\nA\np0\n(dp1\nb.')
Traceback (most recent call last):
  ...
TypeError: __class__ assignment: '_EmptyClass' deallocator differs from 'A'

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

From report at bugs.python.org  Mon Apr  7 23:52:57 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Mon, 07 Apr 2008 21:52:57 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1207605177.15.0.253453747918.issue2576@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:

The code patch is trivial. I believe it needs docs (both explaining how
to use and warning against the problems it may cause), a NEWS entry and
tests (at least to check what happens when an invalid value lands).

I can work on those changes if the general idea is not shot down :)

----------
keywords: +patch
nosy: +ajaksu2
Added file: http://bugs.python.org/file9973/httplib.patch

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

From report at bugs.python.org  Tue Apr  8 01:13:43 2008
From: report at bugs.python.org (Richard King)
Date: Mon, 07 Apr 2008 23:13:43 +0000
Subject: [issue2577] cmd.py should track input file objects so macros with
	submacros can be easily written
In-Reply-To: <1207610022.93.0.150736529438.issue2577@psf.upfronthosting.co.za>
Message-ID: <1207610022.93.0.150736529438.issue2577@psf.upfronthosting.co.za>


New submission from Richard King <rickbking at users.sourceforge.net>:

Add an "input" method or property that saves the current input file
object and resets the input file object; when input results in an "EOF",
the input file object stack is popped and reading continues from there.
A modified cmd.py is attached.

----------
components: Extension Modules
files: cmd.py
messages: 65128
nosy: rickbking
severity: normal
status: open
title: cmd.py should track input file objects so macros with submacros can be easily written
type: feature request
versions: Python 2.4
Added file: http://bugs.python.org/file9974/cmd.py

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

From report at bugs.python.org  Tue Apr  8 01:28:38 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 07 Apr 2008 23:28:38 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1207610918.62.0.252806111687.issue2240@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Trent Nelson kindly gave me access to his FreeBSD 6.2 buildbot so I had
chance to do some tests. The problem happens when Python is built
against or libc_r, or if you are using libmap you won't need to
recompile but the problem still happens when using libc_r.

I started searching in the FreeBSD bug tracker and found this issue:
http://www.freebsd.org/cgi/query-pr.cgi?pr=threads/49087 which seems
very similar to the problem related here.

I've also done a very simple "test" in C, just to demonstrate that this
issue isn't related to Python at all:

#include <stdio.h>
#include <signal.h>
#include <sys/time.h>

void h(int signo)
{
    struct itimerval t;

    getitimer(ITIMER_PROF, &t);
    printf("%d %d\n", t.it_value.tv_sec, t.it_value.tv_usec);

    printf("deactive ITIMER_PROF\n");
    t.it_value.tv_sec = 0;
    t.it_value.tv_usec = 0;
    setitimer(ITIMER_PROF, &t, &t);
}

int main(void)
{
    struct itimerval ival;

    ival.it_value.tv_sec = 1;
    ival.it_value.tv_usec = 0;
    ival.it_interval.tv_sec = 1;
    ival.it_interval.tv_usec = 0;

    signal(SIGPROF, h);
    printf("%d\n", setitimer(ITIMER_PROF, &ival, NULL));
    alarm(2);

    while (1) {
        getitimer(ITIMER_PROF, &ival);
        if (ival.it_value.tv_sec == 0 && ival.it_value.tv_usec == 0)
            break;
        }

    return 0;
}

When I compile this using -lc_r then the callback "h" is never called
and then the alarm is fired. Compiling against pthread, thr or nothing
(since this example doesn't need any threading library) doesn't
demonstrate this problem and all is fine (callback "h" is invoked,
infinite loop finishes and test returns 0).

Should further discussion be moved to python-dev ? I'm somewhat stuck on
how to resolve this, besides saying to upgrade to FreeBSD 7 which uses
libthr by default.

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

From report at bugs.python.org  Tue Apr  8 01:32:29 2008
From: report at bugs.python.org (David Remahl)
Date: Mon, 07 Apr 2008 23:32:29 +0000
Subject: [issue1179] [CVE-2007-4965] Integer overflow in imageop module
In-Reply-To: <1190163754.35.0.664170861932.issue1179@psf.upfronthosting.co.za>
Message-ID: <1207611149.61.0.341126951246.issue1179@psf.upfronthosting.co.za>


David Remahl <chmod007 at users.sourceforge.net> added the comment:

Uploading patch that addresses the test cases above. It applies on top of 
nevyn?s latest patch.

Added file: http://bugs.python.org/file9975/python-2.5-int-overflow-2.patch

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

From report at bugs.python.org  Tue Apr  8 02:20:33 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Apr 2008 00:20:33 +0000
Subject: [issue1736190] asyncore/asynchat patches
Message-ID: <1207614033.02.0.716314120897.issue1736190@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


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

From report at bugs.python.org  Tue Apr  8 02:39:45 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Apr 2008 00:39:45 +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: <1207615185.52.0.957343245169.issue2182@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't think this ought to be changed in exec().  It ought to be done
by opening the file using universal newlines.

----------
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Tue Apr  8 03:01:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Apr 2008 01:01:26 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

unittest has many redundant APIs (eg. failIf and assertFalse) which can
be phased out in 3.x. We may also want to change the actually methods so
they really do what they say:

if x == y:
   pass
 else:
   raise AssertionError(...)

rather than

 if x != y:
   raise AssertionError(...)

----------
components: Library (Lib)
messages: 65132
nosy: benjamin.peterson
severity: normal
status: open
title: Figure out what to do with unittest's redundant APIs
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 03:28:52 2008
From: report at bugs.python.org (Jared Grubb)
Date: Tue, 08 Apr 2008 01:28:52 +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: <1207618132.12.0.418489475753.issue2182@psf.upfronthosting.co.za>


Jared Grubb <python at jaredgrubb.com> added the comment:

This is not a report on a bug in exec(), but rather a bug in the
tokenize module -- the behavior between the CPython tokenizer and the
tokenize module is not consistent. If you look in the tokenize.py
source, it contains code to recognize both \n and \r\n as newlines, but
it ignores the possibility that \r could be the line ending character
(as the Python reference says).

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

From report at bugs.python.org  Tue Apr  8 04:11:36 2008
From: report at bugs.python.org (Henry)
Date: Tue, 08 Apr 2008 02:11:36 +0000
Subject: [issue2579] Misleading 'toctree references unknown document' error
In-Reply-To: <1207620696.06.0.199132876602.issue2579@psf.upfronthosting.co.za>
Message-ID: <1207620696.06.0.199132876602.issue2579@psf.upfronthosting.co.za>


New submission from Henry <misc at hl.id.au>:

The 'toctree references unknown document' can be misleading when the
document name includes whitespace.

For example, I had mistakenly created an index file of the form

.. toctree::
   :maxdepth: 2

    overview

(note that overview has a leading space). In the error message is was
very difficult to see that this was a problem, as the error message was

WARNING: /home/henry/code/bdec.docs/doc/source/index.rst:8: (WARNING/2)
toctree references unknown document  overview

By putting the document name in quotes, it becomes clearer what the
problem was.

WARNING: /home/henry/code/bdec.docs/doc/source/index.rst:8: (WARNING/2)
toctree references unknown document ' overview'

A patch to include these quotes has been attached.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: unknown_reference.patch
keywords: patch
messages: 65134
nosy: georg.brandl, henryl
severity: normal
status: open
title: Misleading 'toctree references unknown document' error
Added file: http://bugs.python.org/file9976/unknown_reference.patch

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

From report at bugs.python.org  Tue Apr  8 04:15:28 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 08 Apr 2008 02:15:28 +0000
Subject: [issue2577] cmd.py should track input file objects so macros with
	submacros can be easily written
In-Reply-To: <1207610022.93.0.150736529438.issue2577@psf.upfronthosting.co.za>
Message-ID: <1207620928.54.0.093958905926.issue2577@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

You should include a diff, not the entire file with your changes

----------
nosy: +gpolo

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

From report at bugs.python.org  Tue Apr  8 04:24:07 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Tue, 08 Apr 2008 02:24:07 +0000
Subject: [issue2573] Can't change the framework name on OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1207621446.76.0.0774335241431.issue2573@psf.upfronthosting.co.za>


Aaron Gallagher <habnabit at gmail.com> added the comment:

Here's a framework that implements the necessary change. I'm not very good 
at autoconf, so it might need to be touched up.

----------
keywords: +patch
Added file: http://bugs.python.org/file9977/framework.patch

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

From report at bugs.python.org  Tue Apr  8 04:26:15 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Tue, 08 Apr 2008 02:26:15 +0000
Subject: [issue2580] Revise builtin class int library manual entry
In-Reply-To: <1207621575.04.0.143306946794.issue2580@psf.upfronthosting.co.za>
Message-ID: <1207621575.04.0.143306946794.issue2580@psf.upfronthosting.co.za>


New submission from Terry J. Reedy <tjreedy at udel.edu>:

Based on c.l.p discussion with Mark Dickinson, who supplied details and
corrections, we propose the following for the int() entry at
http://docs.python.org/dev/3.0/library/functions.html#int

int([number | string[, radix]])
Convert a number or string to an integer.  If no arguments are given,
return 0.  If a number is given, return number.__int__().  Conversion of
floating point numbers to integers truncates towards zero.  A string
must be a base-radix integer literal optionally preceded by '+' or '-'
(with no  space in between) and optionally surrounded by whitespace.  A
base-n literal consists of the digits 0 to n-1, with 'a' to 'z' (or 'A'
to 'Z')having values 10 to 35.  The default radix is 10. The allowed
values are 0 and 2-36.  Base-2, -8, and -16 literals can  be optionally
prefixed with 0b/0B, 0o/0O, or 0x/0X, as with integer literals in code.
 Radix 0 means to interpret exactly as a code literal, so that the
actual radix is 2, 8, 10, or 16, and so that int('010',0) is not legal,
while int('010') is.

The revised signature makes it clear from the start that *radix* can
only follow *string*, so no sentence to that effect is needed in the
text.  The other changes are to discuss the signature in order and to
add details.  We believe the above accurately reflects the
intended/actual behavior once the no-space-after-sign patch is applied.
 (I don't know if that made it into .0a4).

Some of this might apply to the 2.6 docs, except that the no-space patch
will apparently not be backported.  I believe the acceptable strings are
a bit different also, at least for octals, but I am not sure.

----------
assignee: georg.brandl
components: Documentation
messages: 65137
nosy: georg.brandl, tjreedy
severity: normal
status: open
title: Revise builtin class int library manual entry
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 04:27:53 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Apr 2008 02:27:53 +0000
Subject: [issue2573] Can't change the framework name on OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1207621673.93.0.0440554468435.issue2573@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> ronaldoussoren
nosy: +ronaldoussoren

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

From report at bugs.python.org  Tue Apr  8 04:28:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Apr 2008 02:28:44 +0000
Subject: [issue2577] cmd.py should track input file objects so macros with
	submacros can be easily written
In-Reply-To: <1207610022.93.0.150736529438.issue2577@psf.upfronthosting.co.za>
Message-ID: <1207621724.18.0.948283866966.issue2577@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Also, please make it against the current trunk.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Tue Apr  8 04:43:07 2008
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 08 Apr 2008 02:43:07 +0000
Subject: [issue2581] Vista UAC/elevation support for bdist_wininst
In-Reply-To: <1207622587.48.0.467176827447.issue2581@psf.upfronthosting.co.za>
Message-ID: <1207622587.48.0.467176827447.issue2581@psf.upfronthosting.co.za>


New submission from Mark Hammond <mhammond at users.sourceforge.net>:

The attached patch adds basic UAC support to bdist_wininst created
installers.  A new option '--user-access-control' has been added to
bdist_wininst, which is written to the INI file read by the installer. 
The installer reads this value: if it is 'force', elevation is always
requested, if it is 'auto', elevation is requested when Python is
installed in HKLM.  'none' (the default) means nothing UAC related
happens at all.

The elevation happens by having the installer re-execute itself using
ShellExecute.

I've also ensured the code builds for all versions of VS we support.  As
a result, it was necessary to change the old bdist_wininst project files
to point to the later zlib version Python itself uses.  All these
changes are in the patch.

----------
assignee: mhammond
components: Distutils
files: bdist_wininst_uac.patch
keywords: patch, patch
messages: 65139
nosy: mhammond, theller
severity: normal
status: open
title: Vista UAC/elevation support for bdist_wininst
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file9978/bdist_wininst_uac.patch

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

From report at bugs.python.org  Tue Apr  8 05:39:19 2008
From: report at bugs.python.org (bms)
Date: Tue, 08 Apr 2008 03:39:19 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <1207603696.52.0.843420512196.issue2574@psf.upfronthosting.co.za>
Message-ID: <47FAE8E2.7020501@incunabulum.net>


bms <bms at incunabulum.net> added the comment:

Benjamin Peterson wrote:
> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
> Can you submit a patch against the trunk? There aren't going to be any
> new features in 2.5.
>   

Would a patch against 2.6a2 be OK?

I have had a lot of problems building Python on Gentoo Linux (where I 
developed these patches) w/o using their ebuild system, so I am trying 
to keep things simple.

This stuff isn't really new as such, it's been in Windows, OpenSolaris 
and other OSes for a while now -- and trying to get FreeBSD SSM support 
out the door. I can understand if folk don't want to incorporate it in 
the production releases which most people are using, though, however 
it's still important that it sees the light of day.

Unfortunately the setsourcefilter() APIs are not terribly accessible to 
non C users such as Python without the wrapping, otherwise we end up 
instantiating arrays like we have to for fcntl.ioctl().

Also the plat-linux2 stuff seems to be lagging w.r.t the glibc inet 
defines in IN.py, where much of this stuff would normally appear.

cheers
BMS

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

From report at bugs.python.org  Tue Apr  8 05:57:24 2008
From: report at bugs.python.org (bms)
Date: Tue, 08 Apr 2008 03:57:24 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <47FAE8E2.7020501@incunabulum.net>
Message-ID: <47FAED20.6020006@incunabulum.net>


bms <bms at incunabulum.net> added the comment:

Bruce M Simpson wrote:
> Benjamin Peterson wrote:
>> Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>>
>> Can you submit a patch against the trunk? There aren't going to be any
>> new features in 2.5.
>>   
>
> Would a patch against 2.6a2 be OK?
>
> I have had a lot of problems building Python on Gentoo Linux (where I 
> developed these patches) w/o using their ebuild system, so I am trying 
> to keep things simple. 

I just tried to build python 2.6a2 from svn trunk in FreeBSD 
6.3-RELEASE. I get the same error messages as I do in Gentoo Linux:

%%%
Could not find platform independent libraries <prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
'import site' failed; use -v for traceback
Traceback (most recent call last):
  File "./setup.py", line 6, in <module>
    import sys, os, imp, re, optparse
ImportError: No module named os
gmake: *** [sharedmods] Error 1
Exit 2
%%%

I have no PYTHON* variables set in my environment.

On Gentoo, when I build using the ebuild / emerge system, I don't see 
this issue, nor do I see it with FreeBSD ports. Obviously they are doing 
something which differs from the instructions in the README, and it 
makes it difficult for me to submit patches for versions of Python other 
than those supported by the packaging systems, as I am sure you can 
understand.

cheers
BMS

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

From report at bugs.python.org  Tue Apr  8 06:42:57 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Apr 2008 04:42:57 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207629777.4.0.522584511526.issue2578@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

My plan:
- add deprecations to 3.1
- remove in 3.3

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

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

From report at bugs.python.org  Tue Apr  8 06:46:54 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Apr 2008 04:46:54 +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: <1207630013.99.0.498276480915.issue2182@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I still think it shouldn't be tokenize's business to handle this.  I'm
not quite sure how exec() manages to do this; I note that this gives a
syntax error:

exec('x = 1\rprint x\r')

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

From report at bugs.python.org  Tue Apr  8 07:19:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 08 Apr 2008 05:19:16 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1207610918.62.0.252806111687.issue2240@psf.upfronthosting.co.za>
Message-ID: <47FB0050.7060501@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Should further discussion be moved to python-dev ? I'm somewhat stuck on
> how to resolve this, besides saying to upgrade to FreeBSD 7 which uses
> libthr by default.

Discussing on python-dev is fine. An acceptable solution would be to
omit setitimer/getitimer on FreeBSD if the FreeBSD version is "wrong",
either at configure time or at compile time. An even better solution
would be to test at configure time whether these functions work, and
refuse to expose them if they don't (not sure whether that's possible,
though, as I don't know when the choice of threading library is made).

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

From report at bugs.python.org  Tue Apr  8 07:20:21 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Apr 2008 05:20:21 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207632021.73.0.663110088482.issue2578@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

In a separate bug report, Steve Purcell indicated that he was taking 
the module in the opposite direction and adding more redundancy in an 
effort to fully match the J-Unit API.

----------
assignee:  -> purcell
nosy: +purcell, rhettinger

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

From report at bugs.python.org  Tue Apr  8 07:23:18 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Apr 2008 05:23:18 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207632198.7.0.650559423778.issue2578@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I'm all for adding new APIs that provide new functionality (we have a
few at Google that we really should contribute).

I'm not for having several aliases for the same functionality; it maybe
the JUnit way but Python's unittest.py is not JUnit not does it strive
for 100% JUnit compatibility -- the languages just are to different.

What's the bug# for Steve's proposal?

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

From report at bugs.python.org  Tue Apr  8 07:38:06 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Tue, 08 Apr 2008 05:38:06 +0000
Subject: [issue2573] Can't change the framework name on OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1207633086.95.0.00265986979337.issue2573@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

To start: thanks for the patch.

I haven't done a detailed review yet, I have a minor nit: could you 
change  Mac/Makefile.in as well, specifically the definition:

PYTHONAPPSDIR=/Applications/MacPython $(VERSION)

This is used to install a number of GUI applications. "MacPython" should 
be replaced by the framework name. That will drop the "Mac" prefix in a 
default install, but that's not a problem and possibly confusing anyway.

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

From report at bugs.python.org  Tue Apr  8 07:44:00 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Apr 2008 05:44:00 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207633440.46.0.931981705543.issue2578@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

See http://bugs.python.org/issue2249 for discussion.

Personally, I prefer minimalism and would like the API thinned 
considerably.  Also, I don't think all of the classes should be 
exposed.  AFAICT, nobody cares about test suite objects, test result 
objects, and test loader objects.  These are really artifiacts of an 
implementation originally designed to demonstrate how a unittest suite 
could be implemented.   

In Kent Beck's book on Test Driven Development, he complains that most 
unittest implementations spawned from his original work have grown far 
too complicated and would be better served by sticking to a simple 
framework for writing and running tests.

Some of that may have been lost in a effort to model J-Unit or to 
expose all the parts in support of people who want to use subclassing 
to write their own unittest variants and extensions (I have seen this 
in practice but it is somewhat rare). 

If making big changes to the unittest API is on the table, it is worth 
considering alternatives like py.test which is more powerful, easier to 
learn, much less verbose, and more in line with the way python is 
usually written.

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

From report at bugs.python.org  Tue Apr  8 07:54:19 2008
From: report at bugs.python.org (Aaron Gallagher)
Date: Tue, 08 Apr 2008 05:54:19 +0000
Subject: [issue2573] Can't change the framework name on OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1207634059.59.0.978323542358.issue2573@psf.upfronthosting.co.za>


Aaron Gallagher <habnabit at gmail.com> added the comment:

Okay, here's the same patch but now with Mac/Makefile.in patched. I 
changed all references to Python to the framework name, because I believe 
it won't work properly otherwise.

Added file: http://bugs.python.org/file9979/framework2.patch

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

From report at bugs.python.org  Tue Apr  8 07:54:45 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Apr 2008 05:54:45 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207634085.37.0.574151791252.issue2578@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Agreed that the various loader classes etc. are mostly a waste.  The sad
thing is that everyone who is serious about unittests has to reinvent
the code that finds files ending in _test.py on the filesystem, or
something like that, since that's *not* supported directly.

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

From report at bugs.python.org  Tue Apr  8 08:07:13 2008
From: report at bugs.python.org (Jared Grubb)
Date: Tue, 08 Apr 2008 06:07:13 +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: <1207634833.9.0.803279960178.issue2182@psf.upfronthosting.co.za>


Jared Grubb <python at jaredgrubb.com> added the comment:

Yes, but exec(string) also gives a syntax error for \r\n:

exec('x=1\r\nprint x') 

The only explanation I could find for ONLY permitting \n as newlines in
 exec(string) comes from PEP278: "There is no support for universal
newlines in strings passed to eval() or exec. It is envisioned that such
strings always have the standard \n line feed, if the strings come from
a file that file can be read with universal newlines." (This is why my
original example had to be exec(file) and not just a simple exec(string))

Of the 3 newline types, exec(*) allows 1 or all 3 as the case may be,
and tokenize allows exactly 2 of them. I honestly am not sure what the
"right" way is (or should be), but either way, the tokenize module is
not consistent with exec.

(By the way, if you're curious why I filed this issue and Issue#2180,
I'm working on the PyPy project to help improve its current Python
lexer/parser. In order to ensure that it is correct and robust, I was
experimenting with corner cases in Python syntax and I found these cases
where tokenize disagrees with exec.)

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

From report at bugs.python.org  Tue Apr  8 08:12:05 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 08 Apr 2008 06:12:05 +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: <1207635125.01.0.53939093585.issue2182@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I recommend that you only care about \n and consider everything else
unspecified.

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

From report at bugs.python.org  Tue Apr  8 08:29:42 2008
From: report at bugs.python.org (Jared Grubb)
Date: Tue, 08 Apr 2008 06:29:42 +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: <1207636182.06.0.892348634647.issue2182@psf.upfronthosting.co.za>


Jared Grubb <python at jaredgrubb.com> added the comment:

I actually hadnt thought of that. PyPy should actually use universal
newlines to its advantage; after all, it IS written in Python... Thanks
for the suggestion!

In any case, I wanted to get this bug about the standard library in your
record, in case you wanted to handle it. It is fairly innocuous, so I'll
let it go. Take care.

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

From report at bugs.python.org  Tue Apr  8 10:01:34 2008
From: report at bugs.python.org (Steve Purcell)
Date: Tue, 08 Apr 2008 08:01:34 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207641694.82.0.47854556938.issue2578@psf.upfronthosting.co.za>


Steve Purcell <purcell at users.sourceforge.net> added the comment:

Hey, I'm open to anything.  If I started writing unittest from scratch 
knowing what I know now, I'd probably have kept the API a little 
slimmer.  Oh, and I'd have named everthing according to Python 
conventions; my deepest and belated apologies for that.

I think the design has held up pretty well, even if it's arguably not 
the most pythonic.  Its familiarity to users of other xUnit frameworks 
really does help new Pythoneers start writing tests immediately.  And as 
for the TestLoader stuff, it looks (and perhaps is) a bit overblown, but 
I can't count the number of times people have asked me how to do obscure 
or unusual things with the module and I've been able to respond with 
something like, "just write a custom TestLoader/TestRunner".

I don't intend to take unittest in any particular direction; truth be 
told, I'm now only an occasional visitor to the land of Python, and I 
don't think I've had commit rights since the move to subversion.  My 
continued involvement with the unittest tickets is mainly to help 
provide input along the lines of "we discussed this years ago, and 
decided against it / thought it would be great".  Far be it from me to 
stand in the way of progress -- I'd be happy to see unittest re-worked 
in any way that makes sense.

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

From report at bugs.python.org  Tue Apr  8 13:49:35 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 08 Apr 2008 11:49:35 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207655375.27.0.107239638914.issue2550@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Invested quite a few cycles on this issue last night.  The more time I 
spent on it, the more I became convinced that every single test working 
with sockets should be changed in one fell swoop in order to facilitate 
(virtually unlimited) parallel test execution without fear of port 
conflicts.

I've attached a second patch, trunk.2550-2.patch, which is my progress 
so far on doing just this.  The main changes can be expressed by the 
following two points:

a) do whatever it takes in network-oriented tests to ensure
   unique ports are obtained (relying on the bind_port() and
   find_unused_port() methods exposed by test_support)

b) never, ever, ever call SO_REUSEADDR on a socket from a test;
   because we're putting so much effort into obtaining a unique
   port, this should never be necessary -- in the rare cases that
   our attempts to obtain a unique port fail, then we absolutely
   should fail with EADDRINUSE, as the ability to obtain a unique
   port for the duration of a client/server test is an invariant
   that we *must* be able to depend upon.  If the invariant is
   broken, fail immediately (don't mask the problem with 
   SO_REUSEADDR).

With this patch applied, I can spawn a handful of Python processes and 
run the entire test suite (without -r, ensuring all tests are run in 
the same order, which should encourage port conflicts (if there were 
any)) without any errors*.  Doing that now is completely and utterly 
impossible.

[*] Well, almost without error.  All the I/O related tests that try and 
open @test fail.

I believe there's still outstanding work to do with this patch with 
regards to how the intracacies of SO_REUSEADDR and SO_EXCLUSIVEADDRUSE 
should be handled in the rest of the stdlib.  I'm still thinking about 
the best approach for this.  However, the patch as it currently stands 
is still quite substantial so I wanted to get it out sooner rather than 
later for review.

(I'll forward this to python-dev@ to try and encourage more eyes from 
people with far more network-fu than I.)

Added file: http://bugs.python.org/file9980/trunk.2550-2.patch

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

From report at bugs.python.org  Tue Apr  8 13:58:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Apr 2008 11:58:57 +0000
Subject: [issue2574] Add RFC 3768 SSM Multicast support to "socket"
In-Reply-To: <47FAED20.6020006@incunabulum.net>
Message-ID: <1afaf6160804080458k30c7da9dnb934307c5a5b28c7@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok, we'll see what we can do.

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

From report at bugs.python.org  Tue Apr  8 14:39:02 2008
From: report at bugs.python.org (Anand B Pillai)
Date: Tue, 08 Apr 2008 12:39:02 +0000
Subject: [issue2582] Unpickling of range objects fail in Py3k
In-Reply-To: <1207658342.58.0.573226897239.issue2582@psf.upfronthosting.co.za>
Message-ID: <1207658342.58.0.573226897239.issue2582@psf.upfronthosting.co.za>


New submission from Anand B Pillai <abpillai at gmail.com>:

Unpickling of range objects is throwing an exception in Python 3.0

----------
components: Interpreter Core, Library (Lib)
files: bugdemo.py
messages: 65157
nosy: pythonhacker
severity: normal
status: open
title: Unpickling of range objects fail in Py3k
versions: Python 3.0
Added file: http://bugs.python.org/file9981/bugdemo.py

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

From report at bugs.python.org  Tue Apr  8 15:26:24 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Apr 2008 13:26:24 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207661184.56.0.396312221678.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

> For writing the metadata, we don't need to make any assumptions. We
> can just write the bytes as-is. This is how distutils has behaved
> for many releases now, and this is how users have been using it.

But write_pkg_file will use ascii encoding if we don't indicate it
here:

>>> pkg_info.write('Author: %s\n' % self.get_contact() )

So wouldn't a light fix in write_pkg_file() would be sufficient when a
unicode(field) fails, as MAL mentioned ? by trying utf8:

>>> try:
...    pkg_info.write('Author: %s\n' % self.get_contact() )
... except UnicodeEncodeError:
...    pkg_info.write('Author: %s\n' % self.get_contact().encode('utf8') ) 


As far as I know, this simple change will not impact people and will
just make it possible to use Unicode. And everything will be fine under
Py3K as it is now.

But I don't know yet how this would impact 3rd party softwares that reads
the egg-info file. But like MAL said, they will have to get fixed as well.

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

From report at bugs.python.org  Tue Apr  8 15:51:05 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 08 Apr 2008 13:51:05 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
In-Reply-To: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>
Message-ID: <1207662665.75.0.938540771718.issue2564@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Ahh, more FreeBSD threading woes.  If no-one beats me to it, I'll be 
able to start taking a look at this when our FreeBSD 7 server is up in 
a week or so.

----------
assignee:  -> Trent.Nelson
nosy: +Trent.Nelson

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

From report at bugs.python.org  Tue Apr  8 15:52:38 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 08 Apr 2008 13:52:38 +0000
Subject: [issue2563] embed manifest in windows extensions
In-Reply-To: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>
Message-ID: <1207662758.5.0.254053483868.issue2563@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

+1 from me on principle (haven't tested).

----------
nosy: +Trent.Nelson

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

From report at bugs.python.org  Tue Apr  8 15:53:26 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 08 Apr 2008 13:53:26 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
In-Reply-To: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>
Message-ID: <1207662806.33.0.873003921149.issue2564@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Hi Trent,

FreeBSD 7 uses libthr as default, which would possibly eliminate this
problem.

----------
nosy: +gpolo

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

From report at bugs.python.org  Tue Apr  8 15:56:58 2008
From: report at bugs.python.org (monk.e.boy)
Date: Tue, 08 Apr 2008 13:56:58 +0000
Subject: [issue2583] urlparse normalize URL path
In-Reply-To: <1207663018.75.0.231530474022.issue2583@psf.upfronthosting.co.za>
Message-ID: <1207663018.75.0.231530474022.issue2583@psf.upfronthosting.co.za>


New submission from monk.e.boy <johng at neutralize.com>:

Hi,
  This is my first problem with anything Python :-) and my first issue.

  Doing in the following:

  urlparse.urljoin( 'http://site.com/', '../../../../path/' )
  'http://site.com/../../../../path/'

  urlparse.urljoin( 'http://site.com/', '/path/../path/.././path/./' )
  'http://site.com/path/../path/.././path/./'

These URLs are normalized to http://site.com/path/ in both Firefox and
Google (the google spider would follow these OK)

  I think the documentation could be improved to point at the
posixpath.py normpath function and how it solves the above. I blogged a
how to:

http://teethgrinder.co.uk/blog/Normalize-URL-path-python/

I hope my bug report is OK. Thanks for all the code :-)

johng at neutralize.com

----------
components: Library (Lib)
messages: 65162
nosy: monk.e.boy
severity: normal
status: open
title: urlparse normalize URL path
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 16:00:54 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 08 Apr 2008 14:00:54 +0000
Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock)
In-Reply-To: <1195766591.59.0.212085206705.issue1489@psf.upfronthosting.co.za>
Message-ID: <1207663254.42.0.534103380569.issue1489@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Re-assigned this to myself (hope you don't mind janssen ;-) as I'm 
actively looking into it.  We build openssl.exe as part of our Windows 
build so we should make an effort to use this where possible.  Note 
that there is definitely a problem with 'openssl s_server' on Windows, 
I'm not sure if it's to do with buffering though as I can step through 
the same actions the test is performing in the console and I 
get 'ERROR\n' immediately back from the server.  This sort of falls 
into my existing work with issue 2550 (and patches) to improve network-
oriented tests such that they can be ran in parallel.  Note that patch 
trunk.2550-2.patch attached to issue2550 goes as far as converting 
openssl to use the -accept [port] option such that we don't bind on 
4443 by default (thus impeding other test_ssl_socket tests that may be 
running).

Also, openssl.exe in the s_server mode is using SO_REUSEADDR when it 
should be using SO_EXCLUSIVEADDRUSE.  That's not our problem per se, 
but given that we maintain our own openssl-0.9.8g sources, I'm 
considering fixing it if it improves the reliability of the test.  
(I'll feed back any changes to the OpenSSL project, of course.)

----------
assignee: janssen -> Trent.Nelson
nosy: +Trent.Nelson

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

From report at bugs.python.org  Tue Apr  8 16:06:11 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 08 Apr 2008 14:06:11 +0000
Subject: [issue1220212] os.kill on windows
Message-ID: <1207663571.8.0.284080598021.issue1220212@psf.upfronthosting.co.za>


Changes by Trent Nelson <tnelson at onresolve.com>:


----------
nosy: +Trent.Nelson

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

From report at bugs.python.org  Tue Apr  8 16:08:35 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 08 Apr 2008 14:08:35 +0000
Subject: [issue2563] embed manifest in windows extensions
In-Reply-To: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>
Message-ID: <1207663715.91.0.378852564203.issue2563@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Yes, it's me ;)

I'm +1 on the feature but I haven't reviewed your patch. IIRC and unless
I'm not mistaken you can tell the linker to embed the manifest without
the extra mt.exe dance.

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

From report at bugs.python.org  Tue Apr  8 16:35:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 14:35:33 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
In-Reply-To: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>
Message-ID: <1207665333.07.0.732603620045.issue2564@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think that this problem is not FreeBSD specific:
- "import test.autotest" runs the whole test suite as a side-effect of
an import statement.
- in the test suite test_capi spawns threads, which also import.
- a lock ensues...

See for example test_threaded_import.py::

    if imp.lock_held():
        # This triggers on, e.g., from test import autotest.
        raise TestSkipped("can't run when import lock is held")

I the test_capi case, I think that the two imports in TestThreadState
should be moved outside the function.

Also, the backtrace file shows two other threads locked in a "import
socket" statement. I suspect problems in test_urllib2.py or
test_urllib2net.py...

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

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

From report at bugs.python.org  Tue Apr  8 17:09:52 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 15:09:52 +0000
Subject: [issue2410] absolute import doesn't work for standard python modules
In-Reply-To: <1205875676.38.0.76467063797.issue2410@psf.upfronthosting.co.za>
Message-ID: <1207667392.62.0.0477858197283.issue2410@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Running the interactive interpreter like that places the current
directory on sys.path, so it *is* doing an absolute import of your
pseudo email package. (If it didn't do that, your test would fail at the
"import foo" line)

Instead of cd'ing into test the way you did, invoke the interpreter from
the next directory up and do an import of 'test.foo', and you should see
the absolute imports in the foo module having the desired effect.

(I expect the reason you didn't run into this for the os module is
because the os module is bootstrapped quite early in Python's startup
process, so you'd have to try really hard to get it to see something
other than the builtin standard library version of os)

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

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

From report at bugs.python.org  Tue Apr  8 17:19:13 2008
From: report at bugs.python.org (Tim Wilcoxson)
Date: Tue, 08 Apr 2008 15:19:13 +0000
Subject: [issue2584] numeric overflow in IDLE
In-Reply-To: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>
Message-ID: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>


New submission from Tim Wilcoxson <qodosh at gmail.com>:

According to the documentation there is not suppose to be numeric
overflow in python 2.5. However....

If you run a for loop with the range(1, 300000000)a couple of times (for
me 2 or 3 times worked) in the IDLE (1.2.2)GUI . It will cause what
appears to be a memory leak, at least under vista home edition. Haven't
tested out other platforms yet. Vista's logon process will fail to start
security dialog as well if you try to ctrl-alt-del. Which effectively
cripples the system. I haven't tested to see if the condition will get
better over long period of time. I've waited a max of 10 minutes for the
system to respond. 

I tested running the script multiple times under cmd in windows, and it
spits out a memory error after a minute of not responding and then the
cmd prompts will close and the system will begin responding. So it
appears to be isolated to IDLE.

----------
components: IDLE
files: for_loop.py
messages: 65167
nosy: Qodosh
severity: normal
status: open
title: numeric overflow in IDLE
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file9982/for_loop.py

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

From report at bugs.python.org  Tue Apr  8 17:19:25 2008
From: report at bugs.python.org (djc)
Date: Tue, 08 Apr 2008 15:19:25 +0000
Subject: [issue2585] urllib2.HTTPError broken due to urllib.addinfourl changes
In-Reply-To: <1207667965.33.0.297258961494.issue2585@psf.upfronthosting.co.za>
Message-ID: <1207667965.33.0.297258961494.issue2585@psf.upfronthosting.co.za>


New submission from djc <dirkjan at ochtman.nl>:

djc at enrai tests $ python2.6
Python 2.6a2+ (trunk, Apr  4 2008, 20:21:45)
[GCC 4.1.2 20070214 (  (gdc 0.24, using dmd 1.020)) (Gentoo 4.1.2
p1.0.2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import urllib2
>>> try:
...     urllib2.urlopen('http://example.com/weird')
... except urllib2.HTTPError, inst:
...     print inst.code
...
None
>>>

urllib.addinfourl.__init__() was changed in r60133 to set self.code.
Unfortunately, this overrides HTTPError.code, which is probably not good.

----------
components: Library (Lib)
messages: 65168
nosy: birkenfeld, djc
severity: normal
status: open
title: urllib2.HTTPError broken due to urllib.addinfourl changes
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr  8 17:32:16 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Apr 2008 15:32:16 +0000
Subject: [issue2197] Further simplify dict literal bytecode
In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>
Message-ID: <1207668735.95.0.188478114609.issue2197@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Python-3000 discussion <http://mail.python.org/pipermail/python-
3000/2008-March/012753.html> did not reveal any opposition to the idea 
of batch processing of dict displays.  However, a compromise suggestion 
was made to  limit batches to 256 items 
<http://mail.python.org/pipermail/python-3000/2008-March/012829.html>.   
I don't think this type of micro-optimization belongs to the core.  A 
rare application that would benefit from limited size batch processing 
can do so explicitly using dict.update.

See also relevant discussion at issue2292 (starting at msg65111).

I believe this issue can be reopen.  I will submit documentation patch 
if the change is accepted in principle.

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

From report at bugs.python.org  Tue Apr  8 17:38:31 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 08 Apr 2008 15:38:31 +0000
Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock)
In-Reply-To: <1195766591.59.0.212085206705.issue1489@psf.upfronthosting.co.za>
Message-ID: <1207669111.2.0.891653892483.issue1489@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Fine with me.  I don't have a checkout of the code handy, but I believe
this is obsolete test code.  All the SSL tests are, or should be, in
test_ssl, for 2.6 and 3.x.  The right fix is to remove it.

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

From report at bugs.python.org  Tue Apr  8 17:41:40 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:41:40 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The zlib module in multiple places fails to adequately check the sanity
of its arguments resulting in memory corruption, please see two attached
PoCs.

----------
components: Extension Modules
files: python-2.5.2-zlib-unflush-misallocation.py
messages: 65171
nosy: jnferguson
severity: normal
status: open
title: Integer signedness bugs in zlib modules
type: security
versions: Python 2.5
Added file: http://bugs.python.org/file9983/python-2.5.2-zlib-unflush-misallocation.py

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

From report at bugs.python.org  Tue Apr  8 17:42:05 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:42:05 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207669325.81.0.686862409426.issue2586@psf.upfronthosting.co.za>


Changes by Justin Ferguson <justin.ferguson at ioactive.com>:


Added file: http://bugs.python.org/file9984/python-2.5.2-zlib-unflush-signedness.py

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

From report at bugs.python.org  Tue Apr  8 17:49:08 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:49:08 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsane
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The PyString_FromStringAndSize() function takes a pointer and signed
integer as input parameters however it fails to adequately check the
sanity of the integer argument. Because of the failure to check for
negative values and because it sums the integer with the size of the
PyStringObject structure it becomes possible for the allocator to take
either of the code paths in PyObject_MALLOC()-- both of which will
incorrectly allocate memory.

This may not seem like a big deal, but I'm posting this instead of
filing a bug for every place this screws you guys over.

if (0 > len || len > PYSSIZE_T_MAX/sizeof(PyStringObject)) 
        return NULL;

----------
components: Interpreter Core
messages: 65172
nosy: jnferguson
severity: normal
status: open
title: PyString_FromStringAndSize() to be considered unsane
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 17:54:56 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Apr 2008 15:54:56 +0000
Subject: [issue2197] Further simplify dict literal bytecode
In-Reply-To: <1204087358.25.0.336185650198.issue2197@psf.upfronthosting.co.za>
Message-ID: <1207670096.32.0.939984211533.issue2197@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1   I don't think this is worth the semantic change.  The current 
approach doesn't require special cases for different dict sizes. The 
code/time savings is very small (seven bytes of opcodes per item get 
condensed by only one byte and the cost of one time around the eval-
loop is tiny in comparison to the cost of inserting a new dict entry).  
Besides, dict literals almost never occur in the inner-loops of time 
critical code. 

I recommend that this stay closed.  Better to aim for meaningful 
optimizations using the AST and avoid micro-optimizations that subtly 
change semantics.

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

From report at bugs.python.org  Tue Apr  8 17:55:10 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:55:10 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The PyOS_vsnprintf() contains the caveat that the length parameter
cannot be zero, however this is only enforced via assert() which is
compiled out. As a result if the length parameter is zero then the
function will underflow and write a null byte to invalid memory.

 53 int
 54 PyOS_vsnprintf(char *str, size_t size, const char  *format, va_list va)
 55 {
 56         int len;  /* # bytes written, excluding \0 */
 57 #ifndef HAVE_SNPRINTF
 58         char *buffer;
 59 #endif
 60         assert(str != NULL);
 61         assert(size > 0);
 62         assert(format != NULL);
 [...]
 65         len = vsnprintf(str, size, format, va);
 [...]
 91         str[size-1] = '\0';
 92         return len;
 93 }

----------
components: Distutils
messages: 65174
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() underflow leads to memory corruption
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 17:55:22 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:55:22 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207670122.97.0.453302195768.issue2588@psf.upfronthosting.co.za>


Changes by Justin Ferguson <justin.ferguson at ioactive.com>:


----------
components: +Interpreter Core -Distutils

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

From report at bugs.python.org  Tue Apr  8 17:59:49 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 15:59:49 +0000
Subject: [issue2589] PyOS_vsnprintf() potential integer overflow leads to
	memory corruption on esoteric architectures
In-Reply-To: <1207670389.49.0.356116216637.issue2589@psf.upfronthosting.co.za>
Message-ID: <1207670389.49.0.356116216637.issue2589@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

On architectures that do not have a vsnprintf() in their standard
library Python attempts to emulate it. When doing so, the implementation
ambitiously allocates more memory than requested without verifying the
sanity of the summed value. As a result it becomes possible (although
unlikely) for an integer overflow to occur misallocating memory and
causing a buffer overflow.

 53 int
 54 PyOS_vsnprintf(char *str, size_t size, const char  *format, va_list va)
 55 {
 56         int len;  /* # bytes written, excluding \0 */
[...]
 60         assert(str != NULL);
 61         assert(size > 0);
 62         assert(format != NULL);
 63 
[...]
 67         /* Emulate it. */
 68         buffer = PyMem_MALLOC(size + 512);
 69         if (buffer == NULL) {
 70                 len = -666;
 71                 goto Done;
 72         }
 73 
 74         len = vsprintf(buffer, format, va);
 75         if (len < 0)
 76                 /* ignore the error */;
 77 
 78         else if ((size_t)len >= size + 512)
 79                 Py_FatalError("Buffer overflow in
PyOS_snprintf/PyOS_vsnprintf");
 80 
 81         else {
 82                 const size_t to_copy = (size_t)len < size ?
 83                                         (size_t)len : size - 1;
 84                 assert(to_copy < size);
 85                 memcpy(str, buffer, to_copy);
 86                 str[to_copy] = '\0';
 87         }
 88         PyMem_FREE(buffer);
 89 Done:
[...]
 91         str[size-1] = '\0';
 92         return len;
 93 }

----------
components: Interpreter Core
messages: 65175
nosy: jnferguson
severity: normal
status: open
title: PyOS_vsnprintf() potential integer overflow leads to memory corruption on esoteric architectures
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:04:16 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Apr 2008 16:04:16 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207670656.69.0.608395500892.issue2586@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Verified that the script crashes Python.

----------
nosy: +rhettinger
priority:  -> critical

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

From report at bugs.python.org  Tue Apr  8 18:08:32 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 16:08:32 +0000
Subject: [issue2584] numeric overflow in IDLE
In-Reply-To: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>
Message-ID: <1207670912.51.0.872516060364.issue2584@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I wonder why do you suspect a numeric overflow.

It may very well be that the system needs more time to become
responsive, when the script is run by Idle.
Idle actually spawns another python process to execute commands.

> then the cmd prompts will close
Did you try to close the cmd window?

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

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

From report at bugs.python.org  Tue Apr  8 18:09:35 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:09:35 +0000
Subject: [issue2590] S_unpack_from() Read Access Violation
In-Reply-To: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>
Message-ID: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The S_unpack_from() function in Modules/_struct.c does not adequately
validate its arguments, potentially causing an out-of-bounds read
access. It should be noted that the check at line 1561 is inadequate for
obscene values of offset. Finally, because they're not really important
and I really don't want to type them all up-- you guys might want to go
through your code-- especially the modules and look for constructs where
an empty string will cause memory to be uninitialized-- look at the
audioop module for examples of what I mean-- the only thing that
actually saved you guys from overflows there was that the loops you
write with use the same variable. 

1533 static PyObject *
1534 s_unpack_from(PyObject *self, PyObject *args, PyObject *kwds)
1535 {
1536         static char *kwlist[] = {"buffer", "offset", 0};
1537 #if (PY_VERSION_HEX < 0x02050000)
1538         static char *fmt = "z#|i:unpack_from";
1539 #else
1540         static char *fmt = "z#|n:unpack_from";
1541 #endif
1542         Py_ssize_t buffer_len = 0, offset = 0;
[...]
1547 
1548         if (!PyArg_ParseTupleAndKeywords(args, kwds, fmt, kwlist,
1549                                          &buffer, &buffer_len,
&offset))
1550                 return NULL;
[...]
1558         if (offset < 0)
1559                 offset += buffer_len;
1560 
1561         if (offset < 0 || (buffer_len - offset) < soself->s_size) {
[...]
1566         }
1567         return s_unpack_internal(soself, buffer + offset);
1568 }

----------
components: Extension Modules
messages: 65178
nosy: jnferguson
severity: normal
status: open
title: S_unpack_from() Read Access Violation
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:10:13 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 16:10:13 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1207671013.9.0.764781222134.issue643841@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I spent an enlightening evening browsing through the source code for
weakref.proxy. The way that code works is to define every slot,
delegating to the proxied object to handle each call (wrapping and
unwrapping the proxied object as needed).

This is normally transparent to the user due to the fact that
__getattribute__ is one of the proxied methods (and at the C level, the
delegated slot invocations return NotImplemented or set the appropriate
exceptions). The only way it shows through is the fact that
operator.isNumber and operator.isMapping will always return True for the
proxy instance, and operator.isSequence will always return False - this
is due to the proxy type filling in the number and mapping slots, but
not the sequence slots.

However, this prompted me to try an experiment (Python 2.5.1), and the
results didn't fill me with confidence regarding the approach of
expecting 3rd party developers to explicitly delegate all of the special
methods:

>>> class Demo:
...   def __index__(self):
...     return 1
...
>>> a = Demo()
>>> b = weakref.proxy(a)
>>> operator.index(a)
1
>>> operator.index(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'weakproxy' object cannot be interpreted as an index

Oops.

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

From report at bugs.python.org  Tue Apr  8 18:13:33 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:13:33 +0000
Subject: [issue2591] ErrorHandler buffer overflow in ?unused? SGI extension
	module almodule.c
In-Reply-To: <1207671213.37.0.514219749989.issue2591@psf.upfronthosting.co.za>
Message-ID: <1207671213.37.0.514219749989.issue2591@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

I don't think any of these SGI modules even get used, but they're really
buggy-- you guys might want to consider just dropping them all together.

When printing errors larger than 128 bytes a stack based overflow occurs.

  44 static void
  45 ErrorHandler(long code, const char *fmt, ...)
  46 {
  47         va_list args;
  48         char buf[128];
  49 
  50         va_start(args, fmt);
  51         vsprintf(buf, fmt, args);
  52         va_end(args);
  53         PyErr_SetString(ErrorObject, buf);
  54 }

----------
components: Extension Modules
messages: 65180
nosy: jnferguson
severity: normal
status: open
title: ErrorHandler buffer overflow in ?unused? SGI extension module almodule.c
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:17:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 16:17:13 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsane
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207671433.53.0.664537707653.issue2587@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

This is done already:
the second line in PyString_FromStringAndSize() is
    assert(size>=0);
You have to build python in debug mode though...

Oh, I realize this is not a real patch: no error is raised, and why
PYSSIZE_T_MAX/sizeof(PyStringObject), when the allocation is    
PyObject_MALLOC(sizeof(PyStringObject)+size)?

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

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

From report at bugs.python.org  Tue Apr  8 18:17:43 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 16:17:43 +0000
Subject: [issue2592] weakref.proxy fails to delegate tp_index slot
In-Reply-To: <1207671463.8.0.448450429291.issue2592@psf.upfronthosting.co.za>
Message-ID: <1207671463.8.0.448450429291.issue2592@psf.upfronthosting.co.za>


New submission from Nick Coghlan <ncoghlan at gmail.com>:

>From the discussion of issue 643841:

>>> class Demo:
...   def __index__(self):
...     return 1
...
>>> a = Demo()
>>> b = weakref.proxy(a)
>>> operator.index(a)
1
>>> operator.index(b)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'weakproxy' object cannot be interpreted as an index

The weakref proxy types need to be updated to delegate 2.5's new
tp_index slot.

----------
components: Library (Lib)
messages: 65182
nosy: ncoghlan
severity: normal
status: open
title: weakref.proxy fails to delegate tp_index slot
versions: Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Apr  8 18:18:29 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:18:29 +0000
Subject: [issue2593] alp_ReadFrames() integer overflow leads to buffer overflow
In-Reply-To: <1207671509.18.0.228221414786.issue2593@psf.upfronthosting.co.za>
Message-ID: <1207671509.18.0.228221414786.issue2593@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

Please see bug 2591 for a suggestion on what to do with these SGI modules.
(sorry I don't have any pocs/repros I dont have an sgi box handy atm)

Integer overflow/invalid allocation at 768, write to memory at 773

 716 static PyObject *
 717 alp_ReadFrames(alpobject *self, PyObject *args)
 718 {
 719         int framecount;
 720         PyObject *v;
 721         int size;
 722         int ch;
 723         ALconfig c;
 724 
 725         if (!PyArg_ParseTuple(args, "i:ReadFrames", &framecount))
 726                 return NULL;
 727         if (framecount < 0) {
 728                 PyErr_SetString(ErrorObject, "negative framecount");
 729                 return NULL;
 730         }
[...] 732         switch (alGetSampFmt(c)) {
 733         case AL_SAMPFMT_TWOSCOMP:
 734                 switch (alGetWidth(c)) {
 735                 case AL_SAMPLE_8:
 736                         size = 1;
 737                         break;
 738                 case AL_SAMPLE_16:
 739                         size = 2;
 740                         break;
 741                 case AL_SAMPLE_24:
 742                         size = 4;
 743                         break;
 744                 default:
 745                         PyErr_SetString(ErrorObject, "can't
determine width");
 746                         alFreeConfig(c);
 747                         return NULL;
 748                 }
 749                 break;
 750         case AL_SAMPFMT_FLOAT:
 751                 size = 4;
 752                 break;
 753         case AL_SAMPFMT_DOUBLE:
 754                 size = 8;
 755                 break;
 756         default:
 757                 PyErr_SetString(ErrorObject, "can't determine format");
 758                 alFreeConfig(c);
 759                 return NULL;
 760         }
 761         ch = alGetChannels(c);
 762         alFreeConfig(c);
 763         if (ch < 0) {
 764                 PyErr_SetString(ErrorObject, "can't determine # of
channels");
 765                 return NULL;
 766         }
 767         size *= ch;
 768         v = PyString_FromStringAndSize((char *) NULL, size *
framecount);
 769         if (v == NULL)
 770                 return NULL;
 771 
[...] 
 773         alReadFrames(self->port, (void *) PyString_AS_STRING(v),
framecount);

----------
components: Extension Modules
messages: 65183
nosy: jnferguson
severity: normal
status: open
title: alp_ReadFrames() integer overflow leads to buffer overflow
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:21:23 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 16:21:23 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207671683.87.0.539507857142.issue2588@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think that programming errors against the python API are best checked
with asserts: I develop in development mode (with asserts enabled), then
I want my released program to run at full speed.

Other thoughts?

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

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

From report at bugs.python.org  Tue Apr  8 18:23:13 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:23:13 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsane
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207671793.13.0.384664391558.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

The problem with assert()'s is they require debugging to be enabled,
obviously, who compiles it that way?

You may not even want to worry about the second check, when you pass it
into the allocator it gets converted to an unsigned int which will cause
the allocator to either fail (32-bit) or allocate more memory than
expected-- either cause it handled/benign.

If you'd prefer I can file every place where this actually bites you
guys, I was just trying to be nice.

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

From report at bugs.python.org  Tue Apr  8 18:26:04 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:26:04 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207671963.95.0.566978990725.issue2588@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

I can generally agree with that, and I admit I haven't verified all of
the code paths here- theres several hundred of them leading into this
function, are you positive all of them are safe? (seems like it would be
easier to just move the check into an if than sitting down and verifying
that all XXX hundred code paths are safe).

In the other bug, I have verified code paths into it, for instance test
the misallocation poc in 2586 as an example

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

From report at bugs.python.org  Tue Apr  8 18:27:22 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:27:22 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsane
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207672042.4.0.597775557096.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Adding a poc from 2586 to demonstrate my point, this causes a call to
the allocator requesting zero bytes.

Added file: http://bugs.python.org/file9985/python-2.5.2-zlib-unflush-misallocation.py

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

From report at bugs.python.org  Tue Apr  8 18:31:43 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:31:43 +0000
Subject: [issue2594] alp_readsamps() overflow leads to memory corruption in
	?unused? SGI extension module almodule.c
In-Reply-To: <1207672303.58.0.550731547679.issue2594@psf.upfronthosting.co.za>
Message-ID: <1207672303.58.0.550731547679.issue2594@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

You guys should probably just remove the SGI modules, the code looks
like it hasn't been touched in some time and hasn't gone through the
same security checks as other pieces of code. Sorry I have no
repro's/pocs, I don't have an irix box either though ;]

integer overflow/misallocation occurs at 1071, write to bad memory at 1076

1042 alp_readsamps(alpobject *self, PyObject *args)
1043 {
1044         long count;
1045         PyObject *v;
1046         ALconfig c;
1047         int width;
1048         int ret;
1049 
1050         if (!PyArg_ParseTuple(args, "l:readsamps", &count))
1051                 return NULL;
1052 
1053         if (count <= 0) {
1054                 PyErr_SetString(ErrorObject, "al.readsamps : arg <=
0");
1055                 return NULL;
1056         }
1057 
1058         c = ALgetconfig(self->port);
1059 #ifdef AL_405
1060         width = ALgetsampfmt(c);
1061         if (width == AL_SAMPFMT_FLOAT)
1062                 width = sizeof(float);
1063         else if (width == AL_SAMPFMT_DOUBLE)
1064                 width = sizeof(double);
1065         else
1066                 width = ALgetwidth(c);
1067 #else
1068         width = ALgetwidth(c);
1069 #endif /* AL_405 */
1070         ALfreeconfig(c);
1071         v = PyString_FromStringAndSize((char *)NULL, width * count);
1072         if (v == NULL)
1073                 return NULL;
1074 
1075         Py_BEGIN_ALLOW_THREADS
1076         ret = ALreadsamps(self->port, (void *)
PyString_AsString(v), count);
1077         Py_END_ALLOW_THREADS
1078         if (ret == -1) {
1079                 Py_DECREF(v);
1080                 return NULL;
1081         }
1082 
1083         return (v);
1084 }

----------
components: Extension Modules
messages: 65188
nosy: jnferguson
severity: normal
status: open
title: alp_readsamps() overflow leads to memory corruption in ?unused? SGI extension module almodule.c
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 18:45:38 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Apr 2008 16:45:38 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207673137.98.0.586877225196.issue2541@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

You can't change the codec - it's being used in other places as well,
e.g. for use cases where you need to have a 7-bit encoded readable
version of a Unicode object.

Adding a new codec would be fine, though I don't know how this would map
raw Unicode strings with non-ASCII characters in them to an 8-bit
string. Perhaps this is not needed at all in Py3k.

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

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

From report at bugs.python.org  Tue Apr  8 18:46:43 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 16:46:43 +0000
Subject: [issue2592] weakref.proxy fails to delegate tp_index slot
In-Reply-To: <1207671463.8.0.448450429291.issue2592@psf.upfronthosting.co.za>
Message-ID: <1207673203.05.0.858845810238.issue2592@psf.upfronthosting.co.za>


Changes by Nick Coghlan <ncoghlan at gmail.com>:


----------
priority:  -> normal

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

From report at bugs.python.org  Tue Apr  8 18:48:33 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 16:48:33 +0000
Subject: [issue2592] weakref.proxy fails to delegate tp_index slot
In-Reply-To: <1207671463.8.0.448450429291.issue2592@psf.upfronthosting.co.za>
Message-ID: <1207673313.73.0.746650851258.issue2592@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Marking as easy - it should be possible to just look at what the code in
Objects\weakref.c is already doing for slots like tp_len and tp_int and
do the same thing for tp_index.

----------
keywords: +easy

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

From report at bugs.python.org  Tue Apr  8 18:49:18 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:49:18 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207673358.84.0.480822615953.issue2586@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Just so you know, the scripts actually do two different things-- the
bugs are both related to negative values though. One causes
PyString_FromStringAndSize() to try an allocate zero bytes (the -24
one), the other causes like 22 bytes to get allocated and then takes
advantage of the sign-conversion when the value is assigned to the zlib
structure member (the member is unsigned, the value is signed)

Honestly, you guys should consider enforcing the safe downcast usage
because signedness issues are all over your code base (as I'm sure you know)

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

From report at bugs.python.org  Tue Apr  8 18:51:01 2008
From: report at bugs.python.org (Tim Wilcoxson)
Date: Tue, 08 Apr 2008 16:51:01 +0000
Subject: [issue2584] numeric overflow in IDLE
In-Reply-To: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>
Message-ID: <1207673461.92.0.89105660757.issue2584@psf.upfronthosting.co.za>


Tim Wilcoxson <qodosh at gmail.com> added the comment:

msg65177, i did try to close cmd. thats why it closed. i wasnt clear
enough. my apologies.  it merely lags in command line in gives a memory
error. in IDLE, it wont respond, and it gives a logon process erorr in
windows if you try to view the security dialog. Let's just say this. i
got dressed, walked out my apartment several flights of strairs, went
across a large parking lot, grabbed a bag, came back, got comfortable,
looked at my computer, and it was still completely unresponsive. I did
this several times, same problem.

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

From report at bugs.python.org  Tue Apr  8 18:52:31 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 16:52:31 +0000
Subject: [issue1536059] Missing builtin help for with and as
Message-ID: <1207673551.18.0.920996009164.issue1536059@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Georg Brandl applied Santiago's patch in rev. 54329, 54330

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

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

From report at bugs.python.org  Tue Apr  8 18:56:40 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 16:56:40 +0000
Subject: [issue2595] Multiple integer overflows in imgfile extension module
	lead to buffer overflow
In-Reply-To: <1207673799.86.0.811482353328.issue2595@psf.upfronthosting.co.za>
Message-ID: <1207673799.86.0.811482353328.issue2595@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

The imgfile module contains multiple integer overflows, this module is
only used on SGI boxes and is likely mostly unused and thus is fairly
low priority imho-- no repros, no poc, no sgi box :/

I'm only going to post one to give you the idea, there's no need for me
to (further) spam the bug database by filing a bug for each one of
these, they're all pretty much the same.

Here the variables xsize, ysize and zsize are all externally derived.
While xsize and zsize are sanity checked, ysize is not. This potentially
results in an integer overflow/misallocation at line 133 and writes to
invalid memory in the calls to getrow()

 85 static PyObject *
 86 imgfile_read(PyObject *self, PyObject *args)
 87 {
 88         char *fname;
 89         PyObject *rv;
 90         int xsize, ysize, zsize;
 91         char *cdatap;
 92         long *idatap;
 93         static short rs[8192], gs[8192], bs[8192];
 94         int x, y;
 95         IMAGE *image;
 96         int yfirst, ylast, ystep;
 97
 98         if ( !PyArg_ParseTuple(args, "s:read", &fname) )
 99                 return NULL;
100    
101         if ( (image = imgfile_open(fname)) == NULL )
102                 return NULL;
[...]
116         xsize = image->xsize;
117         ysize = image->ysize;
118         zsize = image->zsize;
119         if ( zsize != 1 && zsize != 3) {
120                 iclose(image);
121                 PyErr_SetString(ImgfileError,
122                                 "Can only handle 1 or 3 byte pixels");
123                 return NULL;
124         }
125         if ( xsize > 8192 ) {
126                 iclose(image);
127                 PyErr_SetString(ImgfileError,
128                                 "Can't handle image with > 8192
columns");
129                 return NULL;
130         }
131 
132         if ( zsize == 3 ) zsize = 4;
133         rv = PyString_FromStringAndSize((char *)NULL,
xsize*ysize*zsize);
134         if ( rv == NULL ) {
138         cdatap = PyString_AsString(rv);
139         idatap = (long *)cdatap;
[...]
150         for ( y=yfirst; y != ylast && !error_called; y += ystep ) {
151                 if ( zsize == 1 ) {
152                         getrow(image, rs, y, 0);
153                         for(x=0; x<xsize; x++ )
154                                 *cdatap++ = rs[x];
155                 } else {
156                         getrow(image, rs, y, 0);
157                         getrow(image, gs, y, 1);
158                         getrow(image, bs, y, 2);
159                         for(x=0; x<xsize; x++ )
160                                 *idatap++ = (rs[x] & 0xff)  |
161                                         ((gs[x] & 0xff)<<8) |
162                                         ((bs[x] & 0xff)<<16);
163                 }
164         }

----------
components: Extension Modules
messages: 65194
nosy: jnferguson
severity: normal
status: open
title: Multiple integer overflows in imgfile extension module lead to buffer overflow
type: security
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 19:01:14 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 17:01:14 +0000
Subject: [issue1184112] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <1207674074.61.0.534957369004.issue1184112@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

As of 2.5.1, a missing trailing newline no longer causes a Syntax Error,
making the second part of the caveat in the documentation unnecessary.

Changing to a documentation bug applicable to 2.5+.

----------
assignee:  -> georg.brandl
components: +Documentation -Interpreter Core
keywords: +easy
nosy: +georg.brandl
type:  -> behavior
versions: +Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Tue Apr  8 19:01:25 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 17:01:25 +0000
Subject: [issue2595] Multiple integer overflows in imgfile extension module
	lead to buffer overflow
In-Reply-To: <1207673799.86.0.811482353328.issue2595@psf.upfronthosting.co.za>
Message-ID: <1207674085.16.0.380627561282.issue2595@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

I'm not going to file a different bug for rgbimgmodule.c, it has the
same types of issues.

Sorry, I don't mean to drop a ton of bugs, I'm prepping up to do a talk
on attacking the metadata in scripting languages (i.e. the python call
stack instead of the processors) and I need to have these public/patched
before I talk about them. I've got a bunch more bugs, I'll file them
later when some of this stuff is caught up with.

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

From report at bugs.python.org  Tue Apr  8 19:06:30 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Tue, 08 Apr 2008 17:06:30 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsane
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207674390.04.0.542695260136.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

As an addemdum, consider the following code (theres no assert, but it
wouldnt have helped you outside of debug builds anyways):


488 static PyObject *PySSL_SSLread(PySSLObject *self, PyObject *args)
489 {
490         PyObject *buf;
491         int count = 0;
492         int len = 1024;
[...]
496         if (!PyArg_ParseTuple(args, "|i:read", &len))
497                 return NULL;
498 
499         if (!(buf = PyString_FromStringAndSize((char *) 0, len)))
500                 return NULL;
[...]
521                 count = SSL_read(self->ssl, PyString_AsString(buf),
len);

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

From report at bugs.python.org  Tue Apr  8 19:09:25 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 08 Apr 2008 17:09:25 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1207674565.2.0.994284055587.issue992389@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I think the lowered priority got lost somewhere along the line.

----------
priority: normal -> low

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

From report at bugs.python.org  Tue Apr  8 19:12:50 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 08 Apr 2008 17:12:50 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1207674770.37.0.517606642726.issue2576@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Daniel, Aren, please submit also what Daniel described, and I'll take a
look and push it forward.

Regards,

----------
nosy: +facundobatista

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

From report at bugs.python.org  Tue Apr  8 19:37:47 2008
From: report at bugs.python.org (Richard King)
Date: Tue, 08 Apr 2008 17:37:47 +0000
Subject: [issue2571] cmd.py always uses raw_input,
	even when another stdin is specified
In-Reply-To: <1207597739.54.0.851209464691.issue2571@psf.upfronthosting.co.za>
Message-ID: <47FBAD63.1000004@comcast.net>


Richard King <rickbking at comcast.net> added the comment:

(this is really 2 mails because my home email address was not registered so they were rejected at first)
Right - I wasn't too clear. The module stashes stdin, whether from sys 
or passed in, in self.stdin. When it reads input it uses a flag 
"raw_input" to determine whether to use raw_input or 
self.stdin.readline(), but the flag is not reset when a different stdin 
is passed in, so raw_input is always true.

The flag should be True/False, and I didn't think of setting it directly 
to be honest because it never occurred to me that I should have to do that to get a cmd class that i just instantiated with a different input object to use the one it was created with. I think the flag should be eliminated and replaced 
with the test self.stdin == sys.stdin anyway.

I also entered a feature request to add a stack of stdin's which are 
stacked when you want to process lines in a file, and then pop off the 
stack automatically at end of file. This would make it easy to write a 
command-line tool, like i'm doing, so that any input object could enter commands that change to other input objects and then restore the previous input object....this would allow for nesting of command files. There would be special conditions for 
sys.stdin (sys.stdin can only be used if there are no items on the 
stack). This could all be done outside the module, but it's so easy when 
it's integrated right in there.

----
I think I understand better what you are getting at, but it makes more 
sense to me to be explicit in the code and not take advantage of the 
fact the raw_input always works off sys.stdin. Also, I see now that 
maybe the idea was to have raw_input be changeable so that you could 
switch back and forth between "stdin" (whatever that is), and some other 
input object - I'm having a hard time seeing the usefulness of that, 
though. Anyway, instantiating a cmd class with a non-stdin input object 
and then having to set raw_input to False to get it to use that input 
object seems wrong.
----
does this make sense?
-Rick King

Daniel Diniz wrote:
> Daniel Diniz <ajaksu2 at users.sourceforge.net> added the comment:
>
> I don't think it should stop using raw_input just because you changed
> stdin, as you can change it to something that will work with raw_input.
> Consider:
>   
>>>> import sys
>>>> sys.stdin = open("/dev/tty")
>>>> raw_input()
>>>>         
> a
> 'a'
>
> You can tie it to any object (e.g. a GUI input) that supports the file
> protocol and keep using raw_input. Or change Cmd.use_rawinput to 0 to
> use stdin.readline directly.
>
> On a related issue. Cmd.use_rawinput should be "True", not 1...
>
> ----------
> nosy: +ajaksu2
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2571>
> __________________________________
>
>
>

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

From report at bugs.python.org  Tue Apr  8 20:24:40 2008
From: report at bugs.python.org (=?utf-8?q?Taavi_Rep=C3=A4n?=)
Date: Tue, 08 Apr 2008 18:24:40 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
In-Reply-To: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>
Message-ID: <1207679080.46.0.208437917349.issue2564@psf.upfronthosting.co.za>


Taavi Rep?n <trepan at gmail.com> added the comment:

I don't that the problem is in tests. For example
  import pygtk
  import gtk
hangs also. I don't have backtrace for PyGtk hang yet, but it hangs in
ucond state too (like test_capi).

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

From report at bugs.python.org  Tue Apr  8 20:11:53 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 18:11:53 +0000
Subject: [issue2584] numeric overflow in IDLE
In-Reply-To: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>
Message-ID: <1207678313.58.0.675120297566.issue2584@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

So let's it interpret this way:
range(1, 300000000) consumes more and more memory, and causes the system
to hang.
When python.exe is in a console, you have the ability to close the
window and kill the process.
When using Idle, the interpreter cannot be killed so easily: I suppose
you closed the main windows, but this did not kill the subprocess used
to run commands.

BTW1: did you try xrange(1, 30000000)

BTW2: msg65177 is not a pseudo... it's the message ID in the bug tracker ;-)

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

From report at bugs.python.org  Tue Apr  8 20:41:25 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Tue, 08 Apr 2008 18:41:25 +0000
Subject: [issue1285086] urllib.quote is too slow
Message-ID: <1207680085.71.0.987169754185.issue1285086@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

This is what I found doing some timings:

For the short-circuit path, the regexp can make quote 10x as fast in
exceptional cases, even comparing to the faster version in trunk. The
average win for short-circuit seems to be twice as fast as the map in my
timings. This sounds good.

For the normal path, the overhead can make quote 50% slower. This IMHO
makes it unfit for quote replacement. Perhaps good for a cookbook recipe? 

Regarding the OP's use case, I believe either adding a string cache to
quote or flagging stored strings as "safe" or "must quote" would result
in a much greater impact on performance.

Attaching patch against trunk. Web framework developers should be
interested in testing this and could provide the use cases/data needed
for settling this issue.

----------
keywords: +patch
nosy: +ajaksu2
Added file: http://bugs.python.org/file9986/urllib.quote.patch

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

From report at bugs.python.org  Tue Apr  8 21:12:49 2008
From: report at bugs.python.org (Collin Winter)
Date: Tue, 08 Apr 2008 19:12:49 +0000
Subject: [issue2596] 2to3's fix_range needs fix_dict's context information
In-Reply-To: <1207681968.61.0.683237075469.issue2596@psf.upfronthosting.co.za>
Message-ID: <1207681968.61.0.683237075469.issue2596@psf.upfronthosting.co.za>


New submission from Collin Winter <collinw at gmail.com>:

2to3 should be able to translate the code snippet below successfully.
First guess: generalizing fix_dict's notion of special contexts would do
the trick.

import random

numbers = range(1, 50)
chosen = []

while len(chosen) < 6:
    number = random.choice(numbers)
    numbers.remove(number)
    chosen.append(number)

chosen.sort()
print("This week's numbers are", chosen)
print("The bonus ball is", random.choice(numbers))

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
messages: 65204
nosy: collinwinter
priority: normal
severity: normal
status: open
title: 2to3's fix_range needs fix_dict's context information
type: behavior

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

From report at bugs.python.org  Tue Apr  8 21:14:26 2008
From: report at bugs.python.org (Tim Wilcoxson)
Date: Tue, 08 Apr 2008 19:14:26 +0000
Subject: [issue2584] numeric overflow in IDLE
In-Reply-To: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>
Message-ID: <1207682066.44.0.422530319085.issue2584@psf.upfronthosting.co.za>


Tim Wilcoxson <qodosh at gmail.com> added the comment:

not a nick aye? lol. I am new cant you tell.

And when i ran the script nothing could be closed. And, yes, I realize
it could be a memory exhaustion issue with windows. windows is notorious
for crappy resource handling. However, my concern came when I actually
got an error and a clean exit with cmd prompt but not with the GUI.
explorer.exe didn't crash. And I've had memory exhaustion under windows
before, and it still allowed me enough memory to (albeit slowly)
ctrl-alt-del. However the login process wouldnt even function. I did try
xrange, it hung as the other.

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

From report at bugs.python.org  Tue Apr  8 21:17:39 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 08 Apr 2008 19:17:39 +0000
Subject: [issue2410] absolute import doesn't work for standard python modules
In-Reply-To: <1205875676.38.0.76467063797.issue2410@psf.upfronthosting.co.za>
Message-ID: <1207682259.39.0.854377662073.issue2410@psf.upfronthosting.co.za>


Bruce Frederiksen <dangyogi at gmail.com> added the comment:

OK, I see where I mis-diagnosed the problem.  It seems that importing
smtplib (for example) shouldn't get confused with my email package.  As
I understand it, using relative imports within a package should avoid
the problem of the names of subordinate packages/modules colliding with
those in other packages.  Should the problem have been written up that
the standard modules (e.g., smtplib) should use relative imports to
avoid name collision problems like this?  (I'm not sure if relative
imports work for standard modules).

If this is the correct statement of the problem, I can resubmit it if
that's easier.

Thanks in advance!

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

From report at bugs.python.org  Tue Apr  8 21:24:16 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 08 Apr 2008 19:24:16 +0000
Subject: [issue2597] "python2.6 -3" should report list.sort(cmp) as
	DeprecationWarning
In-Reply-To: <1207682656.33.0.410001743847.issue2597@psf.upfronthosting.co.za>
Message-ID: <1207682656.33.0.410001743847.issue2597@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

this is not reported in 2.6a1.

----------
components: Interpreter Core
messages: 65207
nosy: dangyogi
severity: normal
status: open
title: "python2.6 -3" should report list.sort(cmp) as DeprecationWarning
type: feature request
versions: Python 2.6

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

From report at bugs.python.org  Tue Apr  8 21:36:06 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 08 Apr 2008 19:36:06 +0000
Subject: [issue2597] "python2.6 -3" should report list.sort(cmp) as
	DeprecationWarning
In-Reply-To: <1207682656.33.0.410001743847.issue2597@psf.upfronthosting.co.za>
Message-ID: <1207683366.71.0.0799100568785.issue2597@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Already done in 2.6a2

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

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

From report at bugs.python.org  Tue Apr  8 21:38:44 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 08 Apr 2008 19:38:44 +0000
Subject: [issue2598] "{ +(}".format(**{' +(': 44}) should produce ValueError:
	invalid identifier, ' +(' in format
In-Reply-To: <1207683524.11.0.610086195192.issue2598@psf.upfronthosting.co.za>
Message-ID: <1207683524.11.0.610086195192.issue2598@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

Format strings are documented to only allow identifiers or integers as
the field_name, but allow almost anything.

Python 3.0a3

----------
components: Interpreter Core
messages: 65209
nosy: dangyogi
severity: normal
status: open
title: "{ +(}".format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 21:51:05 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Tue, 08 Apr 2008 19:51:05 +0000
Subject: [issue2599] allow field_name in format strings to default to next
	positional argument (e.g., "{}")
In-Reply-To: <1207684265.4.0.956293084225.issue2599@psf.upfronthosting.co.za>
Message-ID: <1207684265.4.0.956293084225.issue2599@psf.upfronthosting.co.za>


New submission from Bruce Frederiksen <dangyogi at gmail.com>:

Being forced to number the arguments when using positional arguments in
a format string is difficult to maintain.  Adding an argument to the
format string either requires renumbering all subsequent arguments, or
using an out of sequence number such that the order of the format()
arguments no longer matches the order of the "{...}" arguments.  Making
the integer optional would solve this.  Thus, "{}" would be like the old
"%s" where it was far easier to add %s arguments in the middle of the
format string.

Python 3.0a3

----------
components: Interpreter Core
messages: 65210
nosy: dangyogi
severity: normal
status: open
title: allow field_name in format strings to default to next positional argument (e.g., "{}")
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Tue Apr  8 22:01:17 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Apr 2008 20:01:17 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207684877.77.0.12190025595.issue2541@psf.upfronthosting.co.za>


Changes by Marc-Andre Lemburg <mal at egenix.com>:


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

From report at bugs.python.org  Tue Apr  8 22:03:29 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Apr 2008 20:03:29 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207685008.93.0.089955394818.issue2541@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

You can't change the codec - it's being used in other places as well,
e.g. for use cases where you need to have an 8-bit encoded readable
version of a Unicode object (which happens to be Latin-1 + Unicode
escapes for all non-Latin-1 characters, due to Unicode being a superset
of Latin-1).

Adding a new codec would be fine, though I don't know how this would map
raw Unicode strings with non-Latin-1 characters in them to an 8-bit
string. Perhaps this is not needed at all in Py3k.

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

From report at bugs.python.org  Tue Apr  8 22:10:35 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 20:10:35 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207685435.78.0.0637914474339.issue2541@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Isn't "unicode-escape" enough for this purpose?

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

From report at bugs.python.org  Tue Apr  8 22:16:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 08 Apr 2008 20:16:07 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207661184.56.0.396312221678.issue2562@psf.upfronthosting.co.za>
Message-ID: <47FBD282.1050803@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> But write_pkg_file will use ascii encoding if we don't indicate it
> here:
> 
>>>> pkg_info.write('Author: %s\n' % self.get_contact() )

Why do you say that it uses ascii? It uses whatever encoding the string
returned by get_contact uses. See the attached P1-1.0.tar.gz for an
example. This doesn't use ASCII, and doesn't use UTF-8, and works with
2.4.

> So wouldn't a light fix in write_pkg_file() would be sufficient when a
> unicode(field) fails, as MAL mentioned ? by trying utf8:
> 
>>>> try:
> ...    pkg_info.write('Author: %s\n' % self.get_contact() )
> ... except UnicodeEncodeError:
> ...    pkg_info.write('Author: %s\n' % self.get_contact().encode('utf8') ) 

That would work - although I fail to see what this has to do with
a failing unicode(field). Instead, it has rather to do with a failing
.write().

Added file: http://bugs.python.org/file9987/P1-1.0.tar.gz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
__________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: P1-1.0.tar.gz
Type: application/x-gzip
Size: 462 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-bugs-list/attachments/20080408/5d86cd6d/attachment.bin 

From report at bugs.python.org  Tue Apr  8 22:35:13 2008
From: report at bugs.python.org (djc)
Date: Tue, 08 Apr 2008 20:35:13 +0000
Subject: [issue2585] urllib2.HTTPError broken due to urllib.addinfourl changes
In-Reply-To: <1207667965.33.0.297258961494.issue2585@psf.upfronthosting.co.za>
Message-ID: <1207686913.05.0.496788523004.issue2585@psf.upfronthosting.co.za>


Changes by djc <dirkjan at ochtman.nl>:


----------
nosy: +georg.brandl -birkenfeld

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

From report at bugs.python.org  Tue Apr  8 22:39:51 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 08 Apr 2008 20:39:51 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1207687191.45.0.790454985231.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

>>>> pkg_info.write('Author: %s\n' % self.get_contact() )
> Why do you say that it uses ascii? It uses whatever encoding the string
> returned by get_contact uses. See the attached P1-1.0.tar.gz for an
> example. This doesn't use ASCII, and doesn't use UTF-8, and works with
> 2.4.


This happens of course only when get_contact returns an unicode.
It uses the ascii codec by default. Here's an example:

>>> contact = u'Barnab?'
>>> f = open('/tmp/test', 'w')
>>> f.write('Author: %s' % contact)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe9' in
position 14: ordinal not in range(128)

> That would work - although I fail to see what this has to do with
> a failing unicode(field). Instead, it has rather to do with a failing
> .write().

Absolutely, I was focusing on write_pkg_file() method that fails
when the egg-info file is written.

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

From report at bugs.python.org  Tue Apr  8 23:04:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 21:04:57 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
In-Reply-To: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>
Message-ID: <1207688695.91.0.621429159096.issue2564@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

In any case, I reproduce the problem on Windows too.

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

From report at bugs.python.org  Tue Apr  8 23:05:00 2008
From: report at bugs.python.org (Pau Aliagas)
Date: Tue, 08 Apr 2008 21:05:00 +0000
Subject: [issue2600] BindingHTTPConnectionWithTimeout and
	BindingHTTPHandlerWithTimeout
In-Reply-To: <1207688700.18.0.242817334294.issue2600@psf.upfronthosting.co.za>
Message-ID: <1207688700.18.0.242817334294.issue2600@psf.upfronthosting.co.za>


New submission from Pau Aliagas <linuxnow at newtral.org>:

I wanted to use urllib2 with something as usual as binding to a given
network interface and it was incredibly complex. I also did not like the
usual propodes solution to timeout the connections: set the global
socket timeour. I needed a different timeout for each connection.

So I took my time, I learnt about httplib and urllib2 and made a patch
to enhance both libraries.

BindingHTTPConnectionWithTimeout extends HTTPConection with supports
timeouts and a binding address.

BindingHTTPHandlerWithTimeout extends HTTPHandler and basically uses the
new http class provided.

The patch is really simple and would make a great addition to the
standard library. I've tried to follow the style amd copied similar
methods, giving the due credits.

I hope you find it useful and consider it for inclusion.

----------
components: Library (Lib)
files: urllib2_util.py
messages: 65215
nosy: pau
severity: normal
status: open
title: BindingHTTPConnectionWithTimeout and BindingHTTPHandlerWithTimeout
type: feature request
versions: Python 2.4, Python 2.5
Added file: http://bugs.python.org/file9988/urllib2_util.py

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

From report at bugs.python.org  Tue Apr  8 23:11:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 08 Apr 2008 21:11:22 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207689082.97.0.914937288752.issue2587@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
title: PyString_FromStringAndSize() to be considered unsane -> PyString_FromStringAndSize() to be considered unsafe

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

From report at bugs.python.org  Tue Apr  8 23:12:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 08 Apr 2008 21:12:36 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207689156.91.0.827393721388.issue2530@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching an updated patch from a review Mark Summerfield.

Added file: http://bugs.python.org/file9989/io_doc3.patch

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

From report at bugs.python.org  Tue Apr  8 23:13:37 2008
From: report at bugs.python.org (Mark Hammond)
Date: Tue, 08 Apr 2008 21:13:37 +0000
Subject: [issue2563] embed manifest in windows extensions
In-Reply-To: <1207489949.8.0.458848189984.issue2563@psf.upfronthosting.co.za>
Message-ID: <1207689217.61.0.464810863149.issue2563@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

Note that we are actually using the linker to *generate* the manifest
(something linkers pre VC2005 couldn't do), so if we could tell the
linker to skip that manifest generation and embed it directly in the
DLL, it would certainly be easier.  But, IIRC (which I may not), you can
embed a manifest directly via the linker by converting the manifest to a
resource and linking that - however, that conversion still requires an
extra tool.  This is the alternative process outlined on the MS page I
linked to.  And finally, it seems Visual Studio itself embeds the
resource this way.

So if there is a way to embed the manifest without an additional step, I
don't know about it :)

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

From report at bugs.python.org  Tue Apr  8 23:15:30 2008
From: report at bugs.python.org (Matthias Klose)
Date: Tue, 08 Apr 2008 21:15:30 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

r61009 on the 2.5 branch

  - Bug #1389051, 1092502: fix excessively large memory allocations when
    calling .read() on a socket object wrapped with makefile(). 

causes a regression compared to 2.4.5 and 2.5.2:

When reading from urllib2 file descriptor, python will read the data a
byte at a time regardless of how much you ask for. python versions up to
2.5.2 will read the data in 8K chunks.

This has enough of a performance impact that it increases download time
for a large file over a gigabit LAN from 10 seconds to 34 minutes. (!)

Trivial/obvious example code:

  f =
urllib2.urlopen("http://launchpadlibrarian.net/13214672/nexuiz-data_2.4.orig.tar.gz")
  while 1:
    chunk = f.read()

... and then strace it to see the recv()'s chugging along, one byte at a
time.

----------
assignee: akuchling
components: Library (Lib)
messages: 65219
nosy: akuchling, doko
priority: high
severity: normal
status: open
title: [regression] reading from a urllib2 file descriptor happens byte-at-a-time
type: performance
versions: Python 2.5

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

From report at bugs.python.org  Tue Apr  8 23:28:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 21:28:49 +0000
Subject: [issue2564] Python hangs on FreeBSD7 in test_capi
In-Reply-To: <1207498116.36.0.372445518843.issue2564@psf.upfronthosting.co.za>
Message-ID: <1207690129.72.0.666840290386.issue2564@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r62229. Please file a separate issue for the gtk module, it's
really another thing.

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

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

From report at bugs.python.org  Wed Apr  9 00:09:43 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 22:09:43 +0000
Subject: [issue2408] types module can be implemented only in Python
In-Reply-To: <1205874570.2.0.410256172712.issue2408@psf.upfronthosting.co.za>
Message-ID: <1207692583.41.0.692833079478.issue2408@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r62231: remove _types module.

I did not add CellType though, because of discussion in #1605.

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

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

From report at bugs.python.org  Wed Apr  9 00:15:08 2008
From: report at bugs.python.org (Collin Winter)
Date: Tue, 08 Apr 2008 22:15:08 +0000
Subject: [issue2596] 2to3's fix_xrange needs fix_dict's context information
In-Reply-To: <1207681968.61.0.683237075469.issue2596@psf.upfronthosting.co.za>
Message-ID: <1207692908.28.0.444008823658.issue2596@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Fixed in r62232. Verified that the sample code below runs successfully
under Python 3.0a4+ (r62209) after being run through 2to3.

----------
resolution:  -> fixed
status: open -> closed
title: 2to3's fix_range needs fix_dict's context information -> 2to3's fix_xrange needs fix_dict's context information

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

From report at bugs.python.org  Wed Apr  9 01:16:45 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 08 Apr 2008 23:16:45 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207696605.57.0.885567309577.issue2541@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

What do you mean with "enough" ?

The "raw-unicode-escape" codec is used in Python 2.x to convert literal
strings of the form ur"" to Unicode objects. It's a variant of the
"unicode-escape" codec.

The codec is also being used in cPickle, pickle, variants of pickle, 
Python code generators, etc.

It serves its purpose, just like "unicode-escape" and all the other
codecs in Python.

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

From report at bugs.python.org  Wed Apr  9 01:48:18 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 08 Apr 2008 23:48:18 +0000
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
	as on Unix
In-Reply-To: <1207324680.68.0.575928167509.issue2550@psf.upfronthosting.co.za>
Message-ID: <1207698498.59.0.988380772773.issue2550@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Committed updates to relevant network-oriented tests, as well as 
test_support changes discussed, in r62234.

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

From report at bugs.python.org  Wed Apr  9 01:55:39 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 08 Apr 2008 23:55:39 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207698939.28.0.266221704026.issue2541@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I mean: now that raw strings cannot represent all unicode points (or
more precisely, they need the file encoding to do so), is there a use
case for "raw-unicode-escape" that cannot be filled by the
unicode-escape codec?

Note that pickle does not use "raw-unicode-escape" as is: it replaces
backslashes by \u005c. This has the nice effect that pickled strings can
also be decoded by "unicode-escape".

That's why I propose to completely remove raw-unicode-escape, and use
unicode-escape instead.

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

From report at bugs.python.org  Wed Apr  9 03:11:57 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 01:11:57 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207703517.41.0.346526856624.issue2588@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As long as snprintf is used with a fixed size buffer using an idiom

 snprintf(buffer, sizeof(buffer), ..)

there is no issue because sizeof(buffer) cannot be zero.  AFAICT, this 
is how python uses PyOS_vsnprintf wrapper.

On the other hand, may this is a good opportunity to revisit the 
decision to make  PyOS_vsnprintf semantics different from C99 vsnprintf.

C99 defines snprintf semantics as follows:

int snprintf(char *restrict s, size_t n,
       const char *restrict format, ...);

The snprintf() function shall be equivalent to sprintf(), with the 
addition of the n argument which states the size of the buffer referred 
to by s. If n is zero, nothing shall be written and s may be a null 
pointer. Otherwise, output bytes beyond the n-1st shall be discarded 
instead of being written to the array, and a null byte is written at the 
end of the bytes actually written into the array.

<http://www.opengroup.org/onlinepubs/000095399/functions/printf.html>

----------
nosy: +belopolsky

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

From report at bugs.python.org  Wed Apr  9 03:21:18 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Wed, 09 Apr 2008 01:21:18 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207704078.65.0.53495309332.issue2588@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

I do agree with your point about snprintf(..., sizeof(x), ...)-- my
single biggest point (and maybe i'm just not seeing it), is that there
appears to be no good reason for having this caveat and in turn its
essentially just code waiting to break; with as commonly used of a
function as it is, it's really a matter of when and not so much if.

While no one seems to ever use it this way, don't forget that a good
alternative to asprintf() is calling sprintf() with a length of zero to
get the length (in compliant implementations), allocating the memory and
then calling it again.

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

From report at bugs.python.org  Wed Apr  9 03:37:22 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 01:37:22 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207704078.65.0.53495309332.issue2588@psf.upfronthosting.co.za>
Message-ID: <d38f5330804081837k3c040b30i630c75971a7effb2@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Apr 8, 2008 at 9:21 PM, Justin Ferguson <report at bugs.python.org> wrote:

> ..
>  While no one seems to ever use it this way, don't forget that a good
>  alternative to asprintf() is calling sprintf() with a length of zero to
>  get the length (in compliant implementations), allocating the memory and
>  then calling it again.

Remember that PyOS_vsnprintf was introduced back in 2001 when
(according to the comments in the file) not all platforms provided c99
compliant implementations.  If you can verify that the situation has
changes for the supported platforms, I think you will have a good case
for making the wrapper c99 compliant.

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

From report at bugs.python.org  Wed Apr  9 03:57:10 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 01:57:10 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207706230.85.0.551658335041.issue2586@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This has just been fixed in the trunk: r62235.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Wed Apr  9 04:20:18 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 09 Apr 2008 02:20:18 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207707618.68.0.59210705273.issue2586@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thx

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

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

From report at bugs.python.org  Wed Apr  9 05:19:14 2008
From: report at bugs.python.org (Collin Winter)
Date: Wed, 09 Apr 2008 03:19:14 +0000
Subject: [issue2454] sha and md5 fixer
In-Reply-To: <1206147643.89.0.60936055638.issue2454@psf.upfronthosting.co.za>
Message-ID: <1207711154.08.0.0192320340264.issue2454@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
priority:  -> normal

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

From report at bugs.python.org  Wed Apr  9 05:21:17 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 09 Apr 2008 03:21:17 +0000
Subject: [issue2410] absolute import doesn't work for standard python modules
In-Reply-To: <1205875676.38.0.76467063797.issue2410@psf.upfronthosting.co.za>
Message-ID: <1207711277.47.0.751603615969.issue2410@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Using relative imports within smtplib wouldn't have made any difference
in this case. Your dummy email package was the first one encountered on
sys.path, so the "import email.smtplib" line (which does an "import
email" internally as the first step in resolving the import, and then
tries to find "smtplib" in email.__path__) picked it up.

Putting an internal package directory on sys.path (as your example does)
is seriously bad ju-ju. It's one of the main reason why people are so
strongly discouraged from directly executing files that are stored in
package directories (along with another nasty side effect in getting two
different copies of the same module using different names, it also has
the same effect as what you did here - subpackages/modules can end up
overriding standard library modules and packages because the script
directory gets placed on sys.path).

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

From report at bugs.python.org  Wed Apr  9 05:48:48 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 09 Apr 2008 03:48:48 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1207712928.64.0.8059727129.issue2576@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

"The code patch is trivial", he said, only to find out it was not :)

Facundo, thanks in advance for taking a look at this!

This patch tries to implement, document and test an optional argument to
HTTPConnection, which passes it to HTTPResponse. So far, it's called
"sockbuf", but I truly hope we can find a better name.

The crux of the test is that it shouldn't be possible to use a buffered
socket and a persistent connection simultaneously, as that was the
reason a buffer was left out (see issue 508157). It also tries to check
correctly allowing Keep-Alive when sockbuf==0. However, it fails to
exercise HTTPResponse properly and needs a review down the
auto-reconnect path. Persistent connections should be tested.

Regarding the code, there's a chance that some changes touching forced
closing are bogus (but not harmful). I'll get back to it and to
persistent connection tests.

Thanks again :)

Added file: http://bugs.python.org/file9990/buffered_socket.diff

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

From report at bugs.python.org  Wed Apr  9 10:34:53 2008
From: report at bugs.python.org (=?utf-8?q?Taavi_Rep=C3=A4n?=)
Date: Wed, 09 Apr 2008 08:34:53 +0000
Subject: [issue2602] importing gtk hangs (freebsd 7.0)
In-Reply-To: <1207730093.3.0.550456039036.issue2602@psf.upfronthosting.co.za>
Message-ID: <1207730093.3.0.550456039036.issue2602@psf.upfronthosting.co.za>


New submission from Taavi Rep?n <trepan at gmail.com>:

Python 2.5.3a0 (release25-maint:62241, Apr  9 2008, 11:26:27) 
[GCC 4.2.1 20070719  [FreeBSD]] on freebsd7
Type "help", "copyright", "credits" or "license" for more information.
>>> import pygtk
>>> import gtk
[hangs here]

----------
files: backtrace
messages: 65233
nosy: trepan
severity: normal
status: open
title: importing gtk hangs (freebsd 7.0)
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file9991/backtrace

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

From report at bugs.python.org  Wed Apr  9 12:03:25 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 09 Apr 2008 10:03:25 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1207735405.83.0.415384587848.issue2541@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

While that's true for cPickle, it is not for pickle. The pickle protocol
itself is defined in terms of the "raw-unicode-escape" codec (see
pickle.py).

Besides, you cannot assume that the Python interpreter itself is the
only use-case for these codecs. The "raw-unicode-escape" codec is well
usable for other purposes where you need a compact way of encoding
Unicode, especially if you're strings are mostly Latin-1 and only
include non-UCS2 code points every now and then. That's also the reason
why pickle uses it.

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

From report at bugs.python.org  Wed Apr  9 13:18:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Apr 2008 11:18:12 +0000
Subject: [issue2602] importing gtk hangs (freebsd 7.0)
In-Reply-To: <1207730093.3.0.550456039036.issue2602@psf.upfronthosting.co.za>
Message-ID: <1207739892.75.0.83849513176.issue2602@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

You should report this to the FreeBSD team, because I think importing
gtk works on most platforms. Also, gtk is not part of the Python
standard library, and since it's a very large package I doubt people
here are wanting to debug it.

Of course, if it is indeed a bug in the Python interpreter (rather than
in the FreeBSD package or the gtk package), it is fine to report it
here. :-)

----------
nosy: +pitrou

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

From report at bugs.python.org  Wed Apr  9 13:21:26 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Apr 2008 11:21:26 +0000
Subject: [issue2523] binary buffered reading is quadratic
In-Reply-To: <1206987085.65.0.944826780657.issue2523@psf.upfronthosting.co.za>
Message-ID: <1207740086.14.0.0102918447595.issue2523@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

By the way, a simple way to fix it would be to use a native BytesIO
object (as provided by Alexandre's patch in #1751) rather than a str
object for the underlying buffer.

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

From report at bugs.python.org  Wed Apr  9 13:23:02 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 09 Apr 2008 11:23:02 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1207740182.09.0.356734645562.issue1751@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
type:  -> performance

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

From report at bugs.python.org  Wed Apr  9 17:04:23 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 15:04:23 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207753463.37.0.775913322207.issue2587@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I agree that PySSL_SSLread should check that its argument is >= 0.  I 
don't think this check belongs to PyString_FromStringAndSize.   It 
should be the responsibility of the caller to verify that the 
precondition size >= 0 is satisfied before calling PyString_FromStringAndSize.  Oftentimes the caller can ascertain size >= 
0 without an explicit check, for example, if size is the size of a 
buffer or length of a valid string object.

On the other hand, an external input such as the len argument to the 
read function should be checked before used.

I would also suggest changing the len type from int to Py_ssize_t.

I agree with Amaury that assert(size>=0) is sufficient in PyString_FromStringAndSize(), but its documentation should emphasize 
that the caller is responsible for assuring that the requested length is  
nonnegative.

I don't think the upper bound check is necessary: sizeof(PyStringObject) 
+ size will not wrap around as long as size >= 0.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Wed Apr  9 17:09:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Apr 2008 15:09:26 +0000
Subject: [issue2602] importing gtk hangs (freebsd 7.0)
In-Reply-To: <1207730093.3.0.550456039036.issue2602@psf.upfronthosting.co.za>
Message-ID: <1207753765.97.0.638436520025.issue2602@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I'm going to close this, since it is probably a gtk or FreeBSD problem.
Please report if this it not so.

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Wed Apr  9 17:09:50 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 09 Apr 2008 15:09:50 +0000
Subject: [issue2585] urllib2.HTTPError broken due to urllib.addinfourl changes
In-Reply-To: <1207667965.33.0.297258961494.issue2585@psf.upfronthosting.co.za>
Message-ID: <1207753790.13.0.439273779318.issue2585@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

It seems the fix is just passing code to addinfourl __init__, not sure
if someone forgot this or this is just totally wrong.

Patch added.

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file9992/urllib2_2585.diff

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

From report at bugs.python.org  Wed Apr  9 18:42:22 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Apr 2008 16:42:22 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207641694.82.0.47854556938.issue2578@psf.upfronthosting.co.za>
Message-ID: <ca471dc20804090942x2a2cbbebn87d235eca9f782c0@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

>  Steve Purcell <purcell at users.sourceforge.net> added the comment:
>  Hey, I'm open to anything.  If I started writing unittest from scratch
>  knowing what I know now, I'd probably have kept the API a little
>  slimmer.  Oh, and I'd have named everthing according to Python
>  conventions; my deepest and belated apologies for that.

I think the current consensus is to start trimming the API in 3.1. We
could start documenting best practices in 2.6 and 3.0 though.

>  I think the design has held up pretty well, even if it's arguably not
>  the most pythonic.  Its familiarity to users of other xUnit frameworks
>  really does help new Pythoneers start writing tests immediately.

Though I wonder how common that use case is. Not all new Pythoneers
come from Java, you know... Many come from Perl, PHP, even C++, and
more and more come from not programming at all before.

>  And as
>  for the TestLoader stuff, it looks (and perhaps is) a bit overblown, but
>  I can't count the number of times people have asked me how to do obscure
>  or unusual things with the module and I've been able to respond with
>  something like, "just write a custom TestLoader/TestRunner".

I hope we can add more custom TestLoader/TestRunner subclasses for
some of the *common* use cases.

>  I don't intend to take unittest in any particular direction; truth be
>  told, I'm now only an occasional visitor to the land of Python, and I
>  don't think I've had commit rights since the move to subversion.  My
>  continued involvement with the unittest tickets is mainly to help
>  provide input along the lines of "we discussed this years ago, and
>  decided against it / thought it would be great".  Far be it from me to
>  stand in the way of progress -- I'd be happy to see unittest re-worked
>  in any way that makes sense.

And thanks for your continued involvement! I think the clue the
developer community can take from this is not to worry too much about
changing the original design; you don't seem to have a strong sense of
"ownership", which (in this case) sounds good to me.

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

From report at bugs.python.org  Wed Apr  9 19:14:05 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Wed, 09 Apr 2008 17:14:05 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207761245.21.0.824040411532.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

While I think its a mistake that will cause security concerns in Python
for quite some time to come, thats fair enough.

I will refile all the places that this messes up individually

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

From report at bugs.python.org  Wed Apr  9 19:16:31 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Wed, 09 Apr 2008 17:16:31 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207761391.61.0.745995657786.issue2588@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Actually, I'm not sure things are any better today- even the same
operating system but different versions have inconsistencies, for
instance on some versions of RHEL the vsnprintf() can fail during
unicode conversion. MSVCRT still returns -1 on truncation, et cetera.

That said, theres plenty of other implementations that manage this
without the potential of underflowing a buffer

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

From report at bugs.python.org  Wed Apr  9 19:20:50 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Wed, 09 Apr 2008 17:20:50 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207761650.84.0.750061039779.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Do I need to create proof of concepts for each of these bugs, or can I
reference this ticket?

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

From report at bugs.python.org  Wed Apr  9 19:29:49 2008
From: report at bugs.python.org (Steve Purcell)
Date: Wed, 09 Apr 2008 17:29:49 +0000
Subject: [issue2578] Figure out what to do with unittest's redundant APIs
In-Reply-To: <1207616486.67.0.93583341584.issue2578@psf.upfronthosting.co.za>
Message-ID: <1207762189.69.0.306725605052.issue2578@psf.upfronthosting.co.za>


Steve Purcell <purcell at users.sourceforge.net> added the comment:

Hey, I came to Python from Perl, Java *and* C++!  I'm pretty sure the 
xUnits in all those other languages hold to the same basic API.

Adding more TestLoaders/TestRunners sounds like an excellent move.  I'd 
expect that once those common conveniences have been provided for, the 
core TestSuite/TestCase scheme will continue to be helpful.

I could certainly envisage the provision of convenience decorators that 
would remove some of the typical subclassing boilerplate  by 
transforming plain functions into TestCases.

I was recently sent a fun paper describing a mechanism for transforming 
doctests into 'unittest' tests, so there's obviously a lot of scope for 
fun additions and changes.

I'll be interested to see what people come up with, and to help a little 
if and when I can.

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

From report at bugs.python.org  Wed Apr  9 19:50:34 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 17:50:34 +0000
Subject: [issue2579] Misleading 'toctree references unknown document' error
In-Reply-To: <1207620696.06.0.199132876602.issue2579@psf.upfronthosting.co.za>
Message-ID: <1207763434.61.0.692168093999.issue2579@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r62245.

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

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

From report at bugs.python.org  Wed Apr  9 19:54:17 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 17:54:17 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207761391.61.0.745995657786.issue2588@psf.upfronthosting.co.za>
Message-ID: <d38f5330804091054w5a837572i7233073afbcc1732@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 9, 2008 at 1:16 PM, Justin Ferguson <report at bugs.python.org> wrote:
..
>  That said, theres plenty of other implementations that manage this
>  without the potential of underflowing a buffer
>

Do you have in mind something like the following?

===================================================================
--- Python/mysnprintf.c (revision 62211)
+++ Python/mysnprintf.c (working copy)
@@ -88,6 +88,7 @@
        PyMem_FREE(buffer);
 Done:
 #endif
-       str[size-1] = '\0';
+       if (size > 0)
+               str[size-1] = '\0';
        return len;
 }

I would be +0 on such change.

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

From report at bugs.python.org  Wed Apr  9 19:55:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 17:55:05 +0000
Subject: [issue1184112] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <1207763705.35.0.810087321861.issue1184112@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The exec example still presents me a syntax error in 2.5.2.

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

From report at bugs.python.org  Wed Apr  9 19:58:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 17:58:08 +0000
Subject: [issue2585] urllib2.HTTPError broken due to urllib.addinfourl changes
In-Reply-To: <1207667965.33.0.297258961494.issue2585@psf.upfronthosting.co.za>
Message-ID: <1207763888.31.0.976876629021.issue2585@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks Guilherme, that is indeed a detail that I forgot. Fixed in r62246.

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

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

From report at bugs.python.org  Wed Apr  9 20:07:49 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 09 Apr 2008 18:07:49 +0000
Subject: [issue1745] Backport of PEP 3102 "keyword-only arguments" to 2.6
In-Reply-To: <1199635442.3.0.37215467231.issue1745@psf.upfronthosting.co.za>
Message-ID: <1207764465.58.0.0169287707671.issue1745@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

The patch doesn't apply cleanly for me.  I can fix the non-clean patch,
but another error is that obj2ast_arguments doesn't call arguments()
with the correct parameters.  If I pass in NULL's for the new params,
all tests pass, but that just tells me it's not being tested thoroughly.

I'll spend some time looking at it, but if anyone else wants to look at
it, go ahead.

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

From report at bugs.python.org  Wed Apr  9 20:31:07 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 18:31:07 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207761650.84.0.750061039779.issue2587@psf.upfronthosting.co.za>
Message-ID: <d38f5330804091124o1ef4bedfu4ed0f281bb49e158@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 9, 2008 at 1:20 PM, Justin Ferguson <report at bugs.python.org> wrote:
..
>  Do I need to create proof of concepts for each of these bugs, or can I
>  reference this ticket?
>

It would be best if you could provide a patch complete with additional
unit tests that fail in (or crash) unpatched python and demonstrate
the bugs.  Since the fixes are likely to be one-line changes, I would
say there is no need to create separate issues.  Just post a patch
here for ? review.

>From your other post, I understand that you are doing a security audit
of the python codebase.  Is this a manual effort (identifying unsafe
constructs and searching for them) or you use some kind of automation?

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

From report at bugs.python.org  Wed Apr  9 20:41:43 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 18:41:43 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207766503.64.0.913485700916.issue2530@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Reviewed, changed a few things and committed as r62252. Thanks!

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

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

From report at bugs.python.org  Wed Apr  9 20:45:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 18:45:24 +0000
Subject: [issue2580] Revise builtin class int library manual entry
In-Reply-To: <1207621575.04.0.143306946794.issue2580@psf.upfronthosting.co.za>
Message-ID: <1207766724.86.0.790197955725.issue2580@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed as r62253. Thanks!

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

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

From report at bugs.python.org  Wed Apr  9 20:46:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 18:46:57 +0000
Subject: [issue2575] Reference manual: production for integer literals is
	missing "bininteger"
In-Reply-To: <1207601639.49.0.884754538811.issue2575@psf.upfronthosting.co.za>
Message-ID: <1207766817.73.0.893213023808.issue2575@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, fixed in r62254.

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

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

From report at bugs.python.org  Wed Apr  9 20:47:53 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Wed, 09 Apr 2008 18:47:53 +0000
Subject: [issue2588] PyOS_vsnprintf() underflow leads to memory corruption
In-Reply-To: <1207670110.11.0.605807538943.issue2588@psf.upfronthosting.co.za>
Message-ID: <1207766873.07.0.606264662496.issue2588@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Yep, that works for me.

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

From report at bugs.python.org  Wed Apr  9 20:49:03 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Apr 2008 18:49:03 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207766943.15.0.908291183378.issue2587@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

agreed, the assert in PyString_FromStringAndSize() should be changed to
a non-debug test.

----------
nosy: +gregory.p.smith

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

From report at bugs.python.org  Wed Apr  9 20:49:17 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Apr 2008 18:49:17 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207766957.45.0.61280694051.issue2587@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Wed Apr  9 20:49:23 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 18:49:23 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207766963.02.0.509898996617.issue2568@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Isn't the bug here rather that strptime doesn't allow leap seconds?

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

From report at bugs.python.org  Wed Apr  9 20:57:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 09 Apr 2008 18:57:02 +0000
Subject: [issue2513] 64bit cross compilation on windows
In-Reply-To: <1207179556.62.0.434827925195.issue2513@psf.upfronthosting.co.za>
Message-ID: <47FD117B.9070005@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin - my patch creates a new executable in Lib\distutils\command, and
> IMO it should be included in binary builds for all windows platforms. 
> Is there something I should change in the MSI process?

Yes, I fixed that in r62255: it now packages wininst*.exe from that
directory.

Regards,
Martin

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

From report at bugs.python.org  Wed Apr  9 21:02:18 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Wed, 09 Apr 2008 19:02:18 +0000
Subject: [issue2221] Py30a3: eval in threaded code raises SystemError
In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
Message-ID: <1207767738.27.0.497078886937.issue2221@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

PyObject_CallMethod is actually returning a
non-NULL result for sys.std{out,err}, and 
PyErr_Clear() isn't being run in flush_io.

The problem is deeper.  PyErr is being
used during unexceptional processing in
typeobject.c:slot_tp_getattr_hook() to
indicate that PyObject_GenericGetAttr() failed
and the __getattr__ method (used in IDLE) 
should be called.

Perhaps PyErr should be preserved in
slot_tp_getattr_hook(), instead.  Is this 
possibly a potential 2.6 issue for some uses
of getattr?  Or is the current solution 'good 
enough'?

ref issue1400.

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

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

From report at bugs.python.org  Wed Apr  9 21:07:57 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Wed, 09 Apr 2008 19:07:57 +0000
Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition
In-Reply-To: <1207506919.71.0.561124070539.issue1297@psf.upfronthosting.co.za>
Message-ID: <47FD1409.5050406@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Amaury: The file python.hpp, thus basetsd.h, is used by boost-python.

I don't think that was the question. Instead, the question was: why
is basetsd.h needed in the first place, when compiling Python?

Apparently, basetsd was added in r15912. Fred, can you remember what
the rationale was?

----------
nosy: +fdrake

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

From report at bugs.python.org  Wed Apr  9 21:08:15 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Wed, 09 Apr 2008 19:08:15 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207768095.05.0.0865298544128.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Okay, so I'm not sure whose point of view takes precedence here?

Also, to answer the question asked, I'm doing this manually.

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

From report at bugs.python.org  Wed Apr  9 21:21:30 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 19:21:30 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1207768890.09.0.423285623409.issue2601@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
priority: high -> critical

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

From report at bugs.python.org  Wed Apr  9 21:40:03 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 19:40:03 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207768095.05.0.0865298544128.issue2587@psf.upfronthosting.co.za>
Message-ID: <d38f5330804091239j2b6d3ba6r2156f7d5ce5fb882@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 9, 2008 at 3:08 PM, Justin Ferguson <report at bugs.python.org> wrote:

>  Okay, so I'm not sure whose point of view takes precedence here?

I don't have a strong view on this, but just a few points to consider:

1. If you change PyString_FromStringAndSize, you should change
PyBytes_FromStringAndSize and PyUnicode_FromStringAndSize for
consistency.

2. Non-debug check should probably set a ValueError exception and
return NULL.  Think what kind of message you can generate inside
*_FromStringAndSize that would be helpful to the end user.  The caller
is likely to be able to provide a much better diagnostic.

3. Maybe instead of setting a ValueError, a SystemError should be
raised.  In this case the calle will still be clearly responsible for
the pre-condition, but programming errors will not present security
concerns.

4. You have clearly identified several bugs that are not covered by
unittests.  If you fix them en-mass by making
PyString_FromStringAndSize more forgiving, we will miss an opportunity
to improve the test coverage. (If you take the SystemError approach,
this does not apply.)

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

From report at bugs.python.org  Wed Apr  9 21:54:34 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 19:54:34 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207766963.02.0.509898996617.issue2568@psf.upfronthosting.co.za>
Message-ID: <d38f5330804091254v239f09cbld2d32e07b5c08007@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 9, 2008 at 2:49 PM, Georg Brandl <report at bugs.python.org> wrote:

>  Isn't the bug here rather that strptime doesn't allow leap seconds?

This is not specific to strptime.  The datetime module does not allow
leap seconds:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: second must be in 0..59

This is intentional and documented. Or maybe I don't understand your question.

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

From report at bugs.python.org  Wed Apr  9 22:01:34 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Wed, 09 Apr 2008 20:01:34 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207771294.21.0.107543156601.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

> 1. If you change PyString_FromStringAndSize, you should change
> PyBytes_FromStringAndSize and PyUnicode_FromStringAndSize for
> consistency.

Okay, if we don't patch the API call itself, I will look at the users of
those two API calls as well, I haven't gone through much of the stuff in
Objects/ yet, I focused on the modules obviously and thus didn't know
about those calls.

> 4. You have clearly identified several bugs that are not covered by
> unittests.  If you fix them en-mass by making
> PyString_FromStringAndSize more forgiving, we will miss an opportunity
> to improve the test coverage. (If you take the SystemError approach,
> this does not apply.)

This is a valid and good point-- I don't mind either way

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

From report at bugs.python.org  Wed Apr  9 23:15:18 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 21:15:18 +0000
Subject: [issue2599] allow field_name in format strings to default to next
	positional argument (e.g., "{}")
In-Reply-To: <1207684265.4.0.956293084225.issue2599@psf.upfronthosting.co.za>
Message-ID: <1207775718.14.0.987142277956.issue2599@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Omitting the ordinals from {} format units will present a problem with
internationalization because the arguments may need to be rendered in
different order in different languages.  This is a frequent problem with
the % formats and it is a good thing that the new format requires
explicit enumeration.  If your argument list grows to the big enough
size that renumbering presents a problem, you should consider using
named rather than positional arguments.

This type of changes should be discussed on python-ideas list first.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Wed Apr  9 23:23:36 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 21:23:36 +0000
Subject: [issue2598] "{ +(}".format(**{' +(': 44}) should produce ValueError:
	invalid identifier, ' +(' in format
In-Reply-To: <1207683524.11.0.610086195192.issue2598@psf.upfronthosting.co.za>
Message-ID: <1207776216.36.0.678049940805.issue2598@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This is a feature explained in PEP 3101:

"""
    Implementation note: The implementation of this proposal is
    not required to enforce the rule about a simple or dotted name
    being a valid Python identifier.  Instead, it will rely on the
    getattr function of the underlying object to throw an exception if
    the identifier is not legal.  The str.format() function will have
    a minimalist parser which only attempts to figure out when it is
    "done" with an identifier (by finding a '.' or a ']', or '}',
    etc.).
""" <http://www.python.org/dev/peps/pep-3101>


Why is that a problem for you?

----------
nosy: +belopolsky

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

From report at bugs.python.org  Wed Apr  9 23:28:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Apr 2008 21:28:08 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch makes this work:
>>> range(4) == range(4)
True

This is in similar fashion to dict.keys
>>> {1:2}.keys() == {1:2}.keys()
True

Tests included.

----------
components: Interpreter Core
files: range_eq.patch
keywords: patch
messages: 65266
nosy: benjamin.peterson
severity: normal
status: open
title: Make range __eq__ work
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file9993/range_eq.patch

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

From report at bugs.python.org  Wed Apr  9 23:32:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 09 Apr 2008 21:32:49 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207776769.1.0.419359551404.issue2530@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Georg, I have a few questions:
Just out of curiosity, what did you change? Are their markup things I
missed or other things you're looking for that I just didn't get?

Are we going to want to push some of this stuff back into the docstrings?

Should I backport this to 2.6?

Mark: It has been checked in.

----------
nosy: +mark

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

From report at bugs.python.org  Thu Apr 10 00:04:28 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 22:04:28 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207778668.28.0.146790982731.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Your patch does not check the return values of PyObject_RichCompare
calls for NULL.  This is probably ok given the current restrictions on
the type of start/step/stop, but adding the null checks will make the
code more robust.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Apr 10 00:07:31 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 22:07:31 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207778851.02.0.216522546775.issue2603@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I have no opinion whether the patch should go in, but in any case:

* You should use PyObject_RichCompareBool.
* You should error-check the returns of those.

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Thu Apr 10 00:08:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 22:08:13 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207778893.17.0.462167573205.issue2603@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ah yes, and variable declarations must be at the start of a block, else
MSVC (and possible other compilers) will complain.

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

From report at bugs.python.org  Thu Apr 10 00:10:27 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 22:10:27 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207779027.13.0.0869887476893.issue2530@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Other than the "class.method" change you already noticed, I changed some
"method"s to "attribute"s (since they are @propertied in the source),
removed parens in :meth:`` roles, moved the constructor description into
the .. class block and did some spelling corrections.

A backport to 2.6 would be great. If you also find time to put some
docstrings in, very good.

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

From report at bugs.python.org  Thu Apr 10 00:11:31 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 22:11:31 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207779091.3.0.0499875265483.issue2568@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, sorry that I made uninformed guesses :)

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

From report at bugs.python.org  Thu Apr 10 00:11:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 09 Apr 2008 22:11:35 +0000
Subject: [issue2568] Seconds range in time unit
In-Reply-To: <1207551193.66.0.586350051723.issue2568@psf.upfronthosting.co.za>
Message-ID: <1207779095.16.0.743551800407.issue2568@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee: georg.brandl -> 

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

From report at bugs.python.org  Thu Apr 10 00:12:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 22:12:24 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207779144.54.0.919676639783.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Actually, the patch contains an exploitable bug:

$ cat x.py
class X(int):
    def __eq__(self, other):
        raise ValueError

x = range(X(1),X(10),X(1))
x == x

$ ./python x.py
Segmentation fault (core dumped)

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

From report at bugs.python.org  Thu Apr 10 00:13:06 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Apr 2008 22:13:06 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207771294.21.0.107543156601.issue2587@psf.upfronthosting.co.za>
Message-ID: <52dc1c820804091513s2169f7a4w32a84d06cea59cc5@mail.gmail.com>


Gregory P. Smith <greg at krypto.org> added the comment:

I think I like the SystemError approach for the same reasons.  It still
exposes the caller's bug but no longer does bad things.

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

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

From report at bugs.python.org  Thu Apr 10 00:13:28 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Wed, 09 Apr 2008 22:13:28 +0000
Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8
	installed
In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za>
Message-ID: <1207779208.64.0.523027203431.issue2256@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

Ping.

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

From report at bugs.python.org  Thu Apr 10 00:15:31 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 09 Apr 2008 22:15:31 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207779331.14.0.91004080239.issue2587@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Cool. Let's make this a SystemError (in both debug builds and non-debug
build). Greg, go ahead and fix it.

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

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

From report at bugs.python.org  Thu Apr 10 00:18:47 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Wed, 09 Apr 2008 22:18:47 +0000
Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8
	installed
In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za>
Message-ID: <1207779526.97.0.617244006611.issue2256@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

It appears that issue2563 may be a dependency.

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

From report at bugs.python.org  Thu Apr 10 00:21:28 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 09 Apr 2008 22:21:28 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207778893.17.0.462167573205.issue2603@psf.upfronthosting.co.za>
Message-ID: <d38f5330804091521y1011f50br39828fd50bcc1acc@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 9, 2008 at 6:08 PM, Georg Brandl <report at bugs.python.org> wrote:

>  Ah yes, and variable declarations must be at the start of a block

You can avoid the need for extra local variables by declaring
range_richcompare arguments as rangeobject* and casting the function
to richcmpfunc in type initialization.  See for example
weakrefobject.c implementation.

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

From report at bugs.python.org  Thu Apr 10 00:45:20 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Apr 2008 22:45:20 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207781120.97.0.140882205261.issue2587@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith

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

From report at bugs.python.org  Thu Apr 10 00:45:29 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Apr 2008 22:45:29 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207781129.15.0.486361487843.issue2587@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Thu Apr 10 01:25:00 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Apr 2008 23:25:00 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207783500.47.0.948004662062.issue2587@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

python trunk r62261 adds the checks and SystemError.

patches to cleanup modules that inadvertently allow negative values to
be passed into *_FromStringAndSize would still be appreciated.

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

From report at bugs.python.org  Thu Apr 10 01:28:19 2008
From: report at bugs.python.org (Bill Janssen)
Date: Wed, 09 Apr 2008 23:28:19 +0000
Subject: [issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows
	behavior
In-Reply-To: <1188344792.32.0.918453115921.issue1049@psf.upfronthosting.co.za>
Message-ID: <1207783699.29.0.843375136146.issue1049@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Here's what the OS X man page says:

The getsockname() function returns the value 0 if successful; otherwise
the value -1 is returned and the global variable errno is set to
indicate the error.

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

From report at bugs.python.org  Thu Apr 10 01:43:10 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 09 Apr 2008 23:43:10 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207784590.54.0.00299788237315.issue2587@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

release25-maint r62262

I'm closing this one.  Please open additional issues with patches and/or
pointers to bad callers of *_FromStringAndSize that let negative values
through.

[*sigh* i wish we didn't use a signed size type all over the place]

----------
resolution:  -> fixed
status: open -> closed
versions:  -Python 2.5

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

From report at bugs.python.org  Thu Apr 10 02:18:04 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Apr 2008 00:18:04 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207784590.54.0.00299788237315.issue2587@psf.upfronthosting.co.za>
Message-ID: <ca471dc20804091718n2b05a0fcyc7919b59c37204e0@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

>  [*sigh* i wish we didn't use a signed size type all over the place]

What would you use for error returns then?

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

From report at bugs.python.org  Thu Apr 10 03:56:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Apr 2008 01:56:36 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207792596.22.0.351709684222.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the help.

Added file: http://bugs.python.org/file9995/range_eq2.patch

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

From report at bugs.python.org  Thu Apr 10 04:03:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Apr 2008 02:03:12 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1207792992.74.0.0545579248193.issue2530@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

When you remove the class from the method declaration, it shows up in
the html as io.write? Is this correct?

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

From report at bugs.python.org  Thu Apr 10 05:40:47 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 10 Apr 2008 03:40:47 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>


New submission from Piet Delport <pjdelport at gmail.com>:

DocTestCase.tearDown destructively clears its DocTest instance's globs,
preventing the test from being run repeatedly (such as with trial
--until-failure).

There's a fix for this in zope.testing's version of doctest, which
resets the globs instead:

http://svn.zope.org/?view=rev&rev=39023

----------
components: Library (Lib)
messages: 65285
nosy: pjd
severity: normal
status: open
title: doctest.DocTestCase fails when run repeatedly
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Apr 10 06:23:43 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 10 Apr 2008 04:23:43 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207801423.77.0.746320122683.issue2604@psf.upfronthosting.co.za>


Piet Delport <pjdelport at gmail.com> added the comment:

Addendum:  This appears to be a regression in r36809 (Python 2.4+).

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

From report at bugs.python.org  Thu Apr 10 08:02:46 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 06:02:46 +0000
Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8
	installed
In-Reply-To: <1207779208.64.0.523027203431.issue2256@psf.upfronthosting.co.za>
Message-ID: <47FDAD82.2060401@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Ping.

Does the problem still exist in 2.6a2? It shouldn't.

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

From report at bugs.python.org  Thu Apr 10 09:16:10 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 10 Apr 2008 07:16:10 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207811770.5.0.456573177056.issue2603@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

And, a __hash__ method should be added.

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

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

From report at bugs.python.org  Thu Apr 10 12:15:09 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 10 Apr 2008 10:15:09 +0000
Subject: [issue2605] Descriptor instance attributes not interpreted
	consistently
In-Reply-To: <1207822509.14.0.860100540347.issue2605@psf.upfronthosting.co.za>
Message-ID: <1207822509.14.0.860100540347.issue2605@psf.upfronthosting.co.za>


New submission from Piet Delport <pjdelport at gmail.com>:

Short version:  __get__/__set__/__delete__ attributes on descriptor objects
(as opposed to their types) are treated inconsistently as part of the
descriptor
protocol:  the documentation and support code includes them;  the core
implementation doesn't.

Example:

    class D(object):
        __get__ = lambda self, i, o: 'D'

    class C(object):
        d = D()
        d.__get__ = lambda i, o: 'd'
        d.__set__ = lambda i, v: 1/0

    c = C()

According to pydoc and inspect, and the description in the reference manual
(section 3.4.2.3), d's __get__ and __set__ override D's:

    >>> inspect.isdatadescriptor(C.__dict__['d'])
    True
    >>> help(C)
    class C(__builtin__.object)
    |  Data descriptors defined here:
    ...
    |  d

    >>> type(c).__dict__['d'].__get__(c, type(c))
    'd'
    >>> type(c).__dict__['d'].__set__(c, 5)
    ZeroDivisionError: integer division or modulo by zero

According to CPython, they have no effect:

    >>> c.d
    'D'
    >>> c.d = 5; c.d
    5

PEP 252 notes: "For speed, the get and set methods are type slots", which
points to the CPython behavior being an intentional concession for
performance.

Should CPython respect descriptor object attributes, if reasonable
performance
can be maintained?  Otherwise, should the documentation and support code be
changed to ignore them?

----------
components: Interpreter Core, Library (Lib)
messages: 65289
nosy: pjd
severity: normal
status: open
title: Descriptor instance attributes not interpreted consistently
type: behavior
versions: Python 2.2, Python 2.2.1, Python 2.2.2, Python 2.2.3, Python 2.3, Python 2.4, Python 2.5, Python 2.6, Python 3.0

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

From report at bugs.python.org  Thu Apr 10 14:19:18 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 10 Apr 2008 12:19:18 +0000
Subject: [issue2606] trace module crashes due to using wrong sort idiom
In-Reply-To: <1207829958.28.0.410413314443.issue2606@psf.upfronthosting.co.za>
Message-ID: <1207829958.28.0.410413314443.issue2606@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

In Py30a4's trace.py there is this:

    calls = self.calledfuncs.keys()
    calls.sort()

which causes:
    AttributeError: 'dict_keys' object has no attribute 'sort'

There are two other occurrences of this idiom in trace.py (just search
for ".sort"). I guess they should be easy to fix.

----------
components: Library (Lib)
messages: 65290
nosy: mark
severity: normal
status: open
title: trace module crashes due to using wrong sort idiom
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Thu Apr 10 14:40:08 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 10 Apr 2008 12:40:08 +0000
Subject: [issue1049] socket.socket.getsockname() has inconsistent UNIX/Windows
	behavior
In-Reply-To: <1188344792.32.0.918453115921.issue1049@psf.upfronthosting.co.za>
Message-ID: <1207831208.84.0.85738114095.issue1049@psf.upfronthosting.co.za>


Changes by Trent Nelson <tnelson at onresolve.com>:


----------
nosy: +Trent.Nelson

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

From report at bugs.python.org  Thu Apr 10 15:06:09 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Apr 2008 13:06:09 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207811770.5.0.456573177056.issue2603@psf.upfronthosting.co.za>
Message-ID: <d38f5330804100606y4c02cfd0v3daab76985e3e70e@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 10, 2008 at 3:16 AM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
>
>  And, a __hash__ method should be added.
>

See issue2268 for a slice.__hash__ implementation which should work
for range as well.

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

From report at bugs.python.org  Thu Apr 10 15:37:24 2008
From: report at bugs.python.org (Fred L. Drake, Jr.)
Date: Thu, 10 Apr 2008 13:37:24 +0000
Subject: [issue1297] pyconfig.h not compatible with MS VC++ Express Edition
In-Reply-To: <47FD1409.5050406@v.loewis.de>
Message-ID: <C9FC5051-3F65-4747-A9F8-7135C1E2D9B4@acm.org>


Fred L. Drake, Jr. <fdrake at acm.org> added the comment:

On Apr 9, 2008, at 3:07 PM, Martin v. L?wis wrote:
> Fred, can you remember what the rationale was?

No; sorry.  I didn't even remember that I'd ever built Python on  
Windows.  Some things I've blocked out.

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

From report at bugs.python.org  Thu Apr 10 18:21:41 2008
From: report at bugs.python.org (Andreas Eisele)
Date: Thu, 10 Apr 2008 16:21:41 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>


New submission from Andreas Eisele <eisele at dfki.de>:

I need to count pairs of strings, and I use 
a defaultdict in a construct like

count[a,b] += 1

I am able to count 50K items per second on a very fast machine,
which is way too slow for my application.

If I count complete strings like

count[ab] += 1

it can count 500K items/second, which is more reasonable.

I don't see why there is a performance penalty of a factor
of 10 for such a simple construct.

Do I have to switch to Perl or C to get this done???

Thanks a lot for any insight on this.

Best regards,
Andreas

PS.: The problem seems to exist for ordinary
dicts as well, it is not related to the fact that
I use a defaultdict

PPS: I also tried nested defaultdicts
count[a][b] += 1
and get the same slow speed (and 50% more memory consumption)

----------
messages: 65293
nosy: eisele
severity: normal
status: open
title: why is (default)dict so slow on tuples???
type: performance
versions: Python 2.5

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

From report at bugs.python.org  Thu Apr 10 18:26:37 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 10 Apr 2008 16:26:37 +0000
Subject: [issue2606] trace module crashes due to using wrong sort idiom
In-Reply-To: <1207829958.28.0.410413314443.issue2606@psf.upfronthosting.co.za>
Message-ID: <1207844797.26.0.146157031278.issue2606@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I've changed them to sorted(obj.keys())

----------
keywords: +patch
nosy: +gpolo
Added file: http://bugs.python.org/file9996/issue_2606.diff

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

From report at bugs.python.org  Thu Apr 10 18:27:42 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 10 Apr 2008 16:27:42 +0000
Subject: [issue2440] Issues with getargs_n() and PyNumber_Index.
In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za>
Message-ID: <1207844862.36.0.119202814534.issue2440@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Committed patch in r62269.  I'll raise a separate tracker issue for 
PyLong_AsSsize_t as it isn't related to this issue.

----------
assignee:  -> Trent.Nelson
keywords: +64bit
resolution:  -> fixed
status: open -> closed
title: Issues with getargs_n(), PyNumber_Index and PyLong_AsSize_t. -> Issues with getargs_n() and PyNumber_Index.

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

From report at bugs.python.org  Thu Apr 10 18:37:51 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Apr 2008 16:37:51 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207845471.87.0.738787445706.issue2607@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

My guess is that this is due to the fact that strings cache their hash
values while tuples don't.  IIRC, caching tuple's hash values has been
proposed and rejected some time ago.  Furthermore, dict lookups are
heavily optimized for the case when all keys are strings.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Thu Apr 10 18:46:57 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Apr 2008 16:46:57 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1207846017.65.0.637617137493.issue2235@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Hi Amaury, thanks for your work on this. I applied your patch and looked
at the code but there seem to be some issues left still.

(1) I don't think you need to add a warning to classic classes that
define __eq__ without __hash__ -- these aren't hashable and never were.
 The problem is purely with new classes AFAICT.

(2) I can't seen to trigger the warning for new classes (and yes, I
specified -3 on the command line :-):

>>> class C(object):
...   def __eq__(self, other): return False
...
>>> hash(C())
-134976284

(3) test_Hashable in test_collections.py fails.  This is because the
Hashable class believes that list, set, and dict are hashable. 
Something odd is going on:

>>> list.__hash__([])
-135100116

but

>>> hash([])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'list'

Note that in 2.5, both raise TypeError.

----------
assignee:  -> amaury.forgeotdarc

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

From report at bugs.python.org  Thu Apr 10 18:47:43 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Apr 2008 16:47:43 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1207846063.78.0.639458862732.issue2235@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Let's try to have this resolved before the next release.

Also let's try not to accidentally merge the 2.6 changes related to this
issue into 3.0. :-)

----------
priority: high -> release blocker

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

From report at bugs.python.org  Thu Apr 10 18:51:51 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Apr 2008 16:51:51 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1207846311.34.0.656295282981.issue2235@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Note: some more tests also fail:

test_descr, test_quopri, test_set

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

From report at bugs.python.org  Thu Apr 10 18:59:52 2008
From: report at bugs.python.org (Mikhail Gusarov)
Date: Thu, 10 Apr 2008 16:59:52 +0000
Subject: [issue2608] manpages for sphinx-build & sphinx-quickstart
In-Reply-To: <1207846792.27.0.634883270902.issue2608@psf.upfronthosting.co.za>
Message-ID: <1207846792.27.0.634883270902.issue2608@psf.upfronthosting.co.za>


New submission from Mikhail Gusarov <dottedmag at dottedmag.net>:

I just created manpages for sphinx-build and sphinx-quickstart as a 
part of Sphinx debianization.

Feel free to use/change/improve - I'm releasing them under BSD license, 
matching rest of Sphinx.

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
files: sphinx-build.1
messages: 65300
nosy: dottedmag, georg.brandl
severity: normal
status: open
title: manpages for sphinx-build & sphinx-quickstart
type: feature request
Added file: http://bugs.python.org/file9997/sphinx-build.1

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

From report at bugs.python.org  Thu Apr 10 19:00:40 2008
From: report at bugs.python.org (Mikhail Gusarov)
Date: Thu, 10 Apr 2008 17:00:40 +0000
Subject: [issue2608] manpages for sphinx-build & sphinx-quickstart
In-Reply-To: <1207846792.27.0.634883270902.issue2608@psf.upfronthosting.co.za>
Message-ID: <1207846840.03.0.520288865165.issue2608@psf.upfronthosting.co.za>


Changes by Mikhail Gusarov <dottedmag at dottedmag.net>:


Added file: http://bugs.python.org/file9998/sphinx-quickstart.1

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

From report at bugs.python.org  Thu Apr 10 19:01:11 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Apr 2008 17:01:11 +0000
Subject: [issue2609] Tests fail if ./@test is not writeable
In-Reply-To: <1207846870.93.0.178479630911.issue2609@psf.upfronthosting.co.za>
Message-ID: <1207846870.93.0.178479630911.issue2609@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

If @test file is not writable in the current directory,
test_support.TESTFN is changed to '/tmp/@test', but several tests fail
if TESTFN is an absolute path:

$ mkdir @test
$ make test
..
4 tests failed:
    test_import test_site test_urllib test_zipfile
..

For example,

$ ./python -E -tt ./Lib/test/regrtest.py -l test_urllib
test_urllib
test test_urllib failed -- Traceback (most recent call last):
  File "Lib/test/test_urllib.py", line 84, in test_geturl
    self.assertEqual(self.returned_obj.geturl(), self.pathname)
AssertionError: 'file:///tmp/@test' != '/tmp/@test'

Note that I discovered this problem after (probably killed) test_os left
 @test/ directory behind. It took me a while to realize what happened.

I think the simplest fix is to os.chdir to '/tmp' if @test is not
writable instead of changing TESTFN. Other solutions may include
deleting or renaming @test with a warning when it exists, using
tempnam() instead of @test and bailing out if cwd is not writeable etc.

----------
components: Tests
messages: 65301
nosy: belopolsky
severity: normal
status: open
title: Tests fail if ./@test is not writeable
type: behavior
versions: Python 2.6

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

From report at bugs.python.org  Thu Apr 10 19:17:29 2008
From: report at bugs.python.org (David Remahl)
Date: Thu, 10 Apr 2008 17:17:29 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207669300.72.0.572468036548.issue2586@psf.upfronthosting.co.za>
Message-ID: <1207847849.75.0.996835276297.issue2586@psf.upfronthosting.co.za>


David Remahl <chmod007 at users.sourceforge.net> added the comment:

I submit that a check for negative values (non-assert-based) should be 
added to PyString_FromStringAndSize(). This API is called from many, many 
places, and in several cases the operand could probably be negative. It 
should raise an overflow exception for a negative value.

----------
nosy: +chmod007

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

From report at bugs.python.org  Thu Apr 10 19:34:49 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Apr 2008 17:34:49 +0000
Subject: [issue2586] Integer signedness bugs in zlib modules
In-Reply-To: <1207847849.75.0.996835276297.issue2586@psf.upfronthosting.co.za>
Message-ID: <d38f5330804101034yaf7bb5dv156e6997eaaeeaa1@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 10, 2008 at 1:17 PM, David Remahl <report at bugs.python.org> wrote:

>  I submit that a check for negative values (non-assert-based) should be
>  added to PyString_FromStringAndSize().

See issue2587 and r62262.

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

From report at bugs.python.org  Thu Apr 10 19:52:26 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Apr 2008 17:52:26 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <ca471dc20804091718n2b05a0fcyc7919b59c37204e0@mail.gmail.com>
Message-ID: <d38f5330804101052u72fdfb0pa593f8e3e896b061@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 9, 2008 at 8:18 PM, Guido van Rossum <report at bugs.python.org> wrote:

> >  [*sigh* i wish we didn't use a signed size type all over the place]
>
>  What would you use for error returns then?
>

res == (size_t)-1  or res == 0 && PyErr_Occured()

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

From report at bugs.python.org  Thu Apr 10 20:08:18 2008
From: report at bugs.python.org (David Remahl)
Date: Thu, 10 Apr 2008 18:08:18 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207850898.24.0.850846532212.issue2587@psf.upfronthosting.co.za>


Changes by David Remahl <chmod007 at users.sourceforge.net>:


----------
nosy: +chmod007

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

From report at bugs.python.org  Thu Apr 10 20:41:36 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Thu, 10 Apr 2008 18:41:36 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207852896.06.0.0287350263255.issue2587@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

The use of signed integers in Python is (imho) the single largest threat
to the security of the interpreter. I'm probably preaching to the choir
there though. 

I really dislike have to return values and indicate error in the return
value, its really unclean and causes weirdness, for instance if you
follow PyArg_ParseTuple() down and you have an integer (or maybe it was
long?) argument, you can't actually get a value of -1 because one of the
string->int conversion routines uses that to indicate failure. The check
wrapped around it was something along the lines of:

if (-1 == retval && PyErr_Occurred())

In turn down the line somewhere (I didn't follow the code path), this
value got converted to 1, so for instance doing
__import__('zlib').decompressobj().flush(-1) wouldn't trigger that bug,
it would flush 1 byte, not UINT_MAX as I had expected

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

From report at bugs.python.org  Thu Apr 10 20:47:38 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Apr 2008 18:47:38 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207853258.75.0.94664824492.issue2587@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Greg, any reason why you kept the assert()?  IMO having the ValueError
even in debug mode is better.

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

From report at bugs.python.org  Thu Apr 10 20:53:30 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Durigan_J=C3=BAnior?=)
Date: Thu, 10 Apr 2008 18:53:30 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1207853610.79.0.132626903004.issue1628484@psf.upfronthosting.co.za>


S?rgio Durigan J?nior <sergiodj at linux.vnet.ibm.com> added the comment:

Hi,

I'd like to know the status of this issue. I'm having the same problems
here with PPC64, and the patch that Bob Atkins has sent works fine for
me too. Would you intend to apply this patch in upstream?

Thanks in advance.

----------
nosy: +sergiodj

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

From report at bugs.python.org  Thu Apr 10 21:03:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 19:03:07 +0000
Subject: [issue2606] trace module crashes due to using wrong sort idiom
In-Reply-To: <1207829958.28.0.410413314443.issue2606@psf.upfronthosting.co.za>
Message-ID: <1207854187.63.0.837233688926.issue2606@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I've further simplified the code by eliminating the local variables, and
committed that as r62270.

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

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

From report at bugs.python.org  Thu Apr 10 21:15:24 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 19:15:24 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207854924.18.0.500857614694.issue2607@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I cannot reproduce this. The attached script for me gives for 1M
iterations a total time of 0.8s, on 3.2GHz Pentium 4.

----------
nosy: +loewis
resolution:  -> works for me

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

From report at bugs.python.org  Thu Apr 10 21:15:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 19:15:47 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207854947.2.0.332400331074.issue2607@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


Added file: http://bugs.python.org/file9999/a.py

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

From report at bugs.python.org  Thu Apr 10 21:25:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 19:25:47 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1207853610.79.0.132626903004.issue1628484@psf.upfronthosting.co.za>
Message-ID: <47FE69B6.3060703@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'd like to know the status of this issue. I'm having the same problems
> here with PPC64, and the patch that Bob Atkins has sent works fine for
> me too. Would you intend to apply this patch in upstream?
> 
> Thanks in advance.

It's difficult to tell whether the patch can be applied until it is
reviewed. Until then, this issue will stay open.

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

From report at bugs.python.org  Thu Apr 10 21:28:02 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 10 Apr 2008 19:28:02 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207855682.32.0.185446525619.issue2587@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The asserts can go.  I left them in figuring a crashing interpreter on a
debug build in someones sandbox or on a buildbox would get more
attention than a SystemError being raised.  I doubt that is a worthy
assumption on my part.

Both a crash and a SystemError are notable events.

shall I get rid of the asserts?

As for why i dislike signed size types... tons of reasons:
 * It wastes half the range of the integer.
 * It leads to security bugs.
 * on return values -1 and < 0 tests may be convenient to type but they 
   could just as easily compare to a known value defined as a constant; 
   all the things alexander belopolsky suggested.
 * sizes being passed -in- to a function never need to be negative
   meaning safe code requires extra checks like these.
 * sign extension of values going between registers of different sizes
   is needlessly expensive on some cpu architectures.  use unsigned
   types whenever possible for the best code.

anyways, I figure the Python C API is already set in stone using the
signed types so its too late to "fix" it without causing headaches
around the world.

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

From report at bugs.python.org  Thu Apr 10 21:48:05 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 10 Apr 2008 19:48:05 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207856885.84.0.0629246175702.issue2587@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Please do get rid of the asserts.

Regarding signed sizes, it's a historic accident (copied from Unix
system calls which tended to use plain ints or longs in the olden days),
but it may not be impossible to fix -- we've fixed other things
throughout the code (e.g. switching from int to Py_ssize_t).  It'll be a
monumental task though that's probably best tackled post-3.0.

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

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

From report at bugs.python.org  Thu Apr 10 21:49:50 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 10 Apr 2008 19:49:50 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207856990.05.0.0889235910298.issue2607@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Questions about relative performance should be directed to 
comp.lang.python.

Since no bug or suspect behavior was reported, closing as not-a-bug.

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

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

From report at bugs.python.org  Thu Apr 10 21:54:58 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Thu, 10 Apr 2008 19:54:58 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207669747.73.0.910333357226.issue2587@psf.upfronthosting.co.za>
Message-ID: <1207857298.06.0.876886172583.issue2587@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

asserts nuked.  r62271 and r62272

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

From report at bugs.python.org  Thu Apr 10 22:08:44 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 10 Apr 2008 20:08:44 +0000
Subject: [issue2587] PyString_FromStringAndSize() to be considered unsafe
In-Reply-To: <1207856885.84.0.0629246175702.issue2587@psf.upfronthosting.co.za>
Message-ID: <d38f5330804101308w67c6bfe8xd00ac907b2d5d469@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 10, 2008 at 3:48 PM, Guido van Rossum
<report at bugs.python.org> wrote:

Maybe as the first step we could get rid of the size sign abuse in
long integer objects.  I would suggest reserving a bit in the first
(or last) digit to carry the sign.

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

From report at bugs.python.org  Thu Apr 10 22:18:29 2008
From: report at bugs.python.org (Brad Miller)
Date: Thu, 10 Apr 2008 20:18:29 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>


New submission from Brad Miller <bonelake at gmail.com>:

I use Python in my CS1 and CS2 curriculum and I have a question.
As I've been using the Python 3.0 alphas one of the things that I am
bothered by is that I cannot see the sequence produced by range
without introducing students to the list() function.

I typically introduce range on day 1 of class and show students what
it produces without making a big deal out of the fact that it creates
a list.  They all accept this and things work out nicely when I
introduce lists for real in a week or two.

My question is why couldn't the __str__ method for the range object be
more friendly and show a representation of the sequence?  I understand
why __repr__ should return range(0,10) for an object created using
range(10) but couldn't print(range(10)) produce [0, 1, 2, ... 9]
The ... could even be used if the sequence were excessively long.

I have attached a patch, which follows the suggestion from Guido on how 
to format the string so it is not confused with a list.

This is my first attempt at patching any part of the C code for Python.  
Please let me know what should be changed and If I've missed something.

In particular I wonder whether I should be nesting any calls to PyNumber 
functions or whether temporary variables should be used to avoid leaking 
memory?

In addition I get the following warning on the line where I install the 
range_str function in the PyRange_Type array.

Objects/rangeobject.c:357: warning: initialization from incompatible 
pointer type


Brad

----------
components: Interpreter Core
files: range_str.patch
keywords: patch
messages: 65316
nosy: bmiller
severity: normal
status: open
title: string representation of range
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10000/range_str.patch

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

From report at bugs.python.org  Thu Apr 10 22:32:19 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Durigan_J=C3=BAnior?=)
Date: Thu, 10 Apr 2008 20:32:19 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1207859539.85.0.569340860718.issue1628484@psf.upfronthosting.co.za>


S?rgio Durigan J?nior <sergiodj at linux.vnet.ibm.com> added the comment:

Hi Martin,

Thanks for your quick answer. I'd like to know what can we do to push
this patch into upstream. Does the fact that the patch is posted in a
bug report (and not in a developer's mailing list) is slowing down the
reviewing process?

Regards.

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

From report at bugs.python.org  Thu Apr 10 22:40:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Apr 2008 20:40:46 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1207860046.79.0.969125025474.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Including __hash__ in this patch. Alexander, thanks; that could worked
perfectly.

Added file: http://bugs.python.org/file10001/range_eq3.patch

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

From report at bugs.python.org  Thu Apr 10 22:58:40 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 10 Apr 2008 20:58:40 +0000
Subject: [issue2221] Py30a3: eval in threaded code raises SystemError
In-Reply-To: <1204544069.74.0.858936575145.issue2221@psf.upfronthosting.co.za>
Message-ID: <1207861120.12.0.737071824709.issue2221@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I think this is good enough: you should not invoke python code with a
pending exception set (PyErr_Occurred()).

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

From report at bugs.python.org  Thu Apr 10 23:05:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Apr 2008 21:05:18 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207861518.47.0.481689763459.issue2610@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the patch! You can avoid the compiler warning by casting to
reprfunc like this:

(reprfunc)range_str /* tp_str */

Also, some of the whitespace needs reformating. Please put a space
between the parameters passed a function, and remove the ones in the
conditionals.

You should use PyObject_RichCompareBool.

All the calls to functions like PyLong_FromLong and PyNumber_* can
possibly return NULL on error, so you must check for that. Sometimes
it's useful to have a goto for failures at the end of your function in
which you Py_XDECREF everything.

Could you take the space from the "<" and ">" at the end of the
representation?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Thu Apr 10 23:13:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 21:13:33 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <47FE82F9.2010304@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I use Python in my CS1 and CS2 curriculum and I have a question.

At this point, I would have almost stopped reading - the tracker
is not a place for questions. I read on and then noticed that you
have a patch also, not just a question :-)

> This is my first attempt at patching any part of the C code for Python.  
> Please let me know what should be changed and If I've missed something.

The formatting of the C code is wrong in on place (there must not be a
space after the opening or before the closing parenthesis); I would also
drop the space after the < and before the > in the result.

Please try to avoid replicating code as much as possible. Rather than
this complex muliply/add code, use range_item(r, 1), range_item(r, 2),
range_item(r, -2), range_item(r, -1). Use range_length to find out how
many things are in the range, and then again range_item for the 0..7th
element.

Don't use PyUnicode_FromFormat for a single %R; use PyObject_Repr
instead.

The code leaks many object references. Almost any function you call
produces a new reference, and you have to decref it after you don't
need the value anymore. E.g. write

  repr = PyObject_Repr(nth);
  appended = PyUnicode_Concat(result, repr);
  Py_DECREF(repr); // not needed anymore, so release it
  Py_DECREF(result); // about to assign to result, so release old value
  result = appended;

Consider exceptions. About any function returning PyObject* can fail
with an exception, if for not other reason than being out-of-memory.
Don't forget to release partial results in case an exception, making
your code like

  repr = PyObject_Repr(nth);
  if (!repr)
    goto fail;
  appended = PyUnicode_Concat(result, repr);
  if (!appended)
    goto fail;
  Py_DECREF(repr);
  Py_DECREF(result);
  result = appended;
...
fail:
  Py_XDECREF(repr);
  Py_XDECREF(appended);
  ...
  return NULL;

As we don't know in the failure case easily whether appended was already
assigned to, we use XDRECREF; don't forget to initialize appended with
NULL.

As both the success case and the failure case end with a long list
of DECREFs, it is common to phrase that as

  PyObject *result = NULL;
  ...
  result = what_shall_i_really_return;
  what_shall_i_really_return = NULL;
fail:
  lots_of_xdecrefs;
  return result;

In your case, it might be useful to create an array of up to 7
PyObject*, zero-initialize that, and put the partial results in
there; then XDECREF that in a loop at the end.

HTH,
Martin

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

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

From report at bugs.python.org  Thu Apr 10 23:15:49 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Thu, 10 Apr 2008 21:15:49 +0000
Subject: [issue1649238] potential clash with C++ in ceval.h
Message-ID: <1207862149.65.0.319753485789.issue1649238@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
keywords: +easy

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

From report at bugs.python.org  Thu Apr 10 23:17:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 21:17:59 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1207859539.85.0.569340860718.issue1628484@psf.upfronthosting.co.za>
Message-ID: <47FE8404.8070007@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Thanks for your quick answer. I'd like to know what can we do to push
> this patch into upstream. Does the fact that the patch is posted in a
> bug report (and not in a developer's mailing list) is slowing down the
> reviewing process?

No, it's the lack of reviewers in the first place that is slowing all
patches, not just this one.

I'm skeptical about this patch. We already have BASECFLAGS, and blindly
copying  @CFLAGS@ into CFLAGS might break things if configure also
decides to add the same or conflicting flags.

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

From report at bugs.python.org  Thu Apr 10 23:34:58 2008
From: report at bugs.python.org (Jim Kleckner)
Date: Thu, 10 Apr 2008 21:34:58 +0000
Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8
	installed
In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za>
Message-ID: <1207863298.44.0.346230945241.issue2256@psf.upfronthosting.co.za>


Jim Kleckner <jek-python at kleckner.net> added the comment:

I hadn't seen any comment here that I should try it again until your
question (that was why the ping).

I did try it again and my application worked.

Thanks!

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

From report at bugs.python.org  Thu Apr 10 23:36:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Apr 2008 21:36:40 +0000
Subject: [issue2440] Issues with getargs_n() and PyNumber_Index.
In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za>
Message-ID: <1207863400.7.0.604046159957.issue2440@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Trent, that commit broke several tests (test_builtin for one) that
relied on a floats not being interpreted as longs.

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Fri Apr 11 00:00:45 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 10 Apr 2008 22:00:45 +0000
Subject: [issue2256] Install failure of 2.6a1 on Windows XP without VS8
	installed
In-Reply-To: <1204932826.89.0.672189283054.issue2256@psf.upfronthosting.co.za>
Message-ID: <1207864845.43.0.483628062775.issue2256@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


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

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

From report at bugs.python.org  Fri Apr 11 00:06:37 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 10 Apr 2008 22:06:37 +0000
Subject: [issue2440] Issues with getargs_n() and PyNumber_Index.
In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za>
Message-ID: <1207865197.33.0.132366627443.issue2440@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Eek, so it does, thanks.  Applied the following patch on a bunch of 32-
bit/x64 systems, testing now, so far everything looks good...

Index: abstract.c
===================================================================
--- abstract.c  (revision 62279)
+++ abstract.c  (working copy)
@@ -1240,7 +1240,7 @@
                        return NULL;
                }
        }
-       else if (m && m->nb_int != NULL) {
+       else if (m && m->nb_int != NULL && m->nb_float == NULL) {
                result = m->nb_int(item);
                if (result && !PyLong_Check(result)) {
                        PyErr_Format(PyExc_TypeError,

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

From report at bugs.python.org  Fri Apr 11 00:30:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 10 Apr 2008 22:30:30 +0000
Subject: [issue2440] Issues with getargs_n() and PyNumber_Index.
In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za>
Message-ID: <1207866630.78.0.0845610215966.issue2440@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for fixing that.

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

From report at bugs.python.org  Fri Apr 11 00:35:44 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 10 Apr 2008 22:35:44 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1207866944.68.0.0857413689152.issue2240@psf.upfronthosting.co.za>


Changes by Trent Nelson <tnelson at onresolve.com>:


----------
nosy: +Trent.Nelson

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

From report at bugs.python.org  Fri Apr 11 00:55:26 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 10 Apr 2008 22:55:26 +0000
Subject: [issue2611] Extend buildbot web interface to allow for forced tests
	to be run on a slave in verbose mode.
In-Reply-To: <1207868126.69.0.898204218113.issue2611@psf.upfronthosting.co.za>
Message-ID: <1207868126.69.0.898204218113.issue2611@psf.upfronthosting.co.za>


New submission from Trent Nelson <tnelson at onresolve.com>:

It'd be nice if there was a facility to force a particular test to be 
re-run in verbose mode with the most recent build via the buildbot web 
interface.  It would allow us to get a bit more information about 
what's going on when the buildbots report stuff like this:

test_property
test_cprofile
test_signal

command timed out: 1800 seconds without output, killing pid 214235
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1

Neal or Martin, if neither of you have the desire/bandwidth to look 
into this, I'm more than happy to take it on.  Suspect it'd involve a 
buildbot change on dinsdale right?

----------
components: Build
messages: 65328
nosy: Trent.Nelson, loewis, nnorwitz
severity: normal
status: open
title: Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.
type: feature request

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

From report at bugs.python.org  Fri Apr 11 01:44:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 10 Apr 2008 23:44:08 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1207871048.49.0.684141234687.issue2235@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a new patch, all tests pass.
- no warning for classic classes
- added tests for -3 warnings

I had to add two TPSLOT entries to the slodefs list; can you please
check that this is correct (I wanted to reset tp_hash to NULL when
__eq__ or __cmp__ are defined).

Added file: http://bugs.python.org/file10002/inherit_hash3.patch

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

From report at bugs.python.org  Fri Apr 11 04:04:26 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 11 Apr 2008 02:04:26 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207879466.62.0.9144401122.issue2610@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

Thanks for all of the help.  Using range_item certainly simplified my 
job.  Although I more than made up for it with all of the decref and 
error checking calls.

One side effect of using range_item is that str(range(...)) is now 
subject to the same errors as indexing into really big range:
for example: 
x = range(1000000000000000000)
x[1]
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

In a world where ints and long ints have been unified the existence of 
this error seems like a bug.

I think the right thing would be to fix range_item and range_length so 
they do not use Py_ssize_t for the length of the range.  But I may be in 
over my head on that guess.

I also discovered that range_item does not work with negative indices.

I have been poking around the tests and added some simple tests to the 
test_range.py class as well.  I assume I should submit a patch for that 
as well?

I have attached a new patch for rangeobject.c

Brad

Added file: http://bugs.python.org/file10003/range_str_2.patch

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

From report at bugs.python.org  Fri Apr 11 04:45:15 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Fri, 11 Apr 2008 02:45:15 +0000
Subject: [issue2612] file.tell() returns Long usually, Int if subclassed
In-Reply-To: <1207881915.59.0.417748346236.issue2612@psf.upfronthosting.co.za>
Message-ID: <1207881915.59.0.417748346236.issue2612@psf.upfronthosting.co.za>


New submission from Darryl Dixon <esrever_otua at winterhouseconsulting.com>:

Compare:


>>> class y(file):
...     def __init__(self, name):
...         file.__init__(self, name)
...     def __len__(self):
...         self.seek(0, 2)
...         return self.tell()
... 
>>> n = y('/tmp/longfile')
>>> len(n)
364773376


Versus:


>>> class z:
...     def __init__(self, name):
...         self.f = file(name, 'r')
...     def __len__(self):
...         self.f.seek(0, 2)
...         return self.f.tell()
... 
>>> x = z('/tmp/longfile')
>>> len(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: __len__() should return an int


Because:



>>> x = file('/tmp/longfile')
>>> type(x.tell())
<type 'long'>

----------
components: Library (Lib)
messages: 65331
nosy: esrever_otua
severity: normal
status: open
title: file.tell() returns Long usually, Int if subclassed
type: behavior
versions: Python 2.4

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

From report at bugs.python.org  Fri Apr 11 04:46:15 2008
From: report at bugs.python.org (Andreas Eisele)
Date: Fri, 11 Apr 2008 02:46:15 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207881975.23.0.774163354534.issue2607@psf.upfronthosting.co.za>


Andreas Eisele <eisele at dfki.de> added the comment:

Sorry for not giving a good example in the first place.
The problem seems to appear only in the presence of
sufficiently many distinct tuples. Then I see performance
that looks rather like O(n*n)
Here is an example that shows the problem:

>>> from time import clock
>>> d = {}
>>> t0 = clock()
>>> for i in range(5):
 for j in range(i*1000000,(i+1)*1000000):
  d[str(j),str(j)]=j
 print clock()-t0


13.04
39.51
81.86
134.18
206.66
>>>

The same example with str(j)+str(j) works fine.

Sorry if this should be a non-issue. For me it is a
reason to implement functionality in C or Perl
that I would really love to do in Python.
I would call such a thing a performance bug, but
maybe I'm just too demanding...

Best regards,
Andreas

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

From report at bugs.python.org  Fri Apr 11 04:58:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Apr 2008 02:58:40 +0000
Subject: [issue2612] file.tell() returns Long usually, Int if subclassed
In-Reply-To: <1207881915.59.0.417748346236.issue2612@psf.upfronthosting.co.za>
Message-ID: <1207882720.12.0.757183393948.issue2612@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is because y is a new-style class (because file is) and z is not.
If the return type of new-style classe's len is not an int, Python tries
to convert it, which is why that works for the first example. However,
that conversion doesn't happen in old-style classes. Try:

>>> class z(object):
...     def __init__(self, name):
...         self.f = file(name, 'r')
...     def __len__(self):
...         self.f.seek(0, 2)
...         return self.f.tell()
>>> x = z('/tmp/longfile')
>>> len(x)
[Whatever it is]

----------
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

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

From report at bugs.python.org  Fri Apr 11 05:47:34 2008
From: report at bugs.python.org (Darryl Dixon)
Date: Fri, 11 Apr 2008 03:47:34 +0000
Subject: [issue2612] file.tell() returns Long usually, Int if subclassed
In-Reply-To: <1207881915.59.0.417748346236.issue2612@psf.upfronthosting.co.za>
Message-ID: <1207885654.13.0.247046760075.issue2612@psf.upfronthosting.co.za>


Darryl Dixon <esrever_otua at winterhouseconsulting.com> added the comment:

Thanks Benjamin, that is a very interesting feature that I can't find
documented anywhere. Is there perhaps a documentation bug that can arise
from this? There are various places where the differences between old
and new-style classes are documented to a greater or lesser degree, eg:
http://www.python.org/download/releases/2.2.3/bugs/
Is this documented somewhere currently that I missed, or could it be
incorporated somewhere?

thanks,
D

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

From report at bugs.python.org  Fri Apr 11 08:26:22 2008
From: report at bugs.python.org (James Henstridge)
Date: Fri, 11 Apr 2008 06:26:22 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207895182.81.0.582320582814.issue2604@psf.upfronthosting.co.za>


James Henstridge <james at jamesh.id.au> added the comment:

Is repeating a test with the same TestCase instance ever safe?  It'd be
better to create a new instance and run that.

If any of the variables in test.globs are changed by the test (e.g.
appending to a list), then rerunning the test will not necessarily give
the same result.

While the zope change allows tests that have immutable globals or don't
change their globals to function, it also lets other tests "almost"
work, and could lead to new bugs that are difficult to track down.

----------
nosy: +jamesh

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

From report at bugs.python.org  Fri Apr 11 08:31:24 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Apr 2008 06:31:24 +0000
Subject: [issue2611] Extend buildbot web interface to allow for forced tests
	to be run on a slave in verbose mode.
In-Reply-To: <1207868126.69.0.898204218113.issue2611@psf.upfronthosting.co.za>
Message-ID: <1207895484.64.0.813690522002.issue2611@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think this will be fairly difficult to set up. If the clean buildstep
had been executed, you would have to rerun configure and compile before
you can run any tests.

Also, how would you communicate what specific test you want to run?
A "builder" (a lane in the waterfall) has a fixed sequence of build
steps, where one is "test", and a step can be described with a shell
command. The test step simply invokes "make buildbottest". I don't know
whether it's possible to pass per-build parameters to each step (except
perhaps to the svn step); you could ask for that on the buildbot mailing
list.

The simplest solution to achieve the desired effect is to create a
branch in subversion where the buildbottest target does something
different, and then ask the slave in question to build that branch.

In any case, no, I won't be able to look into this further anytime soon.

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

From report at bugs.python.org  Fri Apr 11 08:32:43 2008
From: report at bugs.python.org (Torsten Bronger)
Date: Fri, 11 Apr 2008 06:32:43 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1207895563.13.0.965783290686.issue992389@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

I have a very similar issue (maybe the same?) at the moment.

Assume the follwing package structure:

main.py
package/
    __init__.py   [empty]
    moduleX.py
    moduleY.py

main.py says:

    from package import moduleX

moduleX.py says:

    from . import moduleY

and moduleY.py says:

    from . import moduleX

However, this doesn't work:

    bronger at wilson:~/temp/packages-test$ python main.py
    Traceback (most recent call last):
      File "main.py", line 1, in <module>
        from package import moduleX
      File "/home/bronger/temp/packages-test/package/moduleX.py", line
1, in <module>
        from . import moduleY
      File "/home/bronger/temp/packages-test/package/moduleY.py", line
1, in <module>
        from . import moduleX
    ImportError: cannot import name moduleX

If I turn the relative imports to absolutes ones, it works.  But I'd
prefer the relative notation for intra-package imports.  That's their
purpose after all.

If you split a large module into chunks, cyclic imports are hardly
avoidable (and there's nothing bad about it; it worked fine before PEP 328).

Note that "import absolute.path.to.module as short" doesn't work either.
 So currently, in presence of cyclic imports in a package, the only
remedy is to use the full absolute paths everywhere in the source code,
which is really awkward in my opinion.

----------
nosy: +bronger

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

From report at bugs.python.org  Fri Apr 11 08:48:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Apr 2008 06:48:53 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207879466.62.0.9144401122.issue2610@psf.upfronthosting.co.za>
Message-ID: <47FF09D1.2070306@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> In a world where ints and long ints have been unified the existence of 
> this error seems like a bug.
> 
> I think the right thing would be to fix range_item and range_length so 
> they do not use Py_ssize_t for the length of the range.  But I may be in 
> over my head on that guess.

The question is: what C type to use instead? Whatever native type you
use, it will always have a limitation. Assuming that range() elements
are typically used as indices into collections, having them Py_ssize_t
is fine because no standard collection (string, tuple, list) can have
more than 2**(8*sizeof(Py_ssize_t)) elements, on any computer, as
that would exceed the address space of that computer.

In any case, I think it is fine that str() has this limitation when
you can't actually access the values of the range object, anyway.
If the limit where to be removed, somebody would have to rewrite

> I have been poking around the tests and added some simple tests to the 
> test_range.py class as well.  I assume I should submit a patch for that 
> as well?

Indeed. The code looks fine to me now, please to provide a patch also.

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

From report at bugs.python.org  Fri Apr 11 10:00:03 2008
From: report at bugs.python.org (Piet Delport)
Date: Fri, 11 Apr 2008 08:00:03 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207900803.35.0.466184358153.issue2604@psf.upfronthosting.co.za>


Piet Delport <pjdelport at gmail.com> added the comment:

> If any of the variables in test.globs are changed by the test (e.g. 
appending to a list), then rerunning the test will not necessarily give
the same result.

This is true, but modifying the globals such that subsequent runs of the
same test can break equally affects subsequent runs of any other tests
that use that module:  such a test is already broken (unsafe to run with
other tests) to begin with, independent of the DocTestCase.tearDown issue.

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

From report at bugs.python.org  Fri Apr 11 10:42:51 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Fri, 11 Apr 2008 08:42:51 +0000
Subject: [issue2613] inconsistency with bare * in parameter list
In-Reply-To: <1207903370.95.0.0868464301565.issue2613@psf.upfronthosting.co.za>
Message-ID: <1207903370.95.0.0868464301565.issue2613@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

A bare * in a parameter list behaves differently depending on what
follows it:

Py30a4:

>>> def f(*, a=1, b=2): return 1

>>> def g(*, **kwargs): return 1
SyntaxError: named arguments must follow bare * (<pyshell#10>, line 1)

I don't know if this is a bug or not but thought it worth querying. This
case does not seem to be mentioned in PEP 3102.

----------
components: Interpreter Core
messages: 65340
nosy: mark
severity: normal
status: open
title: inconsistency with bare * in parameter list
type: behavior
versions: Python 3.0

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

From report at bugs.python.org  Fri Apr 11 10:44:37 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Apr 2008 08:44:37 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207903477.53.0.976635983369.issue2607@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The slowdown is because of the garbage collector, which has more and
more objects to traverse (the tuples).
If I add "import gc; gc.disable()" at the beginning of your script, it
runs much faster, and the timings look linear.

Martin's sample is not affected, because there are very few
deallocations, and the gc collection is not triggered.

Disabling the gc may not be a good idea in a real application; I suggest
you to play with the gc.set_threshold function and set larger values, at
least while building the dictionary. (700, 1000, 10) seems to yield good
results.

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

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

From report at bugs.python.org  Fri Apr 11 10:47:39 2008
From: report at bugs.python.org (anatoly techtonik)
Date: Fri, 11 Apr 2008 08:47:39 +0000
Subject: [issue2614] Console UnicodeDecodeError s once more
In-Reply-To: <1207903659.28.0.871159161104.issue2614@psf.upfronthosting.co.za>
Message-ID: <1207903659.28.0.871159161104.issue2614@psf.upfronthosting.co.za>


New submission from anatoly techtonik <techtonik at gmail.com>:

Python debugging under console is a PITA, because it has a bad habit to
fail with UnicodeEncodeError in case of unknown encoding in output. It
quickly turns into a headache when inspecting methods like in the
following example running under windows:

>>> import active_directory
>>> users = active_directory.search ("objectCategory='Person'",
"objectClass='User'")
>>> u = users.next()
>>> u = users.next()
>>> u = users.next()
>>> u.dump()
LDAP://CN=L????????,CN=Users,DC=dom,DC=com
{
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "build\bdist.win32\egg\active_directory.py", line 495, in dump
  File "C:\Python25\lib\codecs.py", line 303, in write
    data, consumed = self.encode(object, self.errors)
  File "C:\Python25\lib\encodings\cp1251.py", line 12, in en
code
    return codecs.charmap_encode(input,errors,encoding_table)
UnicodeDecodeError: 'ascii' codec can't decode byte 0x84 in position 8:
ordinal
not in range(128)

Will this be fixed in Py3k to allow range(255) in case of unknown
encoding? Or will there be a new wrapper function - some
rawhexprint(...) that will temporary change sys.output encoding for the
time arguments are executed and process out of range symbols in output
stream according to its embedded rules (i.e. converting to hex
representaton). Another function can be supplied to write raw bytes to
console as-is. Raw write is preferable as it gives the possibility to
redirect output to a file and inspect it later.

These encoding issues in my POV is the stumbling block that makes
scripting in Python 2.x harder for non-english users and hampers overall
Python adoption. Is this going change in Py3k?

----------
components: Unicode, Windows
messages: 65342
nosy: techtonik
severity: normal
status: open
title: Console UnicodeDecodeError s once more
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Fri Apr 11 11:18:06 2008
From: report at bugs.python.org (Andreas Eisele)
Date: Fri, 11 Apr 2008 09:18:06 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207905486.39.0.420489897375.issue2607@psf.upfronthosting.co.za>


Andreas Eisele <eisele at dfki.de> added the comment:

Great, that really solves my problem.

Thank you so much, Amaury!

As you say, the problem is unrelated to dicts,
and I observe it also when including the tuples to
a set or keeping them in lists.
Perhaps your GC thresholds would be better default
values than what is currently in force.

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

From report at bugs.python.org  Fri Apr 11 11:22:31 2008
From: report at bugs.python.org (James Henstridge)
Date: Fri, 11 Apr 2008 09:22:31 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207905751.71.0.355875813218.issue2604@psf.upfronthosting.co.za>


James Henstridge <james at jamesh.id.au> added the comment:

If I create a test case with a command like:

   test = DocFileSuite('foo.txt', globs={'somelist': [42]})

The doctest isn't doing anything wrong if it modifies somelist.

Furthermore, Glyph has said he thinks the current --until-failure
behaviour in trial is a mistake: http://glyf.livejournal.com/72505.html

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

From report at bugs.python.org  Fri Apr 11 12:29:03 2008
From: report at bugs.python.org (Piet Delport)
Date: Fri, 11 Apr 2008 10:29:03 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207909743.8.0.199703687958.issue2604@psf.upfronthosting.co.za>


Piet Delport <pjdelport at gmail.com> added the comment:

Well, whether that code is wrong depends on whether your project policy
wants repeatable tests or not.  A repeatable and arguably more idiomatic
way of writing that example is to give DocFileSuite a setUp function
which initializes any special globals required by the test.

In any case, DocTestCase allowing non-repeatable tests (which i don't
think are common) is no reason to disallow repeatable tests, which e.g.
at least Zope considers important enough to motivate fixing this issue.
 (Zope is also the source of the code being fixed, if i'm not mistaken.)

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

From report at bugs.python.org  Fri Apr 11 13:13:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Apr 2008 11:13:44 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1207912424.55.0.870472363744.issue2604@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

FWIW, the python testsuite needs repeatable tests, when running in
"reference leaks" mode.

See also r62100, where a DocTestSuite construction had to be moved into
the repeated function.

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

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

From report at bugs.python.org  Fri Apr 11 13:19:49 2008
From: report at bugs.python.org (Jeroen Ruigrok van der Werven)
Date: Fri, 11 Apr 2008 11:19:49 +0000
Subject: [issue2615] xml.dom.minidom documentation consistency and update
In-Reply-To: <1207912789.81.0.894453276302.issue2615@psf.upfronthosting.co.za>
Message-ID: <1207912789.81.0.894453276302.issue2615@psf.upfronthosting.co.za>


New submission from Jeroen Ruigrok van der Werven <asmodai at in-nomine.org>:

xml.dom.minidom details three methods: writexml(), toxml(),
toprettyxml(). Only one, toxml(), showed the optional encoding argument.
In the documentation for writexml() the encoding argument is explained,
but toprettyxml() refers to toxml() for the details, which are not
present there.

----------
assignee: georg.brandl
components: Documentation
files: minidom.diff
keywords: patch
messages: 65347
nosy: asmodai, georg.brandl
severity: normal
status: open
title: xml.dom.minidom documentation consistency and update
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10004/minidom.diff

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

From report at bugs.python.org  Fri Apr 11 13:21:44 2008
From: report at bugs.python.org (Michael Amrhein)
Date: Fri, 11 Apr 2008 11:21:44 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1207912904.71.0.320621492227.issue1738@psf.upfronthosting.co.za>


Michael Amrhein <mamrhein at users.sourceforge.net> added the comment:

I've implemented an enhanced version of this feature by adding a keyword
'match' to the constructor of class 'dircmp'. It defaults to function
'fnmatch' imported from module 'fnmatch'.
This allows to exclude directories and/or files by using patterns like
'*.tmp'.
By giving a different function it's also possible to use more elaborated
patterns, for example, based on regular expressions.
Attached patch includes updates of documentation and test cases.

----------
nosy: +mamrhein
versions: +Python 2.6
Added file: http://bugs.python.org/file10005/wildcard.patch

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

From report at bugs.python.org  Fri Apr 11 13:57:18 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Apr 2008 11:57:18 +0000
Subject: [issue2612] file.tell() returns Long usually, Int if subclassed
In-Reply-To: <1207881915.59.0.417748346236.issue2612@psf.upfronthosting.co.za>
Message-ID: <1207915038.54.0.459230804764.issue2612@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

The documentation is still not very good about documenting the
differences between new and old style classes. Perhaps this is something
which could go under the __len__ entry in "Special Method Names."

----------
nosy: +georg.brandl

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

From report at bugs.python.org  Fri Apr 11 15:52:40 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 11 Apr 2008 13:52:40 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207921960.36.0.448085342453.issue2610@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

Here is a new patch file.  This one contains the modifications to 
rangeobject.c as well as test_range.py

I think this is everything.  If there is something else I need to do 
please let me know.  I looked to see if there was any documentation I 
could or should change for this but did not find any.

Thanks again for your help.

Added file: http://bugs.python.org/file10006/range_str_comb.patch

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

From report at bugs.python.org  Fri Apr 11 16:00:40 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 14:00:40 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1207922440.19.0.651874342164.issue1738@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

+1 on adding the match argument.  Can you comment on how one would 
implement the old behavior? I would guess match=lambda x,y: x in y, 
which is not that bad, but maybe that should be the default and those 
who need pattern matching should use match=fnmatch.

On the patch itself, please don't change default arguments from None to 
lists or function.  There is a subtle difference between the two forms. 
For example, in your code if someone overrides filecmp.fnmatch before 
calling dircmp, old fnmatch will still be used.  If you do match=None in  
finction declaration and match is None check in the function body, then 
the new overridden value will be used in the above scenario.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Apr 11 16:15:09 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Durigan_J=C3=BAnior?=)
Date: Fri, 11 Apr 2008 14:15:09 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1207923309.2.0.187612625934.issue1628484@psf.upfronthosting.co.za>


S?rgio Durigan J?nior <sergiodj at linux.vnet.ibm.com> added the comment:

Hi Martin,

Actually, I know that you can use CC to do it, but IMHO that's not the
correct approach. I understand too you concern about adding @CFLAGS@,
but I think the user should be able to define his/her own CFLAGS, and
this is not implemented yet. Do you agree with that?

Regards.

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

From report at bugs.python.org  Fri Apr 11 16:18:59 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 14:18:59 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207923539.16.0.730504479261.issue2610@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

-1

I don't think <0, 1, ..., 9> is much clearer than range(0, 10).  The 
only problem students may have is that 10 not in range(0, 10), but this 
can be learned very quickly.  The <..> repr breaks x == eval(repr(x)) 
invariant which is actually important in some of my code. Furthermore, 
the proposed <..> representation suggests that the range object contains 
the integers, which is not true.  While eval/repr round-tripping may not 
be important for the majority of applications, it is a nice feature for 
any interactive work including education.  Finally, I think introducing 
students to list(range(..))/tuple(range(..)) idioms early is a good 
thing. The sooner they learn that list/tuple are real containers while 
ranges, dict key/values etc. are not the better.

----------
nosy: +belopolsky

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

From report at bugs.python.org  Fri Apr 11 16:45:49 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 11 Apr 2008 14:45:49 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207925149.52.0.992474864376.issue2610@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

The patch does not change the behavior of repr.  It modifies the 
behavior of str.

I agree that learning list/tuple sooner is better, but students who have 
never written a line of code before can only absorb so much information, 
this little patch allows them to print(range(100,0,-1)) and get a much 
better intuition about what is happening.

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

From report at bugs.python.org  Fri Apr 11 16:47:07 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 14:47:07 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207925227.62.0.397701834263.issue2610@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I did not realize that the proposed patch only affects str and not repr.  
Some of may previous arguments against it do not hold in this case, but 
I am still -1.

If you introduce range before list, it will be hard to explain why lists 
are printed in valid python syntax while ranges are not.

What do you do with ranges in your first classes?  Maybe you can 
introduce it as a part of the looping construct and make students think 
of for i in range(10) as an equivalent of C's for(i = 0; i < 10; i++)?

Also

>>> [i for i in range(10)]
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

can be demonstrated early without explaining the mechanics of list 
comprehensions.  I would expect most students being able to guess what 
for i in range(10): does and half of the students being able to guess 
what [i for i in range(10)] means.

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

From report at bugs.python.org  Fri Apr 11 16:52:15 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Apr 2008 14:52:15 +0000
Subject: [issue2616] ctypes.pointer(), ctypes.POINTER() speedup
In-Reply-To: <1207925534.93.0.923711950169.issue2616@psf.upfronthosting.co.za>
Message-ID: <1207925534.93.0.923711950169.issue2616@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements the POINTER() and the pointer() function in C;
giving a speedup of roughly a factor of 2.

----------
assignee: theller
components: ctypes
files: ctypes-pointer.diff
keywords: patch, patch
messages: 65356
nosy: theller
severity: normal
status: open
title: ctypes.pointer(), ctypes.POINTER() speedup
type: performance
versions: Python 2.6
Added file: http://bugs.python.org/file10007/ctypes-pointer.diff

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

From report at bugs.python.org  Fri Apr 11 17:24:10 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 15:24:10 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207927449.99.0.638411437572.issue2610@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like our messages have crossed in flight.

> this little patch allows them to print(range(100,0,-1))
> and get a much better intuition about what is happening.

This is a really bad example.  Why would you want to introduce the print 
function in the first class?  You can explain much of the language using 
python as an advanced calculator without introducing any IO.  
Furthermore, given that print changes from being a statement to being a 
function in 3.0, it will be a much less novice friendly construct for 
years to come.  Also range(100, 0, -1) is not the most shining example 
of python's clarity. :-)

I think the best idea for educators would be to limit introductory 
material to 2.x - 3.x portable constructs.  This means avoid using 
range(..) outside of looping constructs, don't use print before you have  
to (and then use a subset of 3.x syntax.)

BTW, you really only need to use print function when you start writing 
scripts and that is better avoided in the first class when you have 
interactive environment as you do with python.

As a side remark, you may find the following trick useful in the first 
class:

>>> range(10)
range(0, 10)
>>> list(_)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

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

From report at bugs.python.org  Fri Apr 11 18:06:26 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 11 Apr 2008 16:06:26 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207929986.66.0.14765359158.issue2610@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

Our use of range in the first few classes is exactly for iteration 
purposes, but I do not like students to have to have too many mysteries.  
So I always have liked to show that range(10) simply produces a sequence 
of integers.  In Python 3.0 range returns a mysterious iteration object.  
No thanks.  My proposal was to provide a more user friendly 
implementation of the str method for this new range object that would 
allow the user to see the sequence.  I like Python because it is so easy 
to start up a shell and poke around and see what things are.

I have no problem, introducing list(range(10)) in week 3 when I start 
talking about lists, and I like list comprehensions of that purpose too.

Again, what I do not like is that things that used to be very easy for 
students to get a conceptual handle on are now more difficult in 3.0.
- range is one example the dict_keys and dict_values objects are another 
example.  dict_keys et. al. are much easier to deal with since I've 
already covered lists and the list() function by the time I get there.

BTW, I think  we must have very different teaching styles as I would 
never introduce something as mysterious as list(_) on the first day of 
class.  I'd be happy to continue our discussion of teaching philosophy 
but I doubt that this is the right forum.

Brad

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

From report at bugs.python.org  Fri Apr 11 18:10:49 2008
From: report at bugs.python.org (Michael Amrhein)
Date: Fri, 11 Apr 2008 16:10:49 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1207930249.81.0.0967369895117.issue1738@psf.upfronthosting.co.za>


Michael Amrhein <mamrhein at users.sourceforge.net> added the comment:

Ok, I've set default arguments (back) to None. Revised patch attached.

Defaulting the match function to fnmatch doesn't change the behavior in
the "normal" case, i.e. when regular file / directory names are used,
like in the default value of ignore. It behaves different in two cases:
a) A string given in ignore contains wildcard character(s):
In this case this parameter would have no effect in the previous
implementation, because the string would not match any file / directory
name exactly. In the changed implementation all files / directories
matching the pattern would be ignored. If the wildcard(s) were included
by intent, this is what probably was intended; if they were included by
mistake, both version do not behave as intended.
b) File system is case-insensitive:
In this case the changed implementation will ignore files / directories
which the previous version did not ignore because of a case mismatch.
But, on such a file system this is what one would normally expect, I think.
So, in both cases, I feel the changed behavior is acceptable.
Or did I miss something?

Added file: http://bugs.python.org/file10008/add_match_func.patch

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

From report at bugs.python.org  Fri Apr 11 18:30:32 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 16:30:32 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1207930249.81.0.0967369895117.issue1738@psf.upfronthosting.co.za>
Message-ID: <d38f5330804110930y47b40759gb1eecb4708b73037@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 11, 2008 at 12:10 PM, Michael Amrhein
<report at bugs.python.org> wrote:
>
..
>  a) A string given in ignore contains wildcard character(s):
>  In this case this parameter would have no effect in the previous
>  implementation, because the string would not match any file / directory
>  name exactly.

'*' is a perfectly legal filename character on most filesystems

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

From report at bugs.python.org  Fri Apr 11 18:43:43 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 11 Apr 2008 16:43:43 +0000
Subject: [issue2559] atom sorting error when building ctypes
In-Reply-To: <1207423627.95.0.288324472301.issue2559@psf.upfronthosting.co.za>
Message-ID: <1207932223.79.0.472223042402.issue2559@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

I see this also, on Leopard x86. The linker error is not printed on
Tiger PPC.  At least, the ctypes test suite does work ok so it may be
that it can be ignored.

Googling for this error, I find that it may be related to linker changes
that Apple has made.
One suggestion I found was to link with ld_classic instead of ld;
another was to pass the -dynamic flag instead of -bundle.  However, I do
not known how this can be done in setup.py.

The libffi sources in Python svn were copied from the PyObjC sources;
maybe Ronald has a clue?

----------
nosy: +ronaldoussoren
title: atom sorting error when buiding ctypes -> atom sorting error when building ctypes

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

From report at bugs.python.org  Fri Apr 11 19:16:25 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 17:16:25 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207929986.66.0.14765359158.issue2610@psf.upfronthosting.co.za>
Message-ID: <d38f5330804111016u47564b9cs90796ec5976c28c4@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 11, 2008 at 12:06 PM, Brad Miller <report at bugs.python.org> wrote:

>  Our use of range in the first few classes is exactly for iteration
>  purposes, but I do not like students to have to have too many mysteries.
>  So I always have liked to show that range(10) simply produces a sequence

.. but it does not in 3.x and your patch does not change that.
Instead, range(10) produces range(0,10) and I don't see anything
mysterious here.

>  of integers.  In Python 3.0 range returns a mysterious iteration object.
>  No thanks.  My proposal was to provide a more user friendly
>  implementation of the str method for this new range object that would
>  allow the user to see the sequence.  I like Python because it is so easy
>  to start up a shell and poke around and see what things are.
>

Maybe you should try it with some of your students first.  Note that
you can customize the way results are printed on the console with
sys.displayhook.   I fail to see how <0, 1, ... 9> is less mysterious
than range(0,10), particularly combined with the fact that print
representation is different from console display.  I think <0, 1, ...
9> will confuse more students than it will help.

>  I have no problem, introducing list(range(10)) in week 3 when I start
>  talking about lists, and I like list comprehensions of that purpose too.
>

Why would you want to talk about loops before talking about lists?
Python is not C.  In many cases for x in some_list or for i,x in
enumerate(some_list) is a better construct than for i in range(..).

>  Again, what I do not like is that things that used to be very easy for
>  students to get a conceptual handle on are now more difficult in 3.0.

With your proposed <..> display students will be getting a wrong
concept, thinking that <1, 2, 3> is yet another container in addition
to (1,2,3), [1,2,3] and {1,2,3}.

>  - range is one example the dict_keys and dict_values objects are another
>  example.  dict_keys et. al. are much easier to deal with since I've
>  already covered lists and the list() function by the time I get there.
>

IMHO list function is simpler than the print function, particularly in
cases when it does not print what you enter.

>  BTW, I think  we must have very different teaching styles as I would
>  never introduce something as mysterious as list(_) on the first day of
>  class.  I'd be happy to continue our discussion of teaching philosophy
>  but I doubt that this is the right forum.
>

Your students are probably older than mine.  I don't teach, but I
introduced my son to python when he was 10.  He is 12 now and is quite
comfortable using python as a calculator (computing 2**1000 in python
what quite an experience!)  Explaining that _ stands for the value
that just printed was easier than introducing variables (as in
x=range(10); list(x)).

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

From report at bugs.python.org  Fri Apr 11 20:38:29 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 18:38:29 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1207939109.02.0.413312891535.issue1738@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

As you are working on this, please consider changing
self.hide+self.ignore in phase0 to chain(self.hide, self.ignore) where
chain should be imported from itertools. There is no need to create the
combined list (twice!) and not accepting arbitrary iterables for hide
and ignore seems to be against the zen of python.

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

From report at bugs.python.org  Fri Apr 11 20:45:23 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 11 Apr 2008 18:45:23 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207939523.09.0.0786945177829.issue2610@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

Clearly neither Alexander nor I are going to get the other to come 
around to our point of view.  Thats fine, I think we can disagree here, 
and I can adapt and change my class either way.

My question is how does this get resolved.  When I posted this idea to 
python-dev Guido suggested an approach. Nobody else expressed an opinion 
so after waiting a few days I took Guido's suggestion and implemented a 
patch.  Now there are objections.

Other than some mild frustration at having invested a fair amount of 
time in producing my first python patch, I am also in the middle of 
editing a textbook that will come out this fall.  my intention is to 
have this book be 3.0 compatible.  So it would be nice for me to have 
some clarity on the direction this will go.

Thanks,

Brad

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

From report at bugs.python.org  Fri Apr 11 20:48:30 2008
From: report at bugs.python.org (Frank Wierzbicki)
Date: Fri, 11 Apr 2008 18:48:30 +0000
Subject: [issue2617] Patch to emit "-J is reserved for Jython" on -J arg
In-Reply-To: <1207939710.11.0.248757051095.issue2617@psf.upfronthosting.co.za>
Message-ID: <1207939710.11.0.248757051095.issue2617@psf.upfronthosting.co.za>


New submission from Frank Wierzbicki <fwierzbicki at gmail.com>:

This patch adds the message "-J is reserved for Jython" if that arg is
attempted.  See
http://mail.python.org/pipermail/python-dev/2008-April/078564.html

For support from BDFL.

----------
components: Interpreter Core
files: argdashjay.diff
keywords: patch
messages: 65365
nosy: fwierzbicki
severity: normal
status: open
title: Patch to emit "-J is reserved for Jython" on -J arg
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10009/argdashjay.diff

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

From report at bugs.python.org  Fri Apr 11 21:14:43 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 11 Apr 2008 19:14:43 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207939523.09.0.0786945177829.issue2610@psf.upfronthosting.co.za>
Message-ID: <d38f5330804111214p5769a31v58e28e5c49379c04@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 11, 2008 at 2:45 PM, Brad Miller <report at bugs.python.org> wrote:
..
>  My question is how does this get resolved.  When I posted this idea to
>  python-dev Guido suggested an approach. Nobody else expressed an opinion
>  so after waiting a few days I took Guido's suggestion and implemented a
>  patch.  Now there are objections.
>

My -1 vote is not a veto by any means.  It us ultimately up to Guido
to accept or reject your patch.  I am actually willing to change my
vote to -0.  I cannot recall ever using either str(..) or print on a
range object, so this change will not affect me while I still believe
it will not solve your problem either.

>  Other than some mild frustration at having invested a fair amount of
>  time in producing my first python patch

This happens a lot.  Oftentimes proposals are not even considered
without a working patch.  I hope writing the patch and receiving
Martin's comments on your code was a valuable experience in itself
even if your patch does not get accepted.

> I am also in the middle of
>  editing a textbook that will come out this fall.  my intention is to
>  have this book be 3.0 compatible.  So it would be nice for me to have
>  some clarity on the direction this will go.

I would suggest considering a custom displayhook approach. You can
write a custom displayhook that will print range(..), {}.keys(),
{}.values() etc in a student-friendly way.   I believe a module
installing such display hook can be included in the standard library.
In addition to iterable's display problem such a hook can limit the
amount of output when displaying long lists, insert smart line breaks
etc.  For a textbook, you can instruct the readers to download your
code and import a custom module before trying the examples.  This is
likely to make your textbook more future-proof because you will be
able to update your displayhook code as python changes.

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

From report at bugs.python.org  Fri Apr 11 21:44:00 2008
From: report at bugs.python.org (Kevin Walzer)
Date: Fri, 11 Apr 2008 19:44:00 +0000
Subject: [issue2618] Tile module: Add support for themed widgets
In-Reply-To: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>
Message-ID: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>


New submission from Kevin Walzer <wordtech at users.sourceforge.net>:

The Tile module adds support for the platform-native themed widgets now 
available in Tk 8.5's core (ttk:: namespace in Tk terms). The module 
also supports the ttk:: namespace for Tk 8.4 if a separate Tk extension 
is installed. Adding this module to the core lib-tk library will make it 
simple for Tkinter developers to access the improved, modern widget set 
now available.

The module was originally developed by Martin Franklin. I have updated 
and maintained it for the past two years. Martin Franklin has granted me 
permission to submit it for inclusion in the lib-tk core; documentation 
available on request.

----------
components: Tkinter
files: Tile.py
messages: 65367
nosy: wordtech
severity: normal
status: open
title: Tile module: Add support for themed widgets
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10010/Tile.py

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

From report at bugs.python.org  Fri Apr 11 21:49:01 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Durigan_J=C3=BAnior?=)
Date: Fri, 11 Apr 2008 19:49:01 +0000
Subject: [issue858809] Use directories from configure rather than hardcoded
Message-ID: <1207943341.44.0.633730120088.issue858809@psf.upfronthosting.co.za>


S?rgio Durigan J?nior <sergiodj at linux.vnet.ibm.com> added the comment:

Hi,

Continuing with my effort to improve Python's build system, I'd really
like to know why this issue has not been solved yet. I mean, apparently
this problem is still present in Python 2.5, since I can't change the
library's path with --libdir configure's flag. Any news about it?

----------
nosy: +sergiodj

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

From report at bugs.python.org  Fri Apr 11 22:40:46 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 11 Apr 2008 20:40:46 +0000
Subject: [issue2618] Tile module: Add support for themed widgets
In-Reply-To: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>
Message-ID: <1207946446.87.0.594390098439.issue2618@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Is this complete ? I see several methods with just a pass, where the
docstring says it returns a dict, for example.

----------
nosy: +gpolo

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

From report at bugs.python.org  Fri Apr 11 22:46:58 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Apr 2008 20:46:58 +0000
Subject: [issue2619] Document memoryview
In-Reply-To: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>
Message-ID: <1207946818.06.0.901333881861.issue2619@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

memoryview documentation is currently nonexistent.

----------
assignee: georg.brandl
components: Documentation
messages: 65370
nosy: benjamin.peterson, georg.brandl
priority: critical
severity: normal
status: open
title: Document memoryview
type: feature request
versions: Python 3.0

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

From report at bugs.python.org  Fri Apr 11 22:53:21 2008
From: report at bugs.python.org (Brad Miller)
Date: Fri, 11 Apr 2008 20:53:21 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207947201.62.0.684106177687.issue2610@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

> I would suggest considering a custom displayhook approach. You can
> write a custom displayhook that will print range(..), {}.keys(),
> {}.values() etc in a student-friendly way.   I believe a module
> installing such display hook can be included in the standard library.
> In addition to iterable's display problem such a hook can limit the
> amount of output when displaying long lists, insert smart line breaks
> etc.  For a textbook, you can instruct the readers to download your
> code and import a custom module before trying the examples.  This is
> likely to make your textbook more future-proof because you will be
> able to update your displayhook code as python changes.

That is an interesting idea!  I just hacked together a quick prototype.  
I'll discuss this with my co-author.  Its a fine line between using 
'real'
Python and providing an appropriate level of help for the beginner.  We
have tried to minimize the number of additional modules and 
dependencies, so
if there was a hook like this as part of the standard library that would 
be
great.

Brad

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

From report at bugs.python.org  Fri Apr 11 22:56:05 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 11 Apr 2008 20:56:05 +0000
Subject: [issue2559] atom sorting error when building ctypes
In-Reply-To: <1207423627.95.0.288324472301.issue2559@psf.upfronthosting.co.za>
Message-ID: <1207947365.63.0.0361812047364.issue2559@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

I'm pretty sure I get the same error when building PyObjC. It seems to be 
a harmless warning though, PyObjC passes all its unittests and those 
really exercise all of libffi.

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

From report at bugs.python.org  Fri Apr 11 23:06:44 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 11 Apr 2008 21:06:44 +0000
Subject: [issue2590] S_unpack_from() Read Access Violation
In-Reply-To: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>
Message-ID: <1207948004.6.0.948816428107.issue2590@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What do you mean by "obscene" values? Do you have an example of actual
values where the check at line 1561 does not do the right thing?

-- just trying to understand where the problem is.

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

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

From report at bugs.python.org  Fri Apr 11 23:18:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 11 Apr 2008 21:18:19 +0000
Subject: [issue2618] Tile module: Add support for themed widgets
In-Reply-To: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>
Message-ID: <1207948699.14.0.0989305772307.issue2618@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
components: +Library (Lib)
type: behavior -> feature request

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

From report at bugs.python.org  Fri Apr 11 23:27:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Apr 2008 21:27:29 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207905486.39.0.420489897375.issue2607@psf.upfronthosting.co.za>
Message-ID: <47FFD7BE.4010403@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Perhaps your GC thresholds would be better default
> values than what is currently in force.

No, the defaults are correct for typical applications.

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

From report at bugs.python.org  Fri Apr 11 23:31:52 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Apr 2008 21:31:52 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1207923309.2.0.187612625934.issue1628484@psf.upfronthosting.co.za>
Message-ID: <47FFD8C4.8000809@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Actually, I know that you can use CC to do it, but IMHO that's not the
> correct approach. I understand too you concern about adding @CFLAGS@,
> but I think the user should be able to define his/her own CFLAGS, and
> this is not implemented yet. Do you agree with that?

No, I don't agree this is not implemented. The user can set CC,
BASECFLAGS, and OPT, all of them contributing the CFLAGS.

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

From report at bugs.python.org  Fri Apr 11 23:33:25 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Apr 2008 21:33:25 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207923539.16.0.730504479261.issue2610@psf.upfronthosting.co.za>
Message-ID: <47FFD923.2090007@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I don't think <0, 1, ..., 9> is much clearer than range(0, 10).  The 
> only problem students may have is that 10 not in range(0, 10), but this 
> can be learned very quickly.  The <..> repr breaks x == eval(repr(x)) 
> invariant which is actually important in some of my code.

I think you misunderstand the patch. It doesn't affect repr() at all.

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

From report at bugs.python.org  Fri Apr 11 23:43:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Apr 2008 21:43:53 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207939523.09.0.0786945177829.issue2610@psf.upfronthosting.co.za>
Message-ID: <47FFDB96.2090802@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Now there are objections.
> 
> Other than some mild frustration at having invested a fair amount of 
> time in producing my first python patch, I am also in the middle of 
> editing a textbook that will come out this fall.

Don't be frustrated. This is a regular thing to happen; sometimes,
opposition won't form until the code is committed and released in
an alpha release.

> So it would be nice for me to have 
> some clarity on the direction this will go.

We should wait a few more days for people to speak up.

Myself, I'm -0 on the patch. The '<' syntax is awkward.

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

From report at bugs.python.org  Fri Apr 11 23:47:07 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 11 Apr 2008 21:47:07 +0000
Subject: [issue2618] Tile module: Add support for themed widgets
In-Reply-To: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>
Message-ID: <1207950427.28.0.765938781759.issue2618@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Kevin, is this all your code (the comment seems to suggest otherwise).

Can all authors fill out contributor agreements?

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

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

From report at bugs.python.org  Sat Apr 12 00:35:38 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Fri, 11 Apr 2008 22:35:38 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>


New submission from Justin Ferguson <justin.ferguson at ioactive.com>:

174 static
 175 int unicode_resize(register PyUnicodeObject *unicode,
 176                       Py_ssize_t length)
 177 {
 [...]
 201 
 202     oldstr = unicode->str;
 203     PyMem_RESIZE(unicode->str, Py_UNICODE, length + 1);
[...]
 209     unicode->str[length] = 0;
 210     unicode->length = length;
 211  

 95 #define PyMem_RESIZE(p, type, n) \
 96   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 97         ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )

The unicode_resize() function acts essentially as a wrapper to
realloc(), it accomplishes this via the PyMem_RESIZE() macro which
factors the size with the size of the type, in this case it multiplies
by two as Py_UNICODE is typedef'd to a wchar_t. When resizing large
strings, this results in an incorrect allocation that in turn leads to
buffer overflow.

This is specific to the Unicode objects, however I would not be
surprised to see that other types have this complication as well. Please
see attached proof of concepts.

----------
components: Interpreter Core
files: python-2.5.2-unicode_resize-utf7.py
messages: 65379
nosy: jnferguson
severity: normal
status: open
title: Multiple buffer overflows in unicode processing
type: security
versions: Python 2.5
Added file: http://bugs.python.org/file10011/python-2.5.2-unicode_resize-utf7.py

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

From report at bugs.python.org  Sat Apr 12 00:35:51 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Fri, 11 Apr 2008 22:35:51 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207953351.79.0.849321524155.issue2620@psf.upfronthosting.co.za>


Changes by Justin Ferguson <justin.ferguson at ioactive.com>:


Added file: http://bugs.python.org/file10012/python-2.5.2-unicode_resize-utf8.py

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

From report at bugs.python.org  Sat Apr 12 00:36:03 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Fri, 11 Apr 2008 22:36:03 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207953363.3.0.719887794974.issue2620@psf.upfronthosting.co.za>


Changes by Justin Ferguson <justin.ferguson at ioactive.com>:


Added file: http://bugs.python.org/file10013/python-2.5.2-unicode_resize-utf16.py

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

From report at bugs.python.org  Sat Apr 12 00:40:12 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Fri, 11 Apr 2008 22:40:12 +0000
Subject: [issue2590] S_unpack_from() Read Access Violation
In-Reply-To: <1207670974.93.0.212511655132.issue2590@psf.upfronthosting.co.za>
Message-ID: <1207953612.61.0.452453632368.issue2590@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

What I was originally thinking was if offset was larger than buf_len,
that would cause the check at 1561 to fail due to the subtraction. That
said, I'm not sure what type its being compared against so I need to
check this further, let me get back to you, I may have made a mistake
and this may be !bug.

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

From report at bugs.python.org  Sat Apr 12 00:42:16 2008
From: report at bugs.python.org (Kevin Walzer)
Date: Fri, 11 Apr 2008 22:42:16 +0000
Subject: [issue2618] Tile module: Add support for themed widgets
In-Reply-To: <1207943040.06.0.54693474861.issue2618@psf.upfronthosting.co.za>
Message-ID: <1207953736.11.0.244869120322.issue2618@psf.upfronthosting.co.za>


Kevin Walzer <wordtech at users.sourceforge.net> added the comment:

No, it is not all my code. I will contact Martin Franklin about filling 
out contributors agreement.

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

From report at bugs.python.org  Sat Apr 12 01:29:30 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 11 Apr 2008 23:29:30 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207956570.0.0.734398122695.issue2620@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

You are probably referring to 32-bit platforms. At least on 64-bit
platforms, there's no problem with your test cases:

>>> # this is to get the unicode_freelist initialized
... # the length of the string must be <= 9 to keep
... # unicode->str from being deallocated and set to
... # NULL
... bla = unicode('IOActive')
>>> del bla
>>>
>>>
>>> msg = 'A'*2147483647
>>>
>>> msg.decode('utf7')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
MemoryError

The code does check for success of the realloc():

    PyMem_RESIZE(unicode->str, Py_UNICODE, length + 1);
    if (!unicode->str) {
	unicode->str = (Py_UNICODE *)oldstr;
        PyErr_NoMemory();
        return -1;
    }

Are you after the integer overflow and the fact that realloc() would (if
possible) allocate a buffer smaller than needed ?

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

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

From report at bugs.python.org  Sat Apr 12 01:44:43 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 11 Apr 2008 23:44:43 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1207957483.87.0.167403491235.issue2610@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

FWIW, I would like to see a newsgroup or python-dev discussion for a 
more general solution to the problem for helpful repr's for iterators.  
In 3.0, lots of things return iterators, not just range().  

Before applying one ad-hoc patch, it would be helpful to think through 
how the issue should be handled across the whole language.  For 
example, perhaps pprint() should display general iterators with the 
<...> notation.  

For teaching and experimentation purposes, maybe the right answer is 
the make the command-line a bit smarter.  It already knows how to 
suppress None return values.  Perhaps, it should be taught how to 
display range objects and dict.items() and such.

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

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

From report at bugs.python.org  Sat Apr 12 02:20:36 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Sat, 12 Apr 2008 00:20:36 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207959635.79.0.729988867876.issue2620@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Yes, excuse me-- this should be 32-bit specific as I believe Python will
not let me get a string long enough to overflow the integer on 64-bit.
It's a big string, the only realistic scenario I can see is XML parsing
or similar.

theory$ ./python -V
Python 2.5.2
theory$ cat /proc/cpuinfo | grep -i model
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
theory$ ./python python-2.5.2-unicode_resize-utf7.py
Segmentation fault

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

From report at bugs.python.org  Sat Apr 12 02:32:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 00:32:26 +0000
Subject: [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

I used some brute force search and replace for this and it worked quite
well. If this patch is accepted, I'll fix the docs.

----------
components: Tests
files: rename_test_support.patch
keywords: easy, patch
messages: 65385
nosy: benjamin.peterson, brett.cannon, georg.brandl
severity: normal
status: open
title: rename test_support to support
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10014/rename_test_support.patch

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

From report at bugs.python.org  Sat Apr 12 02:56:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 00:56:34 +0000
Subject: [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1207961794.01.0.724139436047.issue2621@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file10015/rename_test_support2.patch

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

From report at bugs.python.org  Sat Apr 12 05:26:52 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Apr 2008 03:26:52 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207970812.73.0.638997726931.issue2620@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Note that in r61458 Neal replaced PyMem_RESIZE with a direct call to PyMem_REALLOC thus eliminating integer overflow check even from the debug 
builds.

----------
nosy: +belopolsky, nnorwitz

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

From report at bugs.python.org  Sat Apr 12 05:42:11 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Apr 2008 03:42:11 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207971731.37.0.996386025234.issue2620@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Justin,

Where did you find the definition that you cited:

 95 #define PyMem_RESIZE(p, type, n) \
 96   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 97         ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )

?

Current Include/pymem.h does not have the assert:

     94 #define PyMem_RESIZE(p, type, n) \
     95         ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) 
)

and it did not change for a while.

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

From report at bugs.python.org  Sat Apr 12 05:55:42 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Apr 2008 03:55:42 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207972542.72.0.463751418885.issue2620@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith
priority:  -> high
versions: +Python 2.4

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

From report at bugs.python.org  Sat Apr 12 06:01:44 2008
From: report at bugs.python.org (Andreas Eisele)
Date: Sat, 12 Apr 2008 04:01:44 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <47FFD7BE.4010403@v.loewis.de>
Message-ID: <4800347C.4020700@dfki.de>


Andreas Eisele <eisele at dfki.de> added the comment:

Even if they mean that creation
of a huge number N of objects
requires O(N*N) effort?

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

From report at bugs.python.org  Sat Apr 12 06:18:46 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 12 Apr 2008 04:18:46 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207973926.69.0.239190393781.issue2620@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The following simple change should be enough for this issue, but I would 
consider implementing the overflow check in the PyMem_RESIZE and PyMem_NEW macros and de-deprecate their use.

===================================================================
--- Objects/unicodeobject.c     (revision 62237)
+++ Objects/unicodeobject.c     (working copy)
@@ -261,8 +261,8 @@
        it contains). */
 
     oldstr = unicode->str;
-    unicode->str = PyObject_REALLOC(unicode->str,
-                                   sizeof(Py_UNICODE) * (length + 1));
+    unicode->str = SIZE_MAX/sizeof(Py_UNICODE) - 1 < length ? NULL :
+        PyObject_REALLOC(unicode->str, sizeof(Py_UNICODE) * (length + 
1));
     if (!unicode->str) {
        unicode->str = (Py_UNICODE *)oldstr;
         PyErr_NoMemory();

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

From report at bugs.python.org  Sat Apr 12 06:20:20 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Sat, 12 Apr 2008 04:20:20 +0000
Subject: [issue2607] why is (default)dict so slow on tuples???
In-Reply-To: <1207844501.86.0.649423716831.issue2607@psf.upfronthosting.co.za>
Message-ID: <1207974020.11.0.207991003677.issue2607@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

This discussion ought to be moved to comp.lang.python.  The timing 
script needs work.  It doesn't isolate any one issue for discussion.  
It is affected by GC, dict resizing, details of creating and hashing 
string objects, the need to periodically call the system malloc, etc. 

You get different results if:
* a new dictionary is created on each pass
* if any of the objects get reused
* if range(5) gets replaces with [0]*5
* if you use longs instead of ints
* if the strings are of fixed length:  str(j)[:5]

This is the wrong forum to explain every nuance of what affects 
performance and whether you think perl is better.

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

From report at bugs.python.org  Sat Apr 12 07:37:53 2008
From: report at bugs.python.org (John Jackson)
Date: Sat, 12 Apr 2008 05:37:53 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>


New submission from John Jackson <johnjackson at pobox.com>:

In email.message.py there are two import errors:
line 128 from email.Generator import Generator
should be 
  from email.generator import Generator
line 784 from email.Iterators import walk
should be 
  from email.iterators import walk

----------
components: Library (Lib)
messages: 65391
nosy: JohnJackson
severity: normal
status: open
title: Import errors in email.message.py
type: crash
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 12 07:38:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 12 Apr 2008 05:38:16 +0000
Subject: [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1207978696.6.0.579726908069.issue2621@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What's the rationale for this change?

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

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

From report at bugs.python.org  Sat Apr 12 08:04:21 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Sat, 12 Apr 2008 06:04:21 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207980261.67.0.774748874265.issue2620@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

i pulled the Macros out of pymem.h in a Vanille 2.5.2?

----------
components: +None
versions: +Python 3.0

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

From report at bugs.python.org  Sat Apr 12 08:11:49 2008
From: report at bugs.python.org (Leonard Clark)
Date: Sat, 12 Apr 2008 06:11:49 +0000
Subject: [issue2623] Patch: xmlrpclib client ignores datetime tzinfo when
	creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>


New submission from Leonard Clark <lclark at 2bdx.net>:

xmlrpclib ignores datetime parameter timezone information.  Two spots
were identified to apply a new formatting function, _iso8601format, to
ensure that the timezone is passed to the server.

I would like this fix to be included in future releases. (Thank you!)

----------
components: XML
files: xmlrpclib-timezone.patch
keywords: patch
messages: 65394
nosy: lclark
severity: normal
status: open
title: Patch: xmlrpclib client ignores datetime tzinfo when creating iso8601 dates
type: behavior
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10016/xmlrpclib-timezone.patch

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

From report at bugs.python.org  Sat Apr 12 08:16:06 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Sat, 12 Apr 2008 06:16:06 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207980966.86.0.529134570414.issue2620@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

sorry didnt mean to change components and version-- I'm typing this from 
my phone and its being uncooperative at the moment

----------
components: +Library (Lib)

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

From report at bugs.python.org  Sat Apr 12 10:34:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Apr 2008 08:34:45 +0000
Subject: [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1207989285.72.0.705079909063.issue2621@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It would be nice if all test.test_foo modules were real tests.

I know this is on the stdlib-sig's list of changes for 3.0; I don't
think we should do the rename in 2.x.

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

From report at bugs.python.org  Sat Apr 12 12:54:58 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Sat, 12 Apr 2008 10:54:58 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1207997698.53.0.0897638443459.issue2620@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

just fixing the modifications my phone made earlier tonight

----------
components:  -Library (Lib), None
versions:  -Python 3.0

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

From report at bugs.python.org  Sat Apr 12 14:13:57 2008
From: report at bugs.python.org (Justin Ferguson)
Date: Sat, 12 Apr 2008 12:13:57 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1208002437.62.0.160678369948.issue2620@psf.upfronthosting.co.za>


Justin Ferguson <justin.ferguson at ioactive.com> added the comment:

Additionally-- the PyMem_NEW()/PyMem_New() macro's need to be fixed:

 231 static
 232 PyUnicodeObject *_PyUnicode_New(Py_ssize_t length)
 233 {
 234     register PyUnicodeObject *unicode;
 235 
 236     /* Optimization for empty strings */
 237     if (length == 0 && unicode_empty != NULL) {
 238         Py_INCREF(unicode_empty);
 239         return unicode_empty;
 240     }
 241 
 242     /* Unicode freelist & memory allocation */
 243     if (unicode_freelist) {
 244         unicode = unicode_freelist;
 245         unicode_freelist = *(PyUnicodeObject **)unicode;
 246         unicode_freelist_size--;
 247         if (unicode->str) {
 248             /* Keep-Alive optimization: we only upsize the buffer,
 249                never downsize it. */
 250             if ((unicode->length < length) &&
 251                 unicode_resize(unicode, length) < 0) {
 252                 PyMem_DEL(unicode->str);
 253                 goto onError;
 254             }
 255         }
 256         else {
 257             unicode->str = PyMem_NEW(Py_UNICODE, length + 1);
 258         }

 85 #define PyMem_New(type, n) \
 86   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 87         ( (type *) PyMem_Malloc((n) * sizeof(type)) ) )
 88 #define PyMem_NEW(type, n) \
 89   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 90         ( (type *) PyMem_MALLOC((n) * sizeof(type)) ) )
 91 
 92 #define PyMem_Resize(p, type, n) \
 93   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 94         ( (p) = (type *) PyMem_Realloc((p), (n) * sizeof(type)) ) )
 95 #define PyMem_RESIZE(p, type, n) \
 96   ( assert((n) <= PY_SIZE_MAX / sizeof(type)) , \
 97         ( (p) = (type *) PyMem_REALLOC((p), (n) * sizeof(type)) ) )


It looks like much of this is reachable from modules, unicode objects,
dict objects, set objects, et cetera. Also, if a 2G string across the
network seems unrealistic consider what 2 billion A's compresses down
to.(Macros again taken from 2.5.2 vanilla)

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

From report at bugs.python.org  Sat Apr 12 14:53:25 2008
From: report at bugs.python.org (Kjell Braden)
Date: Sat, 12 Apr 2008 12:53:25 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>


New submission from Kjell Braden <fnord at pentabarf.de>:

Distutils should tell swig to create it's C wrapper file into the
temporary directory (eg. build/temp.linux-i686-2.5) and to write the
language specific files to the library directory (eg.
build/lib.linux-i686-2.5).

Rationale:
Without the language specific files, python swig extensions won't be
able to run, so they should definetly be distributed by distutils.
The wrapper files are build by-products and should therefore be in the
temporary directory, so they get cleaned up on "setup.py clean".

----------
components: Demos and Tools
messages: 65399
nosy: afflux
severity: normal
status: open
title: swig support in distutils should use the build and temp dirs
type: behavior
versions: Python 2.5

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

From report at bugs.python.org  Sat Apr 12 15:03:41 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sat, 12 Apr 2008 13:03:41 +0000
Subject: [issue2617] Patch to emit "-J is reserved for Jython" on -J arg
In-Reply-To: <1207939710.11.0.248757051095.issue2617@psf.upfronthosting.co.za>
Message-ID: <1208005421.38.0.790674836629.issue2617@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I've reserved -X as well. Applied in r62293

----------
nosy: +tiran
resolution:  -> accepted
status: open -> closed

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

From report at bugs.python.org  Sat Apr 12 15:55:03 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 13:55:03 +0000
Subject: [issue902061] pydoc insists upon producing file: URLs
Message-ID: <1208008503.71.0.175273313653.issue902061@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr 12 15:57:49 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 12 Apr 2008 13:57:49 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208008669.87.0.594092712611.issue2624@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you provide a patch?

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

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

From report at bugs.python.org  Sat Apr 12 16:34:14 2008
From: report at bugs.python.org (Kjell Braden)
Date: Sat, 12 Apr 2008 14:34:14 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208010854.01.0.405686865679.issue2624@psf.upfronthosting.co.za>


Kjell Braden <fnord at pentabarf.de> added the comment:

Without having it tested very much, the attached patch fixes this issue
for me.

----------
keywords: +patch
Added file: http://bugs.python.org/file10017/python_distutils+swig.patch

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

From report at bugs.python.org  Sat Apr 12 17:53:43 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 15:53:43 +0000
Subject: [issue2600] BindingHTTPConnectionWithTimeout and
	BindingHTTPHandlerWithTimeout
In-Reply-To: <1207688700.18.0.242817334294.issue2600@psf.upfronthosting.co.za>
Message-ID: <1208015623.89.0.134399313844.issue2600@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


----------
versions: +Python 2.6 -Python 2.4, Python 2.5

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

From report at bugs.python.org  Sat Apr 12 18:13:06 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 16:13:06 +0000
Subject: [issue836088] Update htmllib to HTML 4.01
Message-ID: <1208016786.83.0.239846908043.issue836088@psf.upfronthosting.co.za>


Changes by Daniel Diniz <ajaksu at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr 12 18:17:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 16:17:04 +0000
Subject: [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1208017024.35.0.186813511489.issue2621@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Right, we should do this only in Py3k. It might be helpful to make an
alias in 2.6 for it. Attaching py3k patch.

----------
versions: +Python 3.0 -Python 2.6
Added file: http://bugs.python.org/file10018/rename_test_support_py3k.patch

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

From report at bugs.python.org  Sat Apr 12 18:22:17 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 16:22:17 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1208017337.66.0.568528113802.issue2240@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9611/py-itimer-0.1.2.tar.gz

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

From report at bugs.python.org  Sat Apr 12 18:22:29 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 16:22:29 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1208017349.57.0.711043897639.issue2240@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9613/setitimer_getitimer_wrapper.diff

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

From report at bugs.python.org  Sat Apr 12 18:22:51 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 16:22:51 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1208017371.39.0.236942582376.issue2240@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9615/setitimer_getitimer_wrapper_rename.diff

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

From report at bugs.python.org  Sat Apr 12 18:23:18 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 16:23:18 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1208017398.96.0.388056813695.issue2240@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9619/setitimer_getitimer_wrapper_fixes.diff

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

From report at bugs.python.org  Sat Apr 12 18:23:55 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 16:23:55 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1208017435.42.0.553661953199.issue2240@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9622/setitimer_getitimer_wrapper_doc_update.diff

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

From report at bugs.python.org  Sat Apr 12 18:23:49 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 16:23:49 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1208017429.73.0.242477556986.issue2240@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9620/setitimer_getitimer_wrapper_doc.diff

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

From report at bugs.python.org  Sat Apr 12 18:24:00 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 16:24:00 +0000
Subject: [issue2240] setitimer, getitimer wrapper
In-Reply-To: <1204728133.7.0.556949621776.issue2240@psf.upfronthosting.co.za>
Message-ID: <1208017440.56.0.39152695112.issue2240@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9623/setitimer_getitimer_wrapper_test.diff

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

From report at bugs.python.org  Sat Apr 12 18:38:37 2008
From: report at bugs.python.org (Bruce Frederiksen)
Date: Sat, 12 Apr 2008 16:38:37 +0000
Subject: [issue2598] "{ +(}".format(**{' +(': 44}) should produce ValueError:
	invalid identifier, ' +(' in format
In-Reply-To: <1207683524.11.0.610086195192.issue2598@psf.upfronthosting.co.za>
Message-ID: <1208018317.44.0.121049406232.issue2598@psf.upfronthosting.co.za>


Bruce Frederiksen <dangyogi at gmail.com> added the comment:

I was reading the 3.0 documentation:
http://docs.python.org/dev/3.0/library/string.html#formatstrings which
indicated that an identifier was required.  I was unaware of the
implementation note in the PEP.

They only issue remaining is that for the example in the title of this
issue, "{ +(}".format(**{' +(': 44}), no error is generated.  I agree
that this is a nit and presumably the will of the community reviewing
the PEP, so agree to having the issue rejected.

I would reject it myself, but am unable to do so...

Thank you for pointing out the PEP to me.

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

From report at bugs.python.org  Sat Apr 12 18:53:56 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 16:53:56 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1208019236.31.0.131187466025.issue2576@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Also reported in #1542407

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

From report at bugs.python.org  Sat Apr 12 19:13:47 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 17:13:47 +0000
Subject: [issue1156280] cmd.Cmd().cmdloop() can't read from file
Message-ID: <1208020427.24.0.0949178389499.issue1156280@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Superseded by #2571
The user can change cmd.Cmd.use_rawinput to False and get the desired
behaviour.

----------
nosy: +ajaksu2

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

From report at bugs.python.org  Sat Apr 12 19:20:42 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 17:20:42 +0000
Subject: [issue1721241] code that writes the PKG-INFO file doesnt handle
	unicode
Message-ID: <1208020842.11.0.721975909193.issue1721241@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Currently tracked in #2562

----------
nosy: +ajaksu2
versions: +Python 2.6

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

From report at bugs.python.org  Sat Apr 12 19:58:51 2008
From: report at bugs.python.org (=?utf-8?q?Christer_Sj=C3=B6holm?=)
Date: Sat, 12 Apr 2008 17:58:51 +0000
Subject: [issue2625] mailbox.MH.get_message() treats result of get_sequences()
	as list of tuples
In-Reply-To: <1208023131.05.0.0270197595247.issue2625@psf.upfronthosting.co.za>
Message-ID: <1208023131.05.0.0270197595247.issue2625@psf.upfronthosting.co.za>


New submission from Christer Sj?holm <hcs at furuvik.net>:

in mailbox.MH.get_message() there is a loop over the mailbox sequences
on row 894 in Python 2.5.2
  for name, key_list in self.get_sequences():
but mailbox.MH.get_sequences() returns a dict so it should be
  for name, key_list in self.get_sequences().iteritems():

----------
components: Library (Lib)
messages: 65408
nosy: hcs
severity: normal
status: open
title: mailbox.MH.get_message() treats result of get_sequences() as list of tuples
type: behavior
versions: Python 2.5, Python 3.0

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

From report at bugs.python.org  Sat Apr 12 20:13:27 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Apr 2008 18:13:27 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1208024007.42.0.126089571303.issue2530@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It isn't. I'll have to investigate this -- I have a feeling of d?j?-bug...

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

From report at bugs.python.org  Sat Apr 12 20:25:54 2008
From: report at bugs.python.org (Frank Wierzbicki)
Date: Sat, 12 Apr 2008 18:25:54 +0000
Subject: [issue2617] Patch to emit "-J is reserved for Jython" on -J arg
In-Reply-To: <1208005421.38.0.790674836629.issue2617@psf.upfronthosting.co.za>
Message-ID: <4dab5f760804121125u532782f2p4b547e80d7a492a@mail.gmail.com>


Frank Wierzbicki <fwierzbicki at gmail.com> added the comment:

On Sat, Apr 12, 2008 at 9:03 AM, Christian Heimes
<report at bugs.python.org> wrote:
>
>  Christian Heimes <lists at cheimes.de> added the comment:
>
>  I've reserved -X as well. Applied in r62293
Great, thanks!  While I'd love to have *both* -X and -J, is that okay
with the other devs?

-Frank

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

From report at bugs.python.org  Sat Apr 12 20:29:34 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Apr 2008 18:29:34 +0000
Subject: [issue1156280] cmd.Cmd().cmdloop() can't read from file
Message-ID: <1208024974.58.0.912561755519.issue1156280@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing as duplicate.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> cmd.py always uses raw_input, even when another stdin is specified

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

From report at bugs.python.org  Sat Apr 12 20:29:45 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Apr 2008 18:29:45 +0000
Subject: [issue1721241] code that writes the PKG-INFO file doesnt handle
	unicode
Message-ID: <1208024985.14.0.35696433598.issue1721241@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Closing as duplicate.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> Cannot use non-ascii letters in disutils if setuptools is used.

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

From report at bugs.python.org  Sat Apr 12 20:36:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Apr 2008 18:36:19 +0000
Subject: [issue2615] xml.dom.minidom documentation consistency and update
In-Reply-To: <1207912789.81.0.894453276302.issue2615@psf.upfronthosting.co.za>
Message-ID: <1208025378.98.0.597734075167.issue2615@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Committed as r62295.

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

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

From report at bugs.python.org  Sat Apr 12 22:19:15 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 20:19:15 +0000
Subject: [issue853569] Keyword or function to invoke pdb programmatically
Message-ID: <1208031555.43.0.00284591600368.issue853569@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I don't think this is going to happen any time soon.

----------
nosy: +benjamin.peterson
resolution:  -> rejected
status: open -> closed

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

From report at bugs.python.org  Sat Apr 12 22:23:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 20:23:55 +0000
Subject: [issue920680] readline not implemented for UTF-16
Message-ID: <1208031835.64.0.215304177435.issue920680@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It seems this is no longer true.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

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

From report at bugs.python.org  Sat Apr 12 22:26:31 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 20:26:31 +0000
Subject: [issue960845] overall index to distributed documentation
Message-ID: <1208031991.47.0.138572945244.issue960845@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

There is in 2.6.

----------
nosy: +benjamin.peterson
resolution:  -> fixed

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

From report at bugs.python.org  Sat Apr 12 22:47:28 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 20:47:28 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208033248.72.0.690227268363.issue1481036@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Something like this was done in 2.5.

----------
nosy: +benjamin.peterson
resolution:  -> fixed

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

From report at bugs.python.org  Sat Apr 12 22:48:21 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 20:48:21 +0000
Subject: [issue960845] overall index to distributed documentation
Message-ID: <1208033301.12.0.771090076047.issue960845@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr 12 22:48:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 20:48:46 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208033326.11.0.570336257529.issue1481036@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


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

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

From report at bugs.python.org  Sat Apr 12 22:59:57 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 20:59:57 +0000
Subject: [issue1683368] object.__init__ shouldn't allow args/kwds
Message-ID: <1208033997.39.0.764529437381.issue1683368@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Can this be closed?

----------
nosy: +benjamin.peterson

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

From report at bugs.python.org  Sat Apr 12 23:03:29 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sat, 12 Apr 2008 21:03:29 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1208034209.76.0.54888298675.issue2622@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

You may not like the naming applied there, but surely it is not a import
error. Can you actually manage to get an ImportError ?

----------
nosy: +gpolo

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

From report at bugs.python.org  Sat Apr 12 23:31:57 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Apr 2008 21:31:57 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208035917.79.0.501478395128.issue1481036@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I don't think so.

socket.error has been changed to inherit from IOError in 2.6 (and thus
socket.sslerror which inherits from socket.error).

EOFError has not changed.

ftplib.all_errors is already a tuple of (ftplib.Error, socket.error,
IOError, EOFError) which demonstrates the issue...

Anyways there was discussion on python-dev around the time I made
socket.error extend IOError.  Adding a new exception to the heirarchy
was frowned upon.  EnvironmentError is already suitable for that task.

Perhaps EOFError should extend EnvironmentError as well?

----------
nosy: +gregory.p.smith
versions: +Python 2.6

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

From report at bugs.python.org  Sat Apr 12 23:33:47 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Apr 2008 21:33:47 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208036027.34.0.0353205356057.issue1481036@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


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

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

From report at bugs.python.org  Sat Apr 12 23:36:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 12 Apr 2008 21:36:49 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208036209.49.0.532119493119.issue1481036@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Yes, that'd make sense. Ask on python-dev, though.

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

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

From report at bugs.python.org  Sat Apr 12 23:44:27 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Apr 2008 21:44:27 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1208036667.1.0.883610973232.issue2622@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> barry
nosy: +barry
priority:  -> low

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

From report at bugs.python.org  Sat Apr 12 23:55:24 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 21:55:24 +0000
Subject: [issue1779700] urlparse.urljoin does not obey current uri rfc (rfc
	3986)
Message-ID: <1208037324.28.0.452644540994.issue1779700@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Duplicate of #1591035

----------
nosy: +ajaksu2

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

From report at bugs.python.org  Sat Apr 12 23:55:50 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 12 Apr 2008 21:55:50 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1208037350.1.0.251883170648.issue992389@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> ncoghlan
priority: low -> normal

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

From report at bugs.python.org  Sat Apr 12 23:56:26 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sat, 12 Apr 2008 21:56:26 +0000
Subject: [issue1950] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za>
Message-ID: <1208037386.24.0.243540054092.issue1950@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

I revised the patch with respect to Alexander's comments. In summary,
here is what I changed from the previous patch:

  - Removed the unnecessary "fixes" to Objects/structseq.c
    and Modules/timemodule.c
  - Updated Objects/typeobject.c to forbid null-bytes in __doc__,
    since they cannot be handled in the `tp_doc` member.
  - Removed an erroneous pointer dereference in Modules/zipimport.c
  - Changed `len+1` to `len` in the memcpy() call in the
    Modules/parsermodule.c fixes

Added file: http://bugs.python.org/file10019/unicode_string_overflow-2.patch

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

From report at bugs.python.org  Sat Apr 12 23:57:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sat, 12 Apr 2008 21:57:09 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208037429.29.0.25526466387.issue1481036@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

The problem with EOFError as a child of EnvironmentError is that it
wouldn't conform to EnvironmentError's standard 2-tuple or 3-tuple of
args representing errno and the associate string and optionally filename.

So inserting an exception above EnvironmentError would be a solution to
that for EOFError.  Alternatively, EOFError could have some default
2-tuple values and be a child of EnvironmentError.

thoughts or pronouncements anyone?  (asking python-dev now)

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

From report at bugs.python.org  Sun Apr 13 00:02:31 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Sat, 12 Apr 2008 22:02:31 +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: <1208037751.29.0.285597200217.issue2195@psf.upfronthosting.co.za>


Daniel Diniz <ajaksu at gmail.com> added the comment:

Discussed in #754016

----------
nosy: +ajaksu2
versions: +Python 2.6 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2195>
__________________________________

From report at bugs.python.org  Sun Apr 13 01:30:02 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Sat, 12 Apr 2008 23:30:02 +0000
Subject: [issue2626] If compile with gcc 4.3.0 python interpreter itself eats
	all memory
In-Reply-To: <1208043002.25.0.498433851642.issue2626@psf.upfronthosting.co.za>
Message-ID: <1208043002.25.0.498433851642.issue2626@psf.upfronthosting.co.za>


New submission from Georgij Kondratjev <smpuj at bk.ru>:

First time I noticed it during compilation of python3 r62301, then 
3.0a4, then 3.0a3, with and without CFLAGS set. 
Step "./python -E ./setup.py -q build" called by make never ends (and 
there is no output). Just "/python" behaves the same: it eats memory 
and prints nothing. Gcc 3.4.6 works fine. Previous versions of gcc 4 
were working too, but I didn`t tested them now.
My system: gcc 4.3.0, kernel 2.6.24.zen5.20080410 (with zen patchset, 
can test again with vanilla 2.6.24, or if you say it is too old I will 
compile 2.6.24.4), glibc 2.7, Arch GNU/Linux.

----------
components: Interpreter Core
messages: 65426
nosy: orivej
severity: normal
status: open
title: If compile with gcc 4.3.0 python interpreter itself eats all memory
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2626>
__________________________________

From report at bugs.python.org  Sun Apr 13 01:44:29 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 12 Apr 2008 23:44:29 +0000
Subject: [issue1631171] implement warnings module in C
Message-ID: <1208043869.62.0.159623753051.issue1631171@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Committed in revision 62303.

----------
resolution:  -> accepted
status: pending -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1631171>
_____________________________________

From report at bugs.python.org  Sun Apr 13 01:59:08 2008
From: report at bugs.python.org (Georgij Kondratjev)
Date: Sat, 12 Apr 2008 23:59:08 +0000
Subject: [issue2626] If compile with gcc 4.3.0 python interpreter itself eats
	all memory
In-Reply-To: <1208043002.25.0.498433851642.issue2626@psf.upfronthosting.co.za>
Message-ID: <1208044748.9.0.7705132619.issue2626@psf.upfronthosting.co.za>


Georgij Kondratjev <smpuj at bk.ru> added the comment:

This doesn't affect python 2.5.2

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2626>
__________________________________

From report at bugs.python.org  Sun Apr 13 02:21:52 2008
From: report at bugs.python.org (John Jackson)
Date: Sun, 13 Apr 2008 00:21:52 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1208046112.94.0.989855180819.issue2622@psf.upfronthosting.co.za>


John Jackson <johnjackson at pobox.com> added the comment:

Yes. If the code is used to build a standalone application with py2app 
on the Mac, here's the end of the stack trace:
  File "controller.pyo", line 17, in <module>
  File "readMail.pyo", line 15, in <module>
  File "mailbox.pyo", line 1294, in <module>
  File "email/__init__.pyo", line 79, in __getattr__
  File "email/message.pyo", line 86, in <module>
  File "email/message.pyo", line 784, in Message
  File "email/__init__.pyo", line 79, in __getattr__
ImportError: No module named iterators

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Sun Apr 13 02:36:16 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Sun, 13 Apr 2008 00:36:16 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1208046976.41.0.50855531369.issue2622@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Can you send a sample code that reproduces that ?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Sun Apr 13 05:25:51 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Apr 2008 03:25:51 +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: <1208057151.84.0.612632702768.issue2078@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I can't see a great reason to change the behavior.  I've attached my
current patch for csv.py and test_csv.py in case someone else wants
to pick it up later.

----------
keywords: +patch
priority:  -> low
resolution:  -> postponed
status: open -> closed
Added file: http://bugs.python.org/file10020/csv.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2078>
__________________________________

From report at bugs.python.org  Sun Apr 13 05:28:05 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Apr 2008 03:28:05 +0000
Subject: [issue766910] fix one or two bugs in trace.py
Message-ID: <1208057285.93.0.669316966917.issue766910@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

unassigning

----------
assignee: skip.montanaro -> 

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue766910>
____________________________________

From report at bugs.python.org  Sun Apr 13 05:28:55 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Apr 2008 03:28:55 +0000
Subject: [issue1744580] cvs.get_dialect() return a class object
Message-ID: <1208057335.96.0.783801766722.issue1744580@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Just a doc change after all...

----------
status: pending -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1744580>
_____________________________________

From report at bugs.python.org  Sun Apr 13 05:29:45 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Apr 2008 03:29:45 +0000
Subject: [issue852532] ^$ won't split on empty line
Message-ID: <1208057385.17.0.995059454917.issue852532@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
status: pending -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue852532>
____________________________________

From report at bugs.python.org  Sun Apr 13 05:30:34 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Apr 2008 03:30:34 +0000
Subject: [issue1374063] Broader iterable support for xmlrpclib
Message-ID: <1208057434.89.0.192572144018.issue1374063@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
resolution:  -> remind

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1374063>
_____________________________________

From report at bugs.python.org  Sun Apr 13 05:33:04 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Apr 2008 03:33:04 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1208057583.99.0.0195021379435.issue1225769@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Assigning to Andrew (as the primary C lib author).  Andrew, please
comment ;-).

----------
assignee: skip.montanaro -> andrewmcnamara
nosy: +andrewmcnamara

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_____________________________________

From report at bugs.python.org  Sun Apr 13 05:34:12 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 13 Apr 2008 03:34:12 +0000
Subject: [issue1437699] allow unicode arguments for robotparser.can_fetch
Message-ID: <1208057652.23.0.0369118621652.issue1437699@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
assignee: skip.montanaro -> 
nosy:  -skip.montanaro

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1437699>
_____________________________________

From report at bugs.python.org  Sun Apr 13 06:32:48 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 13 Apr 2008 04:32:48 +0000
Subject: [issue2626] If compile with gcc 4.3.0 python interpreter itself eats
	all memory
In-Reply-To: <1208043002.25.0.498433851642.issue2626@psf.upfronthosting.co.za>
Message-ID: <1208061168.7.0.29222302914.issue2626@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That's a bug in gcc 4.3, see

http://mail.python.org/pipermail/python-3000/2008-April/012965.html

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed
versions: +3rd party -Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2626>
__________________________________

From report at bugs.python.org  Sun Apr 13 07:57:43 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sun, 13 Apr 2008 05:57:43 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1208066263.19.0.219512312848.issue992389@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

This is actually a pretty tough problem - fixing it would involve some
fairly subtle changes to the way imports from packages are handled.
Given that I'm of the opinion that permitting circular imports in a code
base is an extraordinarily bad coding practice (if I'm ever tempted to
create a circular import, I consider it a sign that I need to separate
out some of the common code into a utility module), I'm not personally
going to be putting any effort into solving it (although I wouldn't
necessarily oppose anyone else trying to fix it).

However, I'll give a detailed description of the problem and a possible
solution in case anyone else wants to tackle it (since I believe there's
already a similar trick done for the sys.modules cache).

At the moment, when resolving an import chain __import__ only sets the
parent package's attribute for the submodule after the submodule import
is complete. This is what Jim describes in his original post, and is the
cause of the failure to resolve the name. Deferring the lookups solves
the problem because it means the package attributes are checked only
after the whole import chain is complete, instead of trying to get
access to a half-executed module during the import itself.

The most likely solution to the problem would be to change the attribute
on the parent package to be handled in a fashion closer to the way the
sys.modules cache is handled: set the attribute on the parent package
*before* executing the module's code, and delete that attribute if a
problem is encountered with the import.

The consequence of this would be that circular imports would be
permitted, although the module's imported in this fashion would be seen
in a half constructed state. So instead of the import failing with an
exception (which is what happens now), you would instead get a module
which you can't actually use (since most its attributes won't actually
be filled in yet, as the circular imports will normally occur near the
top of the file). Attempts to use methods, attributes and functions from
the module may or may not work depending on the order in which the
original module does things.

A clean failure indicating "You have a circular import, get rid of it"
seems better to me than possible hard to diagnose bugs due to being able
to retrieve things from a half-constructed module, but opinions
obviously differ on that. However, I really don't see this changing
without a PEP.

----------
assignee: ncoghlan -> 
type:  -> feature request

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
____________________________________

From report at bugs.python.org  Sun Apr 13 09:43:42 2008
From: report at bugs.python.org (Armin Rigo)
Date: Sun, 13 Apr 2008 07:43:42 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208072622.49.0.693349357109.issue1481036@psf.upfronthosting.co.za>


Armin Rigo <arigo at users.sourceforge.net> added the comment:

This will break many existing applications, no?  I can easily think of
examples of reasonable code that would no longer work as intended. 
What's even worse, breakage might only show up in exceptional cases and
give obscure results (e.g. reporting the wrong problem to the user).

----------
nosy: +arigo

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481036>
_____________________________________

From report at bugs.python.org  Sun Apr 13 10:02:08 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Apr 2008 08:02:08 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1208073728.36.0.35146910949.issue2530@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Should be fixed now with the latest Sphinx revision.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2530>
__________________________________

From report at bugs.python.org  Sun Apr 13 10:15:36 2008
From: report at bugs.python.org (Torsten Bronger)
Date: Sun, 13 Apr 2008 08:15:36 +0000
Subject: [issue992389] attribute error after non-from import
Message-ID: <1208074536.89.0.777972823887.issue992389@psf.upfronthosting.co.za>


Torsten Bronger <bronger at physik.rwth-aachen.de> added the comment:

I dare to make a follow-up although I have no idea at all about the
internal processes in the Python interpreter.  But I've experimented
with circular imports a lot recently.  Just two points:

First, I think that circular imports don't necessarily exhibit a
sub-opimal programming style.  I had a large parser module which I just
wanted to split in order to get handy file sizes.  However, the parser
parses human documents, and layout element A defined in module A may
contain element B from module B and vice versa.  In a language with
declarations, you just include a big header file but in Python, you end
up with circular imports.  Or, you must stay with large files.

So, while I think that this clean error message Nick suggests is a good
provisional solution, it should not make the impression that the
circular import is a flaw by itself.

And secondly, the problem with modules that are not yet populated with
objects is how circular imports have worked in Python anyway.  You can
easily cope with it by not referencing the imported module's objects in
the top-level code of the importing module (but only in functions and
methods).

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue992389>
____________________________________

From report at bugs.python.org  Sun Apr 13 11:35:40 2008
From: report at bugs.python.org (Kjell Braden)
Date: Sun, 13 Apr 2008 09:35:40 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208079339.96.0.144068414175.issue2624@psf.upfronthosting.co.za>


Kjell Braden <fnord at pentabarf.de> added the comment:

Note that the language specific files can't be handled via py_modules
because this is processed before their generation.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2624>
__________________________________

From report at bugs.python.org  Sun Apr 13 14:22:18 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Sun, 13 Apr 2008 12:22:18 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1208089338.43.0.460002793152.issue2620@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 32-bit platforms, it's probably best to add a size check. I don't
it's worth doing that on 64-bit platforms - overflows are rather
unlikely there.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
__________________________________

From report at bugs.python.org  Sun Apr 13 14:29:13 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Apr 2008 12:29:13 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208089753.47.0.870173383759.issue1481036@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Py3k then?

----------
versions: +Python 3.0 -Python 2.6

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481036>
_____________________________________

From report at bugs.python.org  Sun Apr 13 14:30:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Apr 2008 12:30:52 +0000
Subject: [issue2530] Document IO module
In-Reply-To: <1207082507.57.0.774536381086.issue2530@psf.upfronthosting.co.za>
Message-ID: <1208089852.79.0.365601642899.issue2530@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

And I have fleshed out the doc strings and backported it to 2.6.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2530>
__________________________________

From report at bugs.python.org  Sun Apr 13 15:30:08 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 13 Apr 2008 13:30:08 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1208093407.98.0.435135429816.issue1751@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

I'm going to review the patch later. How are we going to back port the
stuff to 2.6?

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________

From report at bugs.python.org  Sun Apr 13 16:06:19 2008
From: report at bugs.python.org (Ron Adam)
Date: Sun, 13 Apr 2008 14:06:19 +0000
Subject: [issue902061] pydoc insists upon producing file: URLs
Message-ID: <1208095579.72.0.697468081027.issue902061@psf.upfronthosting.co.za>


Ron Adam <ron_adam at users.sourceforge.net> added the comment:

The following patch also fixes this along with other improvements. 
Maybe someone can review it.

http://bugs.python.org/issue2001

----------
nosy: +ron_adam

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue902061>
____________________________________

From report at bugs.python.org  Sun Apr 13 16:12:17 2008
From: report at bugs.python.org (Christian Heimes)
Date: Sun, 13 Apr 2008 14:12:17 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1208095937.03.0.0532738978642.issue1751@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

Hey Alexandre!

The latest patch doesn't apply cleanly. Please provide a new patch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________

From report at bugs.python.org  Sun Apr 13 18:45:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Apr 2008 16:45:40 +0000
Subject: [issue2627] mark pgen generated files
In-Reply-To: <1208105140.17.0.711771131434.issue2627@psf.upfronthosting.co.za>
Message-ID: <1208105140.17.0.711771131434.issue2627@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch makes pgen note that it generated the file at the top.

----------
assignee: georg.brandl
components: Interpreter Core
files: pgen_generated.patch
keywords: easy, patch
messages: 65447
nosy: benjamin.peterson, georg.brandl
priority: low
severity: normal
status: open
title: mark pgen generated files
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10021/pgen_generated.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2627>
__________________________________

From report at bugs.python.org  Sun Apr 13 20:18:37 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 13 Apr 2008 18:18:37 +0000
Subject: [issue2627] mark pgen generated files
In-Reply-To: <1208105140.17.0.711771131434.issue2627@psf.upfronthosting.co.za>
Message-ID: <1208110717.3.0.735136937831.issue2627@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fine with me if you convert the spaces to a tab first.

----------
assignee: georg.brandl -> benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2627>
__________________________________

From report at bugs.python.org  Sun Apr 13 20:32:17 2008
From: report at bugs.python.org (Kjell Braden)
Date: Sun, 13 Apr 2008 18:32:17 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208111537.13.0.846832886444.issue2624@psf.upfronthosting.co.za>


Changes by Kjell Braden <fnord at pentabarf.de>:


Removed file: http://bugs.python.org/file10017/python_distutils+swig.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2624>
__________________________________

From report at bugs.python.org  Sun Apr 13 20:34:02 2008
From: report at bugs.python.org (Kjell Braden)
Date: Sun, 13 Apr 2008 18:34:02 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208111642.53.0.11716701255.issue2624@psf.upfronthosting.co.za>


Kjell Braden <fnord at pentabarf.de> added the comment:

I noticed that my patch did not work for absolute directory names and
adjusted the matching to fix this.

Added file: http://bugs.python.org/file10022/python_distutils+swig.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2624>
__________________________________

From report at bugs.python.org  Sun Apr 13 20:34:19 2008
From: report at bugs.python.org (Kjell Braden)
Date: Sun, 13 Apr 2008 18:34:19 +0000
Subject: [issue2624] swig support in distutils should use the build and temp
	dirs
In-Reply-To: <1208004805.0.0.253675871958.issue2624@psf.upfronthosting.co.za>
Message-ID: <1208111659.01.0.109331515515.issue2624@psf.upfronthosting.co.za>


Changes by Kjell Braden <fnord at pentabarf.de>:


----------
components: +Distutils -Demos and Tools

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2624>
__________________________________

From report at bugs.python.org  Sun Apr 13 22:36:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Apr 2008 20:36:35 +0000
Subject: [issue2627] mark pgen generated files
In-Reply-To: <1208105140.17.0.711771131434.issue2627@psf.upfronthosting.co.za>
Message-ID: <1208118995.81.0.267997048612.issue2627@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Committed in r62329.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2627>
__________________________________

From report at bugs.python.org  Sun Apr 13 22:40:33 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 13 Apr 2008 20:40:33 +0000
Subject: [issue2510] Bazaar ignore file
In-Reply-To: <1206810431.77.0.422106495964.issue2510@psf.upfronthosting.co.za>
Message-ID: <1208119233.61.0.550692513807.issue2510@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Added in r26330.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2510>
__________________________________

From report at bugs.python.org  Sun Apr 13 22:54:57 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Apr 2008 20:54:57 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1208120097.54.0.12997560455.issue1751@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Here's an updated patch.

Added file: http://bugs.python.org/file10023/bytesio+misc-fixes-7.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________

From report at bugs.python.org  Sun Apr 13 22:58:47 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Apr 2008 20:58:47 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1208120326.89.0.257893328273.issue1751@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Oops, I forgot again to "svn add" the new files.

Added file: http://bugs.python.org/file10024/bytesio+misc-fixes-8.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________

From report at bugs.python.org  Sun Apr 13 22:58:51 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 13 Apr 2008 20:58:51 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1208120331.57.0.386726325057.issue1751@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


Removed file: http://bugs.python.org/file10023/bytesio+misc-fixes-7.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________

From report at bugs.python.org  Mon Apr 14 01:50:11 2008
From: report at bugs.python.org (Jonathan)
Date: Sun, 13 Apr 2008 23:50:11 +0000
Subject: [issue2628] ftplib Persistent data connection
In-Reply-To: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>
Message-ID: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>


New submission from Jonathan <jbell at scrippsweb.com>:

About a year ago I found myself fighting a broken FTP server that
couldn't handle multiple passive data transfers through a firewall or
NATed connection. Thankfully, this same problem server supports block
transmission mode, which allows a client to create a single data
connection for transferring multiple files.

I've attached a patch (and sample debug output) for the latest trunk.

Might this be useful to anyone else in any way? I realize any MODE
option rather than S is widely unsupported and possibly an edge case,
but getting this into trunk would be preferable. We've been running this
code under Python2.3 for nearly a year -- the jobs run several times per
hour -- and are extremely happy with the results.

----------
components: Library (Lib)
files: ftplib.py.blockmode.patch
keywords: patch
messages: 65454
nosy: jbell
severity: normal
status: open
title: ftplib Persistent data connection
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10025/ftplib.py.blockmode.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2628>
__________________________________

From report at bugs.python.org  Mon Apr 14 01:54:54 2008
From: report at bugs.python.org (Jonathan)
Date: Sun, 13 Apr 2008 23:54:54 +0000
Subject: [issue2628] ftplib Persistent data connection
In-Reply-To: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>
Message-ID: <1208130894.44.0.396596346303.issue2628@psf.upfronthosting.co.za>


Jonathan <jbell at scrippsweb.com> added the comment:

Here's the debug output when the transfers are going well.

Added file: http://bugs.python.org/file10026/debug.log

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2628>
__________________________________

From report at bugs.python.org  Mon Apr 14 03:08:58 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Apr 2008 01:08:58 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1208135338.57.0.692730665762.issue2620@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
assignee:  -> gregory.p.smith
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
__________________________________

From report at bugs.python.org  Mon Apr 14 04:56:09 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Apr 2008 02:56:09 +0000
Subject: [issue2629] _Py_ForgetReference crash when called from _PyUnicode_New
	on MemoryError
In-Reply-To: <1208141769.9.0.601794636636.issue2629@psf.upfronthosting.co.za>
Message-ID: <1208141769.9.0.601794636636.issue2629@psf.upfronthosting.co.za>


New submission from Gregory P. Smith <greg at krypto.org>:

In _PyUnicode_New() a unicode object is taken from the freelist but if
the unicode_resize() call fails and returns -1, the goto onerror calls
_Py_ForgetReference on the unicode object... But it has NULL _ob_prev
and _ob_next values causing a crash when they're used.

How to reproduce:

* Make a 32-bit --with-pydebug build of Python trunk.
* Run it on a machine with lots of ram (at least 3gigs recommended, or
lots of swap and a heap of patience):

./python
Python 2.6a2+ (trunk:62336M, Apr 13 2008, 18:51:30)
>>> msg = 'A'*2000111222
>>> x = msg.decode('utf8')

It segmentation faults in _Py_ForgetReference.

----------
messages: 65456
nosy: gregory.p.smith
severity: normal
status: open
title: _Py_ForgetReference crash when called from _PyUnicode_New on MemoryError
type: crash
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2629>
__________________________________

From report at bugs.python.org  Mon Apr 14 05:12:44 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 14 Apr 2008 03:12:44 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1207953338.18.0.167765254153.issue2620@psf.upfronthosting.co.za>
Message-ID: <1208142764.87.0.11104603642.issue2620@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Here's a patch that fixes this by making both Python's malloc and
realloc return NULL if (0 <= size <= PY_SSIZE_T_MAX).

A side effect of this is that strings on 32bit platforms can no longer
be allocated up to 2**31-1 in length as the malloc includes the internal
python object structure overhead.  The maximum string size becomes
2147483609 with an optimized build on this system.

I do not think that is a problem.  A 32-bit process by definition can
only ever have one such object allocated at a time anyways. ;)

any objections?

Added file: http://bugs.python.org/file10027/issue2620-gps01-patch.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
__________________________________

From report at bugs.python.org  Mon Apr 14 05:29:33 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 14 Apr 2008 03:29:33 +0000
Subject: [issue2620] Multiple buffer overflows in unicode processing
In-Reply-To: <1208142764.87.0.11104603642.issue2620@psf.upfronthosting.co.za>
Message-ID: <d38f5330804132029m55cfb22fib42f77da9e577e30@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Sun, Apr 13, 2008 at 11:12 PM, Gregory P. Smith
<report at bugs.python.org> wrote:
..
>  Here's a patch that fixes this by making both Python's malloc and
>  realloc return NULL if (0 <= size <= PY_SSIZE_T_MAX).
>
This will not solve the original problem completely: multiplicative
overflow may produce size in the 0 to PY_SSIZE_T_MAX range.
Furthemore, malloc and realloc take unsigned arguments and I believe
there are cases when they are called with unsigned arguments in python
code.  Using the proposed macro definitions in these cases will lead
to compiler warnings.

I don't object to limiting the allowed malloc/realoc size, but the
check should be expressed as unsigned comparison:  (size_t)(n) >
(size_t)PY_SSIZE_T_MAX and multiplications by n > 2 should still be
checked for overflow before the result can be used for malloc.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2620>
__________________________________

From report at bugs.python.org  Mon Apr 14 06:18:04 2008
From: report at bugs.python.org (John Jackson)
Date: Mon, 14 Apr 2008 04:18:04 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1208146684.48.0.387507770325.issue2622@psf.upfronthosting.co.za>


John Jackson <johnjackson at pobox.com> added the comment:

I'll put one together.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Mon Apr 14 10:48:21 2008
From: report at bugs.python.org (Armin Rigo)
Date: Mon, 14 Apr 2008 08:48:21 +0000
Subject: [issue1481036] IOBaseError
Message-ID: <1208162901.56.0.848796306951.issue1481036@psf.upfronthosting.co.za>


Changes by Armin Rigo <arigo at users.sourceforge.net>:


----------
nosy:  -arigo

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1481036>
_____________________________________

From report at bugs.python.org  Mon Apr 14 11:18:26 2008
From: report at bugs.python.org (Tal Einat)
Date: Mon, 14 Apr 2008 09:18:26 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1208164706.95.0.350375215392.issue1529142@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

I really, really wish we could get this in for Python2.6 - this issue is
a major drawback for beginners, for whom IDLE is mostly intended.

Perhaps not this specific patch; I am willing to work on cleaning up the
code and getting it tested by users on different platforms. Is there any
chance of this happening? What can I do to get this moving again?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_____________________________________

From report at bugs.python.org  Mon Apr 14 11:54:24 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Mon, 14 Apr 2008 09:54:24 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>


New submission from atsuo ishimoto <ishimoto at users.sourceforge.net>:

In py3k, repr() escapes non-ASCII characters in Unicode to \uXXXX as
Python 2. This is unpleasant feature if you are working with non-latin
characters. This issue was once discussed by Hye-Shik Chang[1], but was
rejected. Here's a new challenge for Python 3 to fix issue.

In this patch, repr() converts special ascii characters such as "\t", 
"\r", "\n", but doesn't convert non-ASCII characters to \uXXXX form. 
Non-ASCII characters are converted by TextIOWrapper on printing. I set 
'errors' attribute of sys.stdout and sys.stderr to 'backslashreplace', so
un-printable characters are converted to '\uXXXX' if your console
cannot print such characters.

This patch breaks five regr tests on my environment. 
I'll fix these tests if this patch is acceptable.

[1] http://mail.python.org/pipermail/python-dev/2002-October/029443.html
http://bugs.python.org/issue479898

----------
components: None
files: diff.txt
messages: 65461
nosy: ishimoto
severity: normal
status: open
title: repr() should not escape non-ASCII characters
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10028/diff.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Mon Apr 14 12:08:23 2008
From: report at bugs.python.org (=?utf-8?q?Lars_Gust=C3=A4bel?=)
Date: Mon, 14 Apr 2008 10:08:23 +0000
Subject: [issue2058] reduce tarfile memory footprint
In-Reply-To: <1202643843.0.0.134352659823.issue2058@psf.upfronthosting.co.za>
Message-ID: <1208167703.83.0.159349819454.issue2058@psf.upfronthosting.co.za>


Lars Gust?bel <lars at gustaebel.de> added the comment:

Checked into the py3k branch as r62337.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2058>
__________________________________

From report at bugs.python.org  Mon Apr 14 17:09:52 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 14 Apr 2008 15:09:52 +0000
Subject: [issue2628] ftplib Persistent data connection
In-Reply-To: <1208130611.58.0.0933193390026.issue2628@psf.upfronthosting.co.za>
Message-ID: <1208185792.01.0.59679755666.issue2628@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2628>
__________________________________

From report at bugs.python.org  Mon Apr 14 17:12:44 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Mon, 14 Apr 2008 15:12:44 +0000
Subject: [issue2518] smtpd.py to handle huge email
In-Reply-To: <1206940317.15.0.464118270083.issue2518@psf.upfronthosting.co.za>
Message-ID: <1208185964.29.0.229653189805.issue2518@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2518>
__________________________________

From report at bugs.python.org  Mon Apr 14 17:58:14 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 14 Apr 2008 15:58:14 +0000
Subject: [issue2559] atom sorting error when building ctypes
In-Reply-To: <1207423627.95.0.288324472301.issue2559@psf.upfronthosting.co.za>
Message-ID: <1208188694.6.0.721964296758.issue2559@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

So closing this as won't fix.

----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2559>
__________________________________

From report at bugs.python.org  Mon Apr 14 18:19:04 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 14 Apr 2008 16:19:04 +0000
Subject: [issue1797] ctypes function pointer enhancements
In-Reply-To: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za>
Message-ID: <1208189944.81.0.788843590773.issue1797@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


Removed file: http://bugs.python.org/file9129/ctypes-funcptr.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1797>
__________________________________

From report at bugs.python.org  Mon Apr 14 18:19:29 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 14 Apr 2008 16:19:29 +0000
Subject: [issue1797] ctypes function pointer enhancements
In-Reply-To: <1200083698.65.0.997886461661.issue1797@psf.upfronthosting.co.za>
Message-ID: <1208189969.83.0.216072949319.issue1797@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Remove useless file (doesn't contain a patch).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1797>
__________________________________

From report at bugs.python.org  Mon Apr 14 18:33:47 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 16:33:47 +0000
Subject: [issue1092502] Memory leak in socket.py on Mac OS X
Message-ID: <1208190827.29.0.853821042777.issue1092502@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I think this should be fixed somewhere in the c code. people calling
sock.recv which a large recv size will also trigger this error.
this fix is wrong. the fixed code reads one byte at a time.
see:
http://mail.python.org/pipermail/python-dev/2008-April/078613.html

----------
nosy: +schmir

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092502>
_____________________________________

From report at bugs.python.org  Mon Apr 14 18:11:34 2008
From: report at bugs.python.org (Thomas Heller)
Date: Mon, 14 Apr 2008 16:11:34 +0000
Subject: [issue2616] ctypes.pointer(), ctypes.POINTER() speedup
In-Reply-To: <1207925534.93.0.923711950169.issue2616@psf.upfronthosting.co.za>
Message-ID: <1208189494.7.0.671052501072.issue2616@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Committed a slightly modified patch as rev 62338; will also be merged
into py3k.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2616>
__________________________________

From report at bugs.python.org  Mon Apr 14 18:14:04 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Durigan_J=C3=BAnior?=)
Date: Mon, 14 Apr 2008 16:14:04 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
Message-ID: <1208189644.84.0.297738033249.issue1628484@psf.upfronthosting.co.za>


S?rgio Durigan J?nior <sergiodj at linux.vnet.ibm.com> added the comment:

Hi Martin,

This is what you get when you try to build a 64-bit Python on a biarch
machine (64-bit kernel, 32-bit userspace), using a gcc that generates
natively 32-bit objects (therefore, you *must* pass the '-m64' option
for the compiler):

#> ./configure --enable-shared --target=powerpc64-unknown-linux
BASECFLAGS='-m64'

<output generated by configure script>

#> make

gcc -pthread -c -m64 -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3
-Wall -Wstrict-prototypes  -I. -IInclude -I./Include  -fPIC
-DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
In file included from Include/Python.h:57,
                 from ./Modules/python.c:3:
Include/pyport.h:761:2: error: #error "LONG_BIT definition appears wrong
for platform (bad gcc/glibc config?)."
make: *** [Modules/python.o] Error 1


As you can see, the compilation fails. Now, if I try this configure line:

#> ./configure --enable-shared --target=powerpc64-unknown-linux
BASECFLAGS='-m64' CFLAGS='-m64'

<output from configure>

#> make

Compilation goes well untill:

gcc -pthread -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  
Parser/acceler.o Parser/grammar1.o Parser/listnode.o Parser/node.o
Parser/parser.o Parser/parsetok.o Parser/bitset.o Parser/metagrammar.o
Parser/firstsets.o Parser/grammar.o Parser/pgen.o Objects/obmalloc.o
Python/mysnprintf.o Parser/tokenizer_pgen.o Parser/printgrammar.o
Parser/pgenmain.o -lpthread -ldl  -lutil -o Parser/pgen

As you can see, in this specific line we don't have the '-m64' flag,
what causes a bunch of errors (all of them due to the absence of '-m64'
flag). Ok, so I decided to try with LDFLAGS:

#> ./configure --enable-shared --target=powerpc64-unknown-linux
BASECFLAGS='-m64' CFLAGS='-m64' LDFLAGS='-m64'

<output from configure>

#> make

Now, the error happens when libpython.so is generated (and the reason is
the same: missing '-m64').

Well, now I have a few questions:

1) As you could see above, actually you need CFLAGS in order to compile
Python correctly. As far as I could investigate, the reason you need
this is because of the tests that are done by configure. Without the
CFLAGS, configure will think it's building a 32-bit Python, despite of
the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
through Makefile or not? IMHO, we do.

2) Even with CFLAGS and BASECFLAGS set, the compilation fails. Using
LDFLAGS makes the compilation process continue a little more, but it
still doesn't solve the problem. AFAIK, the reason it doesn't solve the
problem is, again, because we are not propagating it through the
Makefile. Can you see any different reason? Also, should we propagate
LDFLAGS through Makefile? IMHO, we should.

Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
But again, I don't think this is a solution for this issue :-).

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________

From report at bugs.python.org  Mon Apr 14 19:30:43 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 14 Apr 2008 17:30:43 +0000
Subject: [issue1092502] Memory leak in socket.py on Mac OS X
Message-ID: <1208194243.95.0.658352893413.issue1092502@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Note that _rbufsize is only set to 1 if the _fileobject's bufsize is set
to 0.  So perhaps the bug is that some library is turning off buffering
when it shouldn't.

I don't see how you would fix this in the C code, other than manually
doing two separate mallocs and copying the data, which would unfairly
penalize platforms with smarter malloc() implementations.  What sort of
fix would you suggest?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092502>
_____________________________________

From report at bugs.python.org  Mon Apr 14 20:02:00 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Apr 2008 18:02:00 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1208196120.59.0.0821288682636.issue2389@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

This looks indeed wrong. Unfortunately it also looks hard to fix in a
way that won't break unpickling arrays pickled by a previous Python
version.  We won't be able to fix this in 2.5 (it'll be a new feature)
but we should try to fix this in 2.6 and 3.0.

----------
nosy: +gvanrossum
priority:  -> critical
versions: +Python 3.0 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
__________________________________

From report at bugs.python.org  Mon Apr 14 20:12:24 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Apr 2008 18:12:24 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208196744.05.0.736759536469.issue2630@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think this has potential, but it is too liberal. There are many more
characters that cannot be assumed printable, e.g. many of the Latin-1
characters in the range 0x80 through 0x9F.  Isn't there some Unicode
data table that shows code points that are safely printable?

OTOH there are other potential use cases where it would be nice to see
the \u escapes, e.g. when one is concerned about sequences that print
the same but don't have the same content (e.g. pre-normalization).

The backslashreplace trick is nice, I didn't even know about that. :-)

----------
keywords: +patch
nosy: +gvanrossum

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Mon Apr 14 20:22:11 2008
From: report at bugs.python.org (Paul Bonser)
Date: Mon, 14 Apr 2008 18:22:11 +0000
Subject: [issue2631] IMPORT_NAME Documentation is incomplete
In-Reply-To: <1208197331.08.0.00587234594445.issue2631@psf.upfronthosting.co.za>
Message-ID: <1208197331.08.0.00587234594445.issue2631@psf.upfronthosting.co.za>


New submission from Paul Bonser <paul at paulbonser.com>:

The documentation for IMPORT_NAME at
http://docs.python.org/lib/bytecodes.html doesn't mention the fact that
the instruction requires two parameters to be on the stack.

TOS and TOS1 should map to the fromlist and level parameters to the
builtin function __import__, respectively.

----------
assignee: georg.brandl
components: Documentation
messages: 65471
nosy: georg.brandl, pib
severity: normal
status: open
title: IMPORT_NAME Documentation is incomplete
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2631>
__________________________________

From report at bugs.python.org  Mon Apr 14 20:30:16 2008
From: report at bugs.python.org (Curt Hagenlocher)
Date: Mon, 14 Apr 2008 18:30:16 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>


New submission from Curt Hagenlocher <curt at hagenlocher.org>:

First reported by Ralf Schmitt.
I haven't checked 2.6 or 3.0.

----------
components: Library (Lib)
files: socket.py.diff
keywords: patch
messages: 65472
nosy: CurtHagenlocher
severity: normal
status: open
title: socket._fileobject.read(n) should ignore _rbufsize when 1
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10029/socket.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 14 20:33:26 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 14 Apr 2008 18:33:26 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208198006.08.0.538500916015.issue2632@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

The relevant python-dev thread is
http://mail.python.org/pipermail/python-dev/2008-April/078613.html

----------
nosy: +draghuram

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 14 20:33:34 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Apr 2008 18:33:34 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1208198013.97.0.737065306972.issue1751@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Do I need to look at this, or is the review going well without my
interference?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________

From report at bugs.python.org  Mon Apr 14 20:48:27 2008
From: report at bugs.python.org (Mike Coleman)
Date: Mon, 14 Apr 2008 18:48:27 +0000
Subject: [issue852532] ^$ won't split on empty line
Message-ID: <1208198907.86.0.673750788006.issue852532@psf.upfronthosting.co.za>


Mike Coleman <mkc at users.sourceforge.net> added the comment:

I'd feel better about this bug being 'wont fix'ed if I had a sense that
several people considered the patch and thought that it sucked.  At the
moment, it seems more like it just fell off of the end without ever
being seriously contemplated.  :-(

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue852532>
____________________________________

From report at bugs.python.org  Mon Apr 14 20:53:39 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Mon, 14 Apr 2008 18:53:39 +0000
Subject: [issue1751] Fast BytesIO implementation + misc changes
In-Reply-To: <1199690432.25.0.839683390385.issue1751@psf.upfronthosting.co.za>
Message-ID: <1208199219.26.0.909408527418.issue1751@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Hi Guido,

The patch changes a minor things to io.py to allow io.BytesIO to pass my
test suite, so you may want to check it out. Other than that, I think
the review is going fine.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1751>
__________________________________

From report at bugs.python.org  Mon Apr 14 20:59:35 2008
From: report at bugs.python.org (=?utf-8?q?Gerhard_H=C3=A4ring?=)
Date: Mon, 14 Apr 2008 18:59:35 +0000
Subject: [issue2277] MozillaCookieJar does not support Firefox3 cookie files
In-Reply-To: <1205310956.06.0.761612370729.issue2277@psf.upfronthosting.co.za>
Message-ID: <1208199575.49.0.989552153993.issue2277@psf.upfronthosting.co.za>


Changes by Gerhard H?ring <gh at ghaering.de>:


----------
nosy: +ghaering

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2277>
__________________________________

From report at bugs.python.org  Mon Apr 14 21:18:59 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Apr 2008 19:18:59 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208200739.76.0.41537350931.issue2603@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Once the review for this is completed I have no objection to it going in.

----------
nosy: +gvanrossum

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Mon Apr 14 22:04:59 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 14 Apr 2008 20:04:59 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <1208189644.84.0.297738033249.issue1628484@psf.upfronthosting.co.za>
Message-ID: <4803B8E6.7000905@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> This is what you get when you try to build a 64-bit Python on a biarch
> machine (64-bit kernel, 32-bit userspace), using a gcc that generates
> natively 32-bit objects (therefore, you *must* pass the '-m64' option
> for the compiler):

Or you install an additional, different, C compiler that defaults to
AMD64.

> 1) As you could see above, actually you need CFLAGS in order to compile
> Python correctly. As far as I could investigate, the reason you need
> this is because of the tests that are done by configure. Without the
> CFLAGS, configure will think it's building a 32-bit Python, despite of
> the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
> through Makefile or not? IMHO, we do.

Not necessarily. I think you can achieve the same effect by specifying
CC="gcc -m64" to configure.

> 2) Even with CFLAGS and BASECFLAGS set, the compilation fails. Using
> LDFLAGS makes the compilation process continue a little more, but it
> still doesn't solve the problem. AFAIK, the reason it doesn't solve the
> problem is, again, because we are not propagating it through the
> Makefile. Can you see any different reason? Also, should we propagate
> LDFLAGS through Makefile? IMHO, we should.

Again, if you specify CC as above, you don't have to.

> Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
> But again, I don't think this is a solution for this issue :-).

Why not?

Regards,
Martin

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________

From report at bugs.python.org  Mon Apr 14 22:06:23 2008
From: report at bugs.python.org (Michael Amrhein)
Date: Mon, 14 Apr 2008 20:06:23 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1208203583.31.0.489624722841.issue1738@psf.upfronthosting.co.za>


Michael Amrhein <mamrhein at users.sourceforge.net> added the comment:

> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
...
> 
> '*' is a perfectly legal filename character on most filesystems
> 
Oops! Never thought of putting a '*' into a file name.
Obviously, I should have tried before ...

Ok, then I agree that, for not breaking existing code, the match
function should default to string comparison.
I'll provide a second revised patch in the next days.
And, I'll chain ignore and hide, as you proposed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
__________________________________

From report at bugs.python.org  Mon Apr 14 22:38:47 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Apr 2008 20:38:47 +0000
Subject: [issue1683368] object.__init__ shouldn't allow args/kwds
Message-ID: <1208205527.67.0.802809873146.issue1683368@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1683368>
_____________________________________

From report at bugs.python.org  Mon Apr 14 22:44:37 2008
From: report at bugs.python.org (Roy Smith)
Date: Mon, 14 Apr 2008 20:44:37 +0000
Subject: [issue2633] Improve subprocess.Popen() documentation ("env" parameter)
In-Reply-To: <1208205877.08.0.141694096579.issue2633@psf.upfronthosting.co.za>
Message-ID: <1208205877.08.0.141694096579.issue2633@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

http://docs.python.org/lib/node528.html (17.1.1 Using the subprocess 
Module) describes the "env" parameter thusly:

If env is not None, it defines the environment variables for the new 
process.

This is too vague to be useful.  If it's not None, what should it be?  A 
dictionary in the style of os.environ?  A sequence of name/value pairs?  A 
string with some sort of delimiter between each entry?

----------
assignee: georg.brandl
components: Documentation
messages: 65480
nosy: georg.brandl, roysmith
severity: normal
status: open
title: Improve subprocess.Popen() documentation ("env" parameter)
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2633>
__________________________________

From report at bugs.python.org  Mon Apr 14 22:53:05 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Mon, 14 Apr 2008 20:53:05 +0000
Subject: [issue2535] duplicate Misc.lower
In-Reply-To: <1207132804.52.0.0603076560404.issue2535@psf.upfronthosting.co.za>
Message-ID: <1208206385.73.0.263985557615.issue2535@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
keywords: +easy

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2535>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:07:39 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 21:07:39 +0000
Subject: [issue1092502] Memory leak in socket.py on Mac OS X
Message-ID: <1208207259.29.0.824659012419.issue1092502@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Well, I think the right thing to do is limit the maximal size to be read
inside the c function (just to make it impossible to pass around large
values). This is basically the same fix just at another place in the code.


http://twistedmatrix.com/trac/ticket/1079 describes the same problem
(but with 64 k read requests: it can even leak with small requests).
The fix there was to really copy those strings around into a StringIO
object.

Note that the code does not read byte by byte when passing in no size
argument. Instead it read recv_size bytes:

            if self._rbufsize <= 1:
                recv_size = self.default_bufsize
            else:
                recv_size = self._rbufsize

This seems clearly wrong to me.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092502>
_____________________________________

From report at bugs.python.org  Mon Apr 14 23:10:18 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 21:10:18 +0000
Subject: [issue1092502] Memory leak in socket.py on Mac OS X
Message-ID: <1208207418.31.0.00378620286476.issue1092502@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

that is it seems wrong that it uses 1 byte when a size is given, and
recv_size when size is not given.

By the way I think if you ask for 4096 bytes and the buffering is set to
2048 bytes it should still try to read the full 4096 bytes.
The number of bytes it tries to read however. should be limited by
whatever the system maximally returns.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092502>
_____________________________________

From report at bugs.python.org  Mon Apr 14 23:20:12 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 14 Apr 2008 21:20:12 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208208012.28.0.331510975647.issue2630@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

What if we turn on the backslashreplace trick for some operations only?
For example: sys_displayhook and sys_excepthook.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:42:00 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 21:42:00 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208209320.5.0.79741116705.issue2632@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:48:36 2008
From: report at bugs.python.org (John Jackson)
Date: Mon, 14 Apr 2008 21:48:36 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1208209716.67.0.393213737399.issue2622@psf.upfronthosting.co.za>


John Jackson <johnjackson at pobox.com> added the comment:

Attached is a sample code that reproduces the problem under python 2.5 on 
Mac OS 10.4.11. See file for instructions on how to reproduce the issue.

Added file: http://bugs.python.org/file10030/test_mailbox.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:49:44 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 21:49:44 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208209784.89.0.845394793073.issue2632@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

One more time: the change is wrong. It should try to recv the maximum
not the minimum of size, buffer_size. If you using a buffering of 16
bytes it will otherwise call recv 256 times when you want to read 1024
bytes. this is wrong.
However there should be an upper limit, it doesn't make sense to read
10MB from socket in one recv call (imap bug).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:50:00 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 21:50:00 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208209800.62.0.799298844658.issue2632@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:51:03 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Mon, 14 Apr 2008 21:51:03 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208209863.44.0.169536975602.issue2632@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
priority:  -> critical

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:51:30 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 21:51:30 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208209890.77.0.285090793322.issue2632@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

akuchling, I added you to the nosy list. hope that's ok.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 14 23:52:18 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 21:52:18 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208209938.85.0.962215705498.issue2632@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 15 00:10:24 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Apr 2008 22:10:24 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208211024.91.0.130894232394.issue2632@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

This is apparently the same issue as #2601.

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 15 00:11:04 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 14 Apr 2008 22:11:04 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208211064.9.0.209659885892.issue2601@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

See #2632 for more discussion of what is probably the same issue.

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Tue Apr 15 00:47:31 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 22:47:31 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208213251.66.0.683863345873.issue2601@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Tue Apr 15 00:59:40 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 14 Apr 2008 22:59:40 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208213980.74.0.116707308993.issue2632@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

ahh. yes, same issue. should have taken a look at the bugtracker before,
would have saved me some time...

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 15 01:11:54 2008
From: report at bugs.python.org (Trent Nelson)
Date: Mon, 14 Apr 2008 23:11:54 +0000
Subject: [issue2609] Tests fail if ./@test is not writeable
In-Reply-To: <1207846870.93.0.178479630911.issue2609@psf.upfronthosting.co.za>
Message-ID: <1208214714.47.0.660109558509.issue2609@psf.upfronthosting.co.za>


Changes by Trent Nelson <tnelson at onresolve.com>:


----------
assignee:  -> Trent.Nelson
nosy: +Trent.Nelson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2609>
__________________________________

From report at bugs.python.org  Tue Apr 15 03:40:27 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Tue, 15 Apr 2008 01:40:27 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208223627.31.0.909635757536.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

>  I think this has potential, but it is too liberal. There are many more
>  characters that cannot be assumed printable, e.g. many of the Latin-1
>  characters in the range 0x80 through 0x9F.  Isn't there some Unicode
>  data table that shows code points that are safely printable?

As Michael Urman pointed out, we can use Unicode properties. 
Or we can define a set of non-printable characters (e.g.
sys.nonprintablechars).

>  OTOH there are other potential use cases where it would be nice to see
>  the \u escapes, e.g. when one is concerned about sequences that print
>  the same but don't have the same content (e.g. pre-normalization).

For such cases, print(s.encode("ascii", "backslashreplace")) might work.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Tue Apr 15 03:48:46 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Tue, 15 Apr 2008 01:48:46 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208224126.86.0.315421785671.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

>  What if we turn on the backslashreplace trick for some operations only?
>  For example: sys_displayhook and sys_excepthook.

It would be difficult, since *_repr() API don't know who is the caller.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Tue Apr 15 04:01:50 2008
From: report at bugs.python.org (Bob Atkins)
Date: Tue, 15 Apr 2008 02:01:50 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <4803B8E6.7000905@v.loewis.de>
Message-ID: <48040C86.8090908@digilink.net>


Bob Atkins <bob at digilink.net> added the comment:

Martin,

I've been quietly reading all of the back and forth regarding this problem.

Your suggestion for using the CC variable to fix the problem that I 
reported won't work - I already tried it and based on what others are 
reporting, you are beating a dead horse. Believe me I would rather not 
modify anyone's code in order to build something. The problem is that 
the CC variable doesn't fix the link stages and overall your autconf 
build is broken particularly as it relates to flowing variables down to 
sub builds.

I don't know why you are resisting this change. I took the time to 
report the bug, proposed a fix /_*and*_/ contributed the patch that 
would make the Python build process more standard relative to the vast 
majority of open source packages that use autoconf. I am glad to see 
that my patch appears to be generic enough that it works on other 
platforms as well. I didn't have to post a bug report let alone 
contribute a patch but, I believe strongly that is what open source is 
all about. As the maintainer you don't have to accept either the bug or 
the patch but, resisting without good cause will discourage further 
contributions - certainly from me because I won't waste my time 
submitting something when I know that a maintainer of a package is being 
closed minded. We do a lot of work with open source software here and it 
is our policy to contribute back to the community as much as possible. 
However, when we run into a brick wall we quickly give up because we 
can't justify the time and effort. As an example, we have completely 
suspended all contributions to the asterisk project. We operate a very 
large asterisk environment with a lot of fixes and improvements that I 
am sure lots of others would love to have but the maintainer's attitude 
was that a Sun Solaris platform was not important. What the maintainer 
doesn't know is that many of our fixes and changes affect /_*all*_/ 
platforms. So now they get nothing from us and the asterisk community as 
a whole is deprived of the benefits of our work. I also know that many 
others have also suspended contributions for the same reason and as a 
result the asterisk package suffers. The resistance on your part to 
recognizing this problem and a fix is unjustified.

Overall it improves the Python package if it can be built on more 
platforms in different ways - especially if it uses the standard 
autoconf approach that the majority of other open source packages use. 
Those of us that have to deal with building almost a hundred different 
packages for different platforms and architectures very much appreciate 
not having to deal with unnecessary exceptions or idiosyncrasies.

I don't care whether you incorporate the change or not - we certainly 
will continue to patch future versions of Python (we have a fully 
automated build process here) in order to produce a successful build. 
Clearly the genie is out of the bottle and others will also likely use 
the patch for their builds. Why not just make everyone happy and 
incorporate it or a reasonably similar approach that properly implements 
the flow of /_*all*_/ autoconf variables to the sub-builds of the Python 
package so that more people can take full advantage of Python on their 
64 bit platforms and also deal with whatever unique build requirements 
that they might have.

Sincerely,
Bob Atkins

Martin v. L?wis wrote:

>Martin v. L?wis <martin at v.loewis.de> added the comment:
>
>  
>
>>This is what you get when you try to build a 64-bit Python on a biarch
>>machine (64-bit kernel, 32-bit userspace), using a gcc that generates
>>natively 32-bit objects (therefore, you *must* pass the '-m64' option
>>for the compiler):
>>    
>>
>
>Or you install an additional, different, C compiler that defaults to
>AMD64.
>
>  
>
>>1) As you could see above, actually you need CFLAGS in order to compile
>>Python correctly. As far as I could investigate, the reason you need
>>this is because of the tests that are done by configure. Without the
>>CFLAGS, configure will think it's building a 32-bit Python, despite of
>>the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
>>through Makefile or not? IMHO, we do.
>>    
>>
>
>Not necessarily. I think you can achieve the same effect by specifying
>CC="gcc -m64" to configure.
>
>  
>
>>2) Even with CFLAGS and BASECFLAGS set, the compilation fails. Using
>>LDFLAGS makes the compilation process continue a little more, but it
>>still doesn't solve the problem. AFAIK, the reason it doesn't solve the
>>problem is, again, because we are not propagating it through the
>>Makefile. Can you see any different reason? Also, should we propagate
>>LDFLAGS through Makefile? IMHO, we should.
>>    
>>
>
>Again, if you specify CC as above, you don't have to.
>
>  
>
>>Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
>>But again, I don't think this is a solution for this issue :-).
>>    
>>
>
>Why not?
>
>Regards,
>Martin
>
>_____________________________________
>Tracker <report at bugs.python.org>
><http://bugs.python.org/issue1628484>
>_____________________________________
>
>
>  
>

Added file: http://bugs.python.org/file10031/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080415/c5bdf715/attachment.txt 

From report at bugs.python.org  Tue Apr 15 05:10:14 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Apr 2008 03:10:14 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208229014.43.0.181948808786.issue2630@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Atsuo: I missed Michael Urman's comment.  Can you copy it here, or
(better :-) write a patch that uses it?

Amaury: I think it would be okay to use backslashreplace as the default
error handler for sys.stderr.  Probably not for sys.stdout or other
files, since I'm sure many users prefer the errors when their data
cannot be printed rather than silently writing \u escapes that might
cause other code reading their output to choke.  For sys.stderr though I
think not having exceptions raised when attempting to print errors is
very valuable.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Tue Apr 15 05:35:10 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Tue, 15 Apr 2008 03:35:10 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208230510.52.0.94076461187.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

Okay, I'll revise a patch later today.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Tue Apr 15 06:09:17 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 15 Apr 2008 04:09:17 +0000
Subject: [issue2611] Extend buildbot web interface to allow for forced tests
	to be run on a slave in verbose mode.
In-Reply-To: <1207895484.64.0.813690522002.issue2611@psf.upfronthosting.co.za>
Message-ID: <ee2a432c0804142109r3b9f6166gdc24c5cbeb901d17@mail.gmail.com>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

>  I think this will be fairly difficult to set up. If the clean buildstep
>  had been executed, you would have to rerun configure and compile before
>  you can run any tests.

We could re-order and do clean first.  That would leave all the build
artifacts in tact after a build which would be nice for some
debugging.

>  Also, how would you communicate what specific test you want to run?

I agree here.  My guess is it would be pretty hard to modify the
buildbot to support this.  I don't have bandwidth to help.  It would
be nice to have, but probably not a high priority.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2611>
__________________________________

From report at bugs.python.org  Tue Apr 15 06:31:47 2008
From: report at bugs.python.org (Roy Smith)
Date: Tue, 15 Apr 2008 04:31:47 +0000
Subject: [issue2634] os.execvpe() docs need to be more specific
In-Reply-To: <1208233905.92.0.0192378489654.issue2634@psf.upfronthosting.co.za>
Message-ID: <1208233905.92.0.0192378489654.issue2634@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

Note: this is (sort of) related to Issue2633.

http://docs.python.org/lib/os-process.html (14.1.5 Process Management).

The docs for os.execvpe() say, "the env parameter must be a mapping which 
is used to define the environment variables for the new process".  It's 
not clear if this mapping replaces the existing environment, or defines 
additional entries which are added to the existing environment.  This 
should be clarified.

This applies to the spawn*() methods too.

----------
assignee: georg.brandl
components: Documentation
messages: 65496
nosy: georg.brandl, roysmith
severity: normal
status: open
title: os.execvpe() docs need to be more specific
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2634>
__________________________________

From report at bugs.python.org  Tue Apr 15 07:09:25 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 Apr 2008 05:09:25 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <48040C86.8090908@digilink.net>
Message-ID: <48043880.1040106@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Your suggestion for using the CC variable to fix the problem that I 
> reported won't work - I already tried it and based on what others are 
> reporting, you are beating a dead horse. Believe me I would rather not 
> modify anyone's code in order to build something. The problem is that 
> the CC variable doesn't fix the link stages

Why is that? It should work fine.

> and overall your autconf 
> build is broken particularly as it relates to flowing variables down to 
> sub builds.

This I don't understand. What is a sub build?

> I don't know why you are resisting this change. I took the time to 
> report the bug, proposed a fix /_*and*_/ contributed the patch that 
> would make the Python build process more standard relative to the vast 
> majority of open source packages that use autoconf.

I don't think that's the case. In autoconf, if you specify CFLAGS,
you expect that this overrides, not adds to, anything configure
computes on its own. This patch does not do that, i.e. it doesn't
allow you to override the settings that configure computes.

I'm concerned that the patch merely makes the entire setup more
complex, rather than solving an actual technical problem. That's
why I'm resisting to accept it.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________

From report at bugs.python.org  Tue Apr 15 07:13:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 Apr 2008 05:13:28 +0000
Subject: [issue2611] Extend buildbot web interface to allow for forced tests
	to be run on a slave in verbose mode.
In-Reply-To: <ee2a432c0804142109r3b9f6166gdc24c5cbeb901d17@mail.gmail.com>
Message-ID: <48043972.5080506@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> We could re-order and do clean first.  That would leave all the build
> artifacts in tact after a build which would be nice for some
> debugging.

With the current setup, that wouldn't quite work. We can't run it before
configure, because we might have no Makefile to invoke the clean target,
and we can't run it after configure, as we run "make distclean", which
deletes the makefile.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2611>
__________________________________

From report at bugs.python.org  Tue Apr 15 07:24:24 2008
From: report at bugs.python.org (Curt Hagenlocher)
Date: Tue, 15 Apr 2008 05:24:24 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208237064.48.0.166346677912.issue2632@psf.upfronthosting.co.za>


Curt Hagenlocher <curt at hagenlocher.org> added the comment:

I've attached a much better patch as suggested by Guido

Added file: http://bugs.python.org/file10032/socket.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 15 07:24:32 2008
From: report at bugs.python.org (Curt Hagenlocher)
Date: Tue, 15 Apr 2008 05:24:32 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208237072.49.0.245536200693.issue2632@psf.upfronthosting.co.za>


Changes by Curt Hagenlocher <curt at hagenlocher.org>:


Removed file: http://bugs.python.org/file10029/socket.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 15 07:42:16 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 15 Apr 2008 05:42:16 +0000
Subject: [issue2632] socket._fileobject.read(n) should ignore _rbufsize when 1
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208238136.77.0.648343053408.issue2632@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

This patch handles the case where the caller has specified the size
argument. When size is unspecified, it should be handled as if size was
infinite. By the formula from your patch, this should be

 recv_size = min(self.max_readsize, max(self._rbufsize, left))
  (== min(self.max_readsize, inf) == self.max_readsize)

and not the current code:
            if self._rbufsize <= 1:
                recv_size = self.default_bufsize
            else:
                recv_size = self._rbufsize
            while True:
                data = self._sock.recv(recv_size)

BTW,  I still think this max_readsize limit should be handled somewhere
deeper in the code. at least maybe in the _socketobject class.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 15 07:50:29 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 Apr 2008 05:50:29 +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: <1208238629.05.0.12173908563.issue2122@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
keywords: +patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
__________________________________

From report at bugs.python.org  Tue Apr 15 07:54:45 2008
From: report at bugs.python.org (Giuseppe Scelsi)
Date: Tue, 15 Apr 2008 05:54:45 +0000
Subject: [issue2635] textwrap: bug in 'fix_sentence_endings' option
In-Reply-To: <1208238885.76.0.507566596531.issue2635@psf.upfronthosting.co.za>
Message-ID: <1208238885.76.0.507566596531.issue2635@psf.upfronthosting.co.za>


New submission from Giuseppe Scelsi <giuseppe.scelsi at analog.com>:

>>> textwrap.fill('File stdio.h is nice.',
...     fix_sentence_endings=True)
'File stdio.h  is nice.'
              ^-- wrong double space!

The problem is with the compiled regexp 'sentence_end_re' in
'textwrap.py'.  A possible fix would be to add the following line after
line 90 in textwrap.py:

    r'$'  # end of chunk

Giuseppe

----------
components: Library (Lib)
messages: 65501
nosy: gscelsi
severity: normal
status: open
title: textwrap: bug in 'fix_sentence_endings' option
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2635>
__________________________________

From report at bugs.python.org  Tue Apr 15 07:56:19 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 15 Apr 2008 05:56:19 +0000
Subject: [issue2235] __eq__ / __hash__ check doesn't take inheritance into
	account
In-Reply-To: <1204660164.8.0.960033908954.issue2235@psf.upfronthosting.co.za>
Message-ID: <1208238979.43.0.0543026511673.issue2235@psf.upfronthosting.co.za>


Changes by Neal Norwitz <nnorwitz at gmail.com>:


----------
assignee: amaury.forgeotdarc -> gvanrossum

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2235>
__________________________________

From report at bugs.python.org  Tue Apr 15 08:09:36 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 15 Apr 2008 06:09:36 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1208239776.35.0.365046247938.issue2541@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

What is the status of this bug?  AFAICT, the code is now correct.  Have
the doc changes been applied?  The resolution on this report should be
updated too.  It's currently rejected.

----------
nosy: +nnorwitz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2541>
__________________________________

From report at bugs.python.org  Tue Apr 15 08:11:50 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Tue, 15 Apr 2008 06:11:50 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208239910.6.0.411206739588.issue2601@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

Bumping the priority.  I'd like to see this fixed before the next
release.  What version(s) does this problem apply to: 2.5, 2.6, 3.0?

----------
nosy: +nnorwitz
priority: critical -> release blocker

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Tue Apr 15 08:21:50 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 15 Apr 2008 06:21:50 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208240510.17.0.90169354718.issue2601@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

quoting http://bugs.python.org/issue1389051: "Applied to 2.6 trunk in
rev. 61008 and to 2.5-maint in rev. 61009."

I don't know about py3k...

----------
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Tue Apr 15 09:16:59 2008
From: report at bugs.python.org (Andrew McNamara)
Date: Tue, 15 Apr 2008 07:16:59 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1208243819.34.0.482317067343.issue1225769@psf.upfronthosting.co.za>


Andrew McNamara <andrewm at object-craft.com.au> added the comment:

I think it's a reasonable enough request - I've certainly had to 
process CSV files with comments. Iain - appologies for not looking at 
your request before now - 3 years is a pretty poor response time.

Some thoughts:
 * this should target 2.6, not 2.5 (as 2.5 is in maintenance only)?
 * the check that disallows "space" - I wonder what other things it 
should disallow - the delimiter?
 * should it support multicharacter comments, like the C++ //-style 
comment? I think no.
 * any implications for the py3k port?

Skip - are you happy making the changes, or should I dust off my 
working copy?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_____________________________________

From report at bugs.python.org  Tue Apr 15 10:01:51 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 15 Apr 2008 08:01:51 +0000
Subject: [issue1225769] Proposal to implement comment rows in csv module
Message-ID: <1208246511.84.0.21618831888.issue1225769@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

-1 on the change.  Comments in CSV files are not a common use case.  
I'm less worried about cluttering the C code and more concerned about 
cluttering the API, making the module harder to learn and remember.

Also, it is already trivial to implement filtering using str.startswith
().  This proposed patch is not worth the rare case where it saves a 
line or two code that was already crystal clear.

----------
nosy: +rhettinger

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1225769>
_____________________________________

From report at bugs.python.org  Tue Apr 15 10:21:52 2008
From: report at bugs.python.org (Bob Atkins)
Date: Tue, 15 Apr 2008 08:21:52 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <48043880.1040106@v.loewis.de>
Message-ID: <4804659A.1050007@digilink.net>


Bob Atkins <bob at digilink.net> added the comment:

Martin,

Martin v. L?wis wrote:

It does not when link stage specific options are required that are not 
valid for compilation stages.

My mistake. I was thinking of another package - you can scratch that 
comment.

There is no hard and fast rule that specifying the CFLAGS or other 
configure variables have to override /_*all*_/ of the compile flags that 
a developer chooses to use in their build process. Most open source 
packages use the configure CFLAGS, LDFLAGS, etc, variables to add to the 
compile and link flags and not completely override them. My patch 
follows the same philosophy that I have seen in the majority of other 
open source packages.

On the contrary - it does /_*not*_/ make it more complex and it 
/_*does*_/ provide a solution to a number of compile and link failures 
that have been reported over and over again. When I first posted this 
bug I read through the various forums and bug reports and I noticed 
quite a bit of complaining regarding this issue and I acknowledged that 
by noting in my report that what I was opening a bug report on what was 
clearly a sore subject within the Python community. To be specific the 
complaints were regarding the symptoms (unusual compile and link 
problems) related to this issue, not the specific cause of the problem 
which is why I filed the bug as I did.

The patch that I submitted will allow a build of Python to be performed 
the /_exact_/ same way it is today without any modifications to CFLAGS 
or LDFLAGS, etc. Those of us that /need/ to use these variables will be 
able to modify the build options to the configure script as necessary 
/_*without*_/ any complexity and without losing 'important' compile 
options that are currently generated by configure. All of your 
suggestions to use the CC variable in lieu of using the more appropriate 
CFLAGS, LDFLAGS, etc., introduce the very complexity and non-standard 
approach you are claiming you want top avoid.

Again, I don't see what your concerns are. My patch is a completely 
non-affecting change to the way Python is built today /_*but*_/ it does 
add the necessary fixes so that those that require specific compile and 
link options can specify them to the configure script.

In addition, while you are fixing the build/compile options, I noticed 
that you are missing the -fPIC compile option. Without it you can't link 
shared libraries and the build fails. You should probably be including 
-fPIC as a standard compile option so it is not required to be passed 
into the build via the configure script.

---
Bob

Added file: http://bugs.python.org/file10033/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080415/dd7607dd/attachment.txt 

From report at bugs.python.org  Tue Apr 15 11:49:22 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Apr 2008 09:49:22 +0000
Subject: [issue2439] Patch to add a get_data function to pkgutil
In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za>
Message-ID: <1208252962.11.0.7036131835.issue2439@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

I should be able to review/commit this for the next alpha (looking into
it right now).

----------
assignee:  -> ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2439>
__________________________________

From report at bugs.python.org  Tue Apr 15 12:20:00 2008
From: report at bugs.python.org (Paul Moore)
Date: Tue, 15 Apr 2008 10:20:00 +0000
Subject: [issue2439] Patch to add a get_data function to pkgutil
In-Reply-To: <1208252962.11.0.7036131835.issue2439@psf.upfronthosting.co.za>
Message-ID: <79990c6b0804150319o5848e84dt10d8ad35e60e6365@mail.gmail.com>


Paul Moore <p.f.moore at gmail.com> added the comment:

Thanks,
Paul.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2439>
__________________________________

From report at bugs.python.org  Tue Apr 15 12:26:35 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Apr 2008 10:26:35 +0000
Subject: [issue2439] Patch to add a get_data function to pkgutil
In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za>
Message-ID: <1208255195.4.0.89835371057.issue2439@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Commited as rev 62350

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2439>
__________________________________

From report at bugs.python.org  Tue Apr 15 12:28:51 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 15 Apr 2008 10:28:51 +0000
Subject: [issue2439] Patch to add a get_data function to pkgutil
In-Reply-To: <1206046713.54.0.393035413153.issue2439@psf.upfronthosting.co.za>
Message-ID: <1208255331.61.0.236757710964.issue2439@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Test file added in rev 62351 (forgot to svn add it the first time around)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2439>
__________________________________

From report at bugs.python.org  Tue Apr 15 13:51:26 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Apr 2008 11:51:26 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1208260286.39.0.56443738812.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It's rejected because the OP wanted unicode escapes to be applied in
unicode strings, and I haven't applied the docs because nobody has told
me I should.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2541>
__________________________________

From report at bugs.python.org  Tue Apr 15 13:57:52 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Tue, 15 Apr 2008 11:57:52 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>


New submission from Jeffrey C. Jacobs <timehorse at users.sourceforge.net>:

I am working on adding features to the current Regexp implementation,
which is now set to 2.2.2.  These features are to bring the Regexp code
closer in line with Perl 5.10 as well as add a few python-specific
niceties and potential speed-ups and clean-ups.

I will be posting regular patch updates to this thread when major
milestones have been reach with a description of the feature(s) added. 
Currently, the list of proposed changes are (in no particular order):

1) Fix <a href="http://bugs.python.org/issue433030">issue 433030</a> by
adding support for Atomic Grouping and Possessive Qualifiers

2) Make named matches direct attributes of the match object; i.e.
instead of m.group('foo'), one will be able to write simply m.foo.

3) (maybe) make Match objects subscriptable, such that m[n] is
equivalent to m.group(n) and allow slicing.

4) Implement Perl-style back-references including relative back-references.

5) Add a well-formed, python-specific comment modifier, e.g. (?P#...);
the difference between (?P#...) and Perl/Python's (?#...) is that the
former will allow nested parentheses as well as parenthetical escaping,
so that patterns of the form '(?P# Evaluate (the following) expression,
3\) using some other technique)'.  The (?P#...) will interpret this
entire expression as a comment, where as with (?#...) only, everything
following ' expression...' would be considered part of the match. 
(?P#...) will necessarily be slower than (?#...) and so only should be
used if richer commenting style is required but the verbose mode is not
desired.

6) Add official support for fast, non-repeating capture groups with the
Template option.  Template is unofficially supported and disables all
repeat operators (*, + and ?).  This would mainly consist of documenting
its behavior.

7) Modify the re compiled expression cache to better handle the
thrashing condition.  Currently, when regular expressions are compiled,
the result is cached so that if the same expression is compiled again,
it is retrieved from the cache and no extra work has to be done.  This
cache supports up to 100 entries.  Once the 100th entry is reached, the
cache is cleared and a new compile must occur.  The danger, all be it
rare, is that one may compile the 100th expression only to find that one
recompiles it and has to do the same work all over again when it may
have been done 3 expressions ago.  By modifying this logic slightly, it
is possible to establish an arbitrary counter that gives a time stamp to
each compiled entry and instead of clearing the entire cache when it
reaches capacity, only eliminate the oldest half of the cache, keeping
the half that is more recent.  This should limit the possibility of
thrashing to cases where a very large number of Regular Expressions are
continually recompiled.  In addition to this, I will update the limit to
256 entries, meaning that the 128 most recent are kept.

8) Emacs/Perl style character classes, e.g. [:alphanum:].  For instance,
:alphanum: would not include the '_' in the character class.

9) C-Engine speed-ups.  I commenting and cleaning up the _sre.c Regexp
engine to make it flow more linearly, rather than with all the current
gotos and replace the switch-case statements with lookup tables, which
in tests have shown to be faster.  This will also include adding many
more comments to the C code in order to make it easier for future
developers to follow.  These changes are subject to testing and some
modifications may not be included in the final release if they are shown
to be slower than the existing code.  Also, a number of Macros are being
eliminated where appropriate.

10) Export any (not already) shared value between the Python Code and
the C code, e.g. the default Maximum Repeat count (65536); this will
allow those constants to be changed in 1 central place.

11) Various other Perl 5.10 conformance modifications, TBD.


More items may come and suggestions are welcome.

-----

Currently, I have code which implements 5) and 7), have done some work
on 10) and am almost 9).  When 9) is complete, I will work on 1), some
of which, such as parsing, is already done, then probably 8) and 4)
because they should not require too much work -- 4) is parser-only
AFAICT.  Then, I will attempt 2) and 3), though those will require
changes at the C-Code level.  Then I will investigate what additional
elements of 11) I can easily implement.  Finally, I will write
documentation for all of these features, including 6).

In a few days, I will provide a patch with my interim results and will
update the patches with regular updates when Milestones are reached.

----------
components: Library (Lib)
messages: 65513
nosy: timehorse
severity: normal
status: open
title: Regexp 2.6 (modifications to current re 2.2.2)
type: feature request
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Tue Apr 15 14:19:59 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Tue, 15 Apr 2008 12:19:59 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208261999.31.0.884698170648.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

I revised a patch against Python 3.0a4.

- As-per suggestion from Michael Urman, unicode_repr() 
  refers unicode database to determine characters to be 
  hex-encoded.
  
- sys.stdout doesn't use 'backslashreplace'.

Added file: http://bugs.python.org/file10034/diff2.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Tue Apr 15 14:49:43 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 15 Apr 2008 12:49:43 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208263783.61.0.0433957057758.issue2636@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
nosy: +akuchling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Tue Apr 15 15:01:43 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Durigan_J=C3=BAnior?=)
Date: Tue, 15 Apr 2008 13:01:43 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <4803B8E6.7000905@v.loewis.de>
Message-ID: <1208264514.5817.3.camel@miki>


S?rgio Durigan J?nior <sergiodj at linux.vnet.ibm.com> added the comment:

Hi Martin,

On Mon, 2008-04-14 at 20:04 +0000, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> 
> > This is what you get when you try to build a 64-bit Python on a biarch
> > machine (64-bit kernel, 32-bit userspace), using a gcc that generates
> > natively 32-bit objects (therefore, you *must* pass the '-m64' option
> > for the compiler):
> 
> Or you install an additional, different, C compiler that defaults to
> AMD64.

I cannot do that. Actually, even if I could, I don't think this is the
best way to handle this *Python*'s problem.

> > 1) As you could see above, actually you need CFLAGS in order to compile
> > Python correctly. As far as I could investigate, the reason you need
> > this is because of the tests that are done by configure. Without the
> > CFLAGS, configure will think it's building a 32-bit Python, despite of
> > the '-m64' flag in BASECFLAGS. So, do we need to propagate CFLAGS
> > through Makefile or not? IMHO, we do.
> 
> Not necessarily. I think you can achieve the same effect by specifying
> CC="gcc -m64" to configure.

I know that. But the purpose of CC flag is to define a compiler to be
used in the compilation, and not to specify compiler flags (for that, we
have CFLAGS).

> > Ohh, before I forget: compilation succeeds if we use only CC='gcc -m64'.
> > But again, I don't think this is a solution for this issue :-).
> 
> Why not?

See above.

Regards,

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________

From report at bugs.python.org  Tue Apr 15 15:06:01 2008
From: report at bugs.python.org (=?utf-8?q?S=C3=A9rgio_Durigan_J=C3=BAnior?=)
Date: Tue, 15 Apr 2008 13:06:01 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <48040C86.8090908@digilink.net>
Message-ID: <1208264770.5817.9.camel@miki>


S?rgio Durigan J?nior <sergiodj at linux.vnet.ibm.com> added the comment:

On Tue, 2008-04-15 at 02:01 +0000, Bob Atkins wrote:

> I don't know why you are resisting this change. I took the time to 
> report the bug, proposed a fix /_*and*_/ contributed the patch that 
> would make the Python build process more standard relative to the vast 
> majority of open source packages that use autoconf. I am glad to see 
> that my patch appears to be generic enough that it works on other 
> platforms as well. I didn't have to post a bug report let alone 
> contribute a patch but, I believe strongly that is what open source is 
> all about. As the maintainer you don't have to accept either the bug or 
> the patch but, resisting without good cause will discourage further 
> contributions - certainly from me because I won't waste my time 
> submitting something when I know that a maintainer of a package is being 
> closed minded. We do a lot of work with open source software here and it 
> is our policy to contribute back to the community as much as possible. 
> However, when we run into a brick wall we quickly give up because we 
> can't justify the time and effort. As an example, we have completely 
> suspended all contributions to the asterisk project. We operate a very 
> large asterisk environment with a lot of fixes and improvements that I 
> am sure lots of others would love to have but the maintainer's attitude 
> was that a Sun Solaris platform was not important. What the maintainer 
> doesn't know is that many of our fixes and changes affect /_*all*_/ 
> platforms. So now they get nothing from us and the asterisk community as 
> a whole is deprived of the benefits of our work. I also know that many 
> others have also suspended contributions for the same reason and as a 
> result the asterisk package suffers. The resistance on your part to 
> recognizing this problem and a fix is unjustified.

Bob just took the words from my mouth. Martin, with all respect, your
resistance in accepting this patch is making things much harder that
they really are. The main point here is that this pacth actually
*doesn't* break anything in Python!

Please, take a time to consider our proposal.

Thanks,

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________

From report at bugs.python.org  Tue Apr 15 15:15:04 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 15 Apr 2008 13:15:04 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208265304.92.0.864743704466.issue2601@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

It was applied to 2.5-maint after 2.5.2 was released, BTW, so the change
isn't in any stable released version, only the 2.6 alphas.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Tue Apr 15 15:22:10 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Tue, 15 Apr 2008 13:22:10 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208265730.27.0.276708207519.issue2636@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
components: +Regular Expressions -Library (Lib)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Tue Apr 15 17:09:12 2008
From: report at bugs.python.org (Tim Lesher)
Date: Tue, 15 Apr 2008 15:09:12 +0000
Subject: [issue2637] urllib.quote() escapes characters unnecessarily and
	contrary to docs
In-Reply-To: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>
Message-ID: <1208272151.95.0.897886992301.issue2637@psf.upfronthosting.co.za>


New submission from Tim Lesher <tlesher at gmail.com>:

The urllib.quote docstring implies that it quotes only characters in RFC
2396's "reserved" set.

However, urllib.quote currently escapes all characters except those in
an "always_safe" list, which consists of alphanumerics and three
punctuation characters, "_.-".

This behavior is contrary to the RFC, which defines "unreserved"
characters as alphanumerics plus "mark" characters, or "-_.!~*'()".  

The RFC also says:

  Unreserved characters can be escaped without changing the semantics
  of the URI, but this should not be done unless the URI is being used
  in a context that does not allow the unescaped character to appear.

This seems to imply that "always_safe" should correspond to the RFC's
"unreserved" set of "alphanum" | "mark".

----------
components: Library (Lib)
messages: 65518
nosy: tlesher
severity: normal
status: open
title: urllib.quote() escapes characters unnecessarily and contrary to docs
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2637>
__________________________________

From report at bugs.python.org  Tue Apr 15 17:24:03 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Tue, 15 Apr 2008 15:24:03 +0000
Subject: [issue1092502] Memory leak in socket.py on Mac OS X
Message-ID: <1208273043.68.0.204307871313.issue1092502@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092502>
_____________________________________

From report at bugs.python.org  Tue Apr 15 17:44:13 2008
From: report at bugs.python.org (Ron Longo Work)
Date: Tue, 15 Apr 2008 15:44:13 +0000
Subject: [issue2638] tkSimpleDialog Window Flashing
In-Reply-To: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>
Message-ID: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>


New submission from Ron Longo Work <longorh at npt.nuwc.navy.mil>:

When a Tkinter window comes up that uses tkSimpleDialog to construct a 
dialog box, the window first flashes on the screen as an unpopulated 
top-level window, before being drawn in its completed state.

This problem is easily corrected by adding two lines of code to the 
constructor for class Dialog in tkSimpleDialog.py.  The first line of 
the constructor reads Toplevel.__init__( self, parent ).  After this 
line insert self.overrideredirect( True ).  The second line from the 
last in this constructor reads self.initial_focus.focus_set(), just 
before this line insert self.overrideredirect( False).  That's it.  
I've attached the revised version of this file.

----------
components: Tkinter
files: tkSimpleDialog.py
messages: 65519
nosy: Longorh
severity: normal
status: open
title: tkSimpleDialog Window Flashing
versions: Python 2.5
Added file: http://bugs.python.org/file10035/tkSimpleDialog.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2638>
__________________________________

From report at bugs.python.org  Tue Apr 15 17:47:16 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 15 Apr 2008 15:47:16 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208274436.81.0.619450285469.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch does not add unit tests for hash(range(..)).  I would actually 
test that hash(range(a,b,c)) == hash((a,b,c)) for various values of a, 
b,  and c.

A nit-pick: while I personally like the coding style with line breaks 
before binary ops, python C style appears to be the opposite.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Tue Apr 15 18:11:07 2008
From: report at bugs.python.org (Roy Smith)
Date: Tue, 15 Apr 2008 16:11:07 +0000
Subject: [issue2639] shutil.copyfile() documentation is vague
In-Reply-To: <1208275866.73.0.43584708825.issue2639@psf.upfronthosting.co.za>
Message-ID: <1208275866.73.0.43584708825.issue2639@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

The current doc says, "Copy the contents of the file named src to a file 
named dst".  Anybody used to the unix shell "cp" command would assume that 
dst could be a directory, in which case the true destination is a file in 
that directory with the same basename as src.  Experimentation shows that 
this is not true.  A note something like the following would help:

Note: unlike the "cp" shell command, dst may not be a directory; it must 
be a path to a file in that directory.

True, there's no place in the docs which actually says a directory is 
valid for dst, but the name of the module is shutil, so it's reasonable 
for people to assume that these act the same way as the corresponding unix 
shell commands.  It should be stated up front that this is not true, to 
avoid confusion.

----------
assignee: georg.brandl
components: Documentation
messages: 65521
nosy: georg.brandl, roysmith
severity: normal
status: open
title: shutil.copyfile() documentation is vague
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2639>
__________________________________

From report at bugs.python.org  Tue Apr 15 18:24:44 2008
From: report at bugs.python.org (Roy Smith)
Date: Tue, 15 Apr 2008 16:24:44 +0000
Subject: [issue2639] shutil.copyfile() documentation is vague
In-Reply-To: <1208275866.73.0.43584708825.issue2639@psf.upfronthosting.co.za>
Message-ID: <1208276684.24.0.698895306945.issue2639@psf.upfronthosting.co.za>


Roy Smith <roy at panix.com> added the comment:

Reading closer, I see that copy() has the shell-like semantics I was 
expecting copyfile() to have.  Perhaps the right fix is to include a note in 
the copyfile() docs saying, "dst must be a file path; see also copy() for a 
version which allows dst to be a directory".

It might also make sense to move copy() to the top of the list, because it 
is the one which has the most shell-like semantics.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2639>
__________________________________

From report at bugs.python.org  Tue Apr 15 19:38:59 2008
From: report at bugs.python.org (Jeff Hall)
Date: Tue, 15 Apr 2008 17:38:59 +0000
Subject: [issue2640] "excel" csv option generates multiple lines
In-Reply-To: <1208281138.97.0.0353161636631.issue2640@psf.upfronthosting.co.za>
Message-ID: <1208281138.97.0.0353161636631.issue2640@psf.upfronthosting.co.za>


New submission from Jeff Hall <hall.jeff at gmail.com>:

Current: csv.py indicates lineterminator = '\r\n'
Issue: looks fine in notepad but when pulled into excel (office 2003)
extra lines are added
Resolution: should read lineterminator = '\r'

----------
components: Extension Modules
messages: 65523
nosy: laxrulz777
severity: normal
status: open
title: "excel" csv option generates multiple lines
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2640>
__________________________________

From report at bugs.python.org  Tue Apr 15 20:01:26 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Apr 2008 18:01:26 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208282486.18.0.597705598528.issue2603@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Code review:

Objects/rangeobject.c:

line 259-260:
AFAIK register is completely useless in this day and age; drop it.

line 296 and further:
Please move the || and && operators to the end of the previous line.

line 313 etc:
This all fits on one line.

Line 319-320:
Ditto.

Line 361:
Please make the comment line up.

Lib/test/test_builtin.py:
I'd like to see another test indicating which of the following is true:

range(0, 11, 2) == range(0, 10, 2)

or

range(0, 11, 2) != range(0, 10, 2)

(since they produce the same sequence of values).

Also, add a test for __hash__() of a range().

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Tue Apr 15 22:01:29 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Tue, 15 Apr 2008 20:01:29 +0000
Subject: [issue2638] tkSimpleDialog Window Flashing
In-Reply-To: <1208274253.49.0.82594797708.issue2638@psf.upfronthosting.co.za>
Message-ID: <1208289689.61.0.0537894483802.issue2638@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Isn't overrideredirect only used to enable/disable borders in the window
? Why doing this fix what you described ?
Also, make a patch against python-trunk instead of sending the entire file.

----------
nosy: +gpolo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2638>
__________________________________

From report at bugs.python.org  Tue Apr 15 22:17:21 2008
From: report at bugs.python.org (Franz Glasner)
Date: Tue, 15 Apr 2008 20:17:21 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1208290641.28.0.729393596794.issue2504@psf.upfronthosting.co.za>


Franz Glasner <f.glasner at feldmann-mg.com> added the comment:

I have written a patch against the current Python trunk's gettext to
add support for pgettext and friends (upgettext, npgettext, unpgettext,
...).

I have also changed Tools/i18n/msgfmt.py to recognize the "msgctxt" keyword.
Some new unittests for dgettext and lgettext and variants are also included.

If the patch will be accepted then someone should drop a message to the
maintainers of GNU gettext to add the new functions as default keywords
for xgettext. Right now you have to call xgettext with
"--keyword=pgettext:1c,2" to extract messages with context. 

Tools/i18n/pygettext.py does currently not handle context variants.

----------
components: +Library (Lib) -Extension Modules
keywords: +patch
nosy: +franz_glasner
Added file: http://bugs.python.org/file10036/gettext-pgettext.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
__________________________________

From report at bugs.python.org  Tue Apr 15 22:34:36 2008
From: report at bugs.python.org (Jason Orendorff)
Date: Tue, 15 Apr 2008 20:34:36 +0000
Subject: [issue2641] setuptools gets site-packages wrong on Mac
In-Reply-To: <1208291676.15.0.165300999847.issue2641@psf.upfronthosting.co.za>
Message-ID: <1208291676.15.0.165300999847.issue2641@psf.upfronthosting.co.za>


New submission from Jason Orendorff <jason.orendorff at gmail.com>:

On my Mac, /usr/local/bin/python2.5 is a symlink to
"../../../Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5".

When I install Mercurial from source, the "mercurial" package is
installed at "/usr/local/lib/python2.5/site-packages/mercurial", so the
installation is broken.  Since "site-packages" appears nowhere in the
Mercurial source tree, I think it's setuptools (not Mercurial) that is
getting this wrong.

Mercurial's setup.py can be seen here:

(as of this writing)
http://hg.intevation.org/mercurial/crew/file/628da4a91628/setup.py

(the latest)
http://hg.intevation.org/mercurial/crew/file/tip/setup.py

I'm not sure what the Right Thing would be, but if it's agreed that the
current behavior is a hack, then `(p for p in sys.path if
p.endswith('site-packages')).next()`, falling back to the current
behavior, seems like a better hack.

Happy to patch, if someone can advise me; MvL?

----------
components: Distutils
messages: 65527
nosy: jorendorff
severity: normal
status: open
title: setuptools gets site-packages wrong on Mac
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2641>
__________________________________

From report at bugs.python.org  Tue Apr 15 22:45:16 2008
From: report at bugs.python.org (Curt Hagenlocher)
Date: Tue, 15 Apr 2008 20:45:16 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208292316.49.0.00492747511517.issue2632@psf.upfronthosting.co.za>


Curt Hagenlocher <curt at hagenlocher.org> added the comment:

At least in 2.5.2, there appear to be only two places in the standard 
library where an arbitrary and unchecked size is passed directly to 
_socketobject.recv.  _fileobject.read is one such place and the other 
is in logging/config.py.  In both cases, the pattern is something like

while len(data) < size:
    data = data + sock.recv(size - len(data))

Of course, the same pattern may exist in any number of instances of 
user code that performs a socket.recv, and all of these would be 
subject to the same memory thrashing problem that originally beset 
imaplib.

As such, I now agree with Ralf that the fix ultimately belongs in 
_socketobject.  However, deploying a fix for 2.5.2 is probably easier 
if it's in socket.py than if it requires a recompile.

----------
title: socket._fileobject.read(n) should ignore _rbufsize when 1 -> performance problem in socket._fileobject.read

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 15 22:54:22 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 Apr 2008 20:54:22 +0000
Subject: [issue1628484] Python 2.5 64 bit compile fails on Solaris 10/gcc 4.1.1
In-Reply-To: <4804659A.1050007@digilink.net>
Message-ID: <480515FA.2090600@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Just to repeat my concern about this patch: It gives the impression of
supporting CFLAGS, but doesn't really. There *is* a hard rule that
CFLAGS given to configure should override any options passed to
configure, and there is a reason for that: configure may guess
incorrectly, and may add options that actually conflict with the ones
that you are trying to pass in. For example, for Darwin, we add
-arch ppc -arch i386, so there is no way to not build a universal
binary anymore. Likewise, on SCO_SV, configure adds -Ki486 -DSCO5,
which may well be incorrect, and there would be no way to correct that.

Can you please agree that above description is factual wrt. the patch
you propose?

Therefore, I claim that this makes things more complex, and doesn't
solve an actual problem.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1628484>
_____________________________________

From report at bugs.python.org  Tue Apr 15 23:17:01 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 15 Apr 2008 21:17:01 +0000
Subject: [issue2504] Add gettext.pgettext() and variants support
In-Reply-To: <1206756624.13.0.664664048525.issue2504@psf.upfronthosting.co.za>
Message-ID: <1208294221.64.0.968231682861.issue2504@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
assignee:  -> loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2504>
__________________________________

From report at bugs.python.org  Tue Apr 15 23:21:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 15 Apr 2008 21:21:17 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208294477.19.0.277594698607.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the review! How does this look?

Added file: http://bugs.python.org/file10037/range_eq_after_review.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Tue Apr 15 23:36:25 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Tue, 15 Apr 2008 21:36:25 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208295385.13.0.808431796772.issue2603@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Close.  Just a few nits:

line 298:
These two fit on one line. Possibly the whole thing fits. If it doesn't,
the '{' should be on a line by itself.

(Are you aware of PEP 7, C code guidelines? I realize it's incomplete,
but you should still study it -- if you find things it's missing,
propose a patch to update it...!)

line 356:
Still not aligned.

Are you sure you're viewing this with a fixed-width font and tabs set to
8 spaces?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Tue Apr 15 23:41:52 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 15 Apr 2008 21:41:52 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208295712.43.0.31693009143.issue2603@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch uses Py_SIZE(v) on a rangeobject?
I guess you borrowed too much from the tuple implementation ;-)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 00:32:59 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 15 Apr 2008 22:32:59 +0000
Subject: [issue2483] int and float accept bytes, complex does not
In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za>
Message-ID: <1208298779.7.0.129025683728.issue2483@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Closing this:  the consensus seems to be that things are fine as they 
are.

See the thread at

http://mail.python.org/pipermail/python-3000/2008-April/013100.html

for discussion.

----------
resolution:  -> invalid

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2483>
__________________________________

From report at bugs.python.org  Wed Apr 16 01:40:11 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 15 Apr 2008 23:40:11 +0000
Subject: [issue2640] "excel" csv option generates multiple lines
In-Reply-To: <1208281138.97.0.0353161636631.issue2640@psf.upfronthosting.co.za>
Message-ID: <1208302811.61.0.637817233502.issue2640@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

What platform are you on?  Did you open the output file in
binary mode?  I sort of suspect you failed to add 'b' to the
file mode and are getting a text file.

----------
nosy: +skip.montanaro

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2640>
__________________________________

From report at bugs.python.org  Wed Apr 16 02:33:32 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Wed, 16 Apr 2008 00:33:32 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208306012.7.0.724526880283.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

I think sys.stdout need to have backslashreplace error handler. 
Without backslashreplace, print(listOfJapaneseString) prints nothing, 
but raises an exception. This is worse than Python2.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Wed Apr 16 02:44:17 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 16 Apr 2008 00:44:17 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208306657.13.0.690348492201.issue2630@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I don't think this is a good idea; I've explained why earlier on this issue.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Wed Apr 16 03:05:54 2008
From: report at bugs.python.org (Wesley Spikes)
Date: Wed, 16 Apr 2008 01:05:54 +0000
Subject: [issue2642] MSVCRT packing in Windows Installer (3.0a4)
In-Reply-To: <1208307954.26.0.976441320091.issue2642@psf.upfronthosting.co.za>
Message-ID: <1208307954.26.0.976441320091.issue2642@psf.upfronthosting.co.za>


New submission from Wesley Spikes <wesley.spikes at gmail.com>:

I've searched and did not find any open ticket to make suggestions on, 
so I'm posting it here.

You currently have posted "The MSI installers for Python 3.0a4 are 
compiled with the new Visual Studio 2008 Professional version. 
Therefore Python depends on the -Visual C++ runtime library 9.0. We 
currently don't package this library properly, which means that non-
Administrator installation is currently not supported. Contributions to 
fix this problem are welcome."

Two potential fixes, both of which should be very readily doable. First 
one is to set the Linking option in MSVC++ to a static link to the CRT. 
This in-builds the library with Python. (Options /MT and /MTd, for 
release and debug versions, respectively.)

The other potential resolution for Non-Admin installs, which may or may 
not be more stable, is to include the MSVCRT DLLs into the directory 
containing the Python installation. If needed, you may have to register 
these files manually into the HKCU hive.

Hope that helps with your described packaging issue with the installer.

(Classified under Build and Installation, since it deals with both 
halves -- feel free to reclassify as appropriate.)

----------
components: Build, Installation
messages: 65537
nosy: wesley.spikes
severity: normal
status: open
title: MSVCRT packing in Windows Installer (3.0a4)
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2642>
__________________________________

From report at bugs.python.org  Wed Apr 16 03:23:35 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Wed, 16 Apr 2008 01:23:35 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208309015.16.0.179811439232.issue2601@psf.upfronthosting.co.za>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

So if the fix was applied to 2.5 branch and 2.6 (3.0 should have
picked up from 2.6 automatically), can we close this bug?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Wed Apr 16 04:18:31 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 16 Apr 2008 02:18:31 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208312311.29.0.962248391904.issue2601@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

I don't think the fix was acceptable.  Now python spins consuming all
cpu trying to read trivial amounts of data one byte at a time...

See the discusson at the end of http://bugs.python.org/issue1092502 as
well as a recent python-dev thread:

http://mail.python.org/pipermail/python-dev/2008-April/078613.html

----------
nosy: +gregory.p.smith

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Wed Apr 16 04:21:15 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 16 Apr 2008 02:21:15 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208312475.85.0.743248658555.issue2601@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

or else i'm missing something here in the maze of three bugs talking
about the same issue..

which revisions fixed the introduced performance issue?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Wed Apr 16 04:21:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Apr 2008 02:21:30 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208312490.47.0.267443862116.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching a new patch. I'm not really sure what to do about the hash. I
just removed the Py_SIZE parts. I hope that's OK.

Added file: http://bugs.python.org/file10038/range_eq4.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 04:37:16 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Wed, 16 Apr 2008 02:37:16 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208313436.34.0.30896574503.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

Sorry, I missed to write "for interactive session".
I agree for sys.stdout and other files should not have default 
backslashescape, but for iteractive session, I think sys.stdout can 
have backslasespape handler to avoid exceptions.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Wed Apr 16 04:50:49 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Apr 2008 02:50:49 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1208312490.47.0.267443862116.issue2603@psf.upfronthosting.co.za>
Message-ID: <d38f5330804151950h339f12e2ie62a902f85b64fb5@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Tue, Apr 15, 2008 at 10:21 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>  I'm not really sure what to do about the hash. I
>  just removed the Py_SIZE parts. I hope that's OK.

If you want to maintain hash(range(a,b,c)) == hash((a,b,c)) invariant,
you need to replace len with 3, not 0.  While I think your latest
implementation is ok, reproducing tuple hash will make correctness
more obvious.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 05:24:26 2008
From: report at bugs.python.org (sams.james)
Date: Wed, 16 Apr 2008 03:24:26 +0000
Subject: [issue2008] cookielib lacks FileCookieJar class for Safari
In-Reply-To: <1202153846.32.0.869416159529.issue2008@psf.upfronthosting.co.za>
Message-ID: <1208316266.81.0.804368544616.issue2008@psf.upfronthosting.co.za>


sams.james <sams.james at gmail.com> added the comment:

would you mind posting the read code you have? I would really like to at
least be able to import Safari cookies in an app or two I have lying
around..

----------
nosy: +sams.james

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2008>
__________________________________

From report at bugs.python.org  Wed Apr 16 08:02:03 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 06:02:03 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1208325723.45.0.836829795003.issue2601@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

me and amk are talking about the commit that introduced this bug (which
was meant as a fix for another bug).
neal seems to think that this commit is the fix to this bug itself.
and gregory, you are now confused :)

hope it's clear now.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Wed Apr 16 13:58:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 16 Apr 2008 11:58:19 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208347099.74.0.583163318485.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks Alexander. Trying again.

Added file: http://bugs.python.org/file10039/range_eq5.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 14:22:43 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 16 Apr 2008 12:22:43 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1208348563.05.0.291930014258.issue1529142@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Works fine for me, I just dislike that Port binding error message
because it is a bit misleading. It says "IDLE can't bind any TCP/IP
port, ..." which is not entirely true.

----------
nosy: +gpolo

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_____________________________________

From report at bugs.python.org  Wed Apr 16 15:16:42 2008
From: report at bugs.python.org (Alan McIntyre)
Date: Wed, 16 Apr 2008 13:16:42 +0000
Subject: [issue1622] zipfile hangs on certain zip files
In-Reply-To: <1197595878.01.0.706002731675.issue1622@psf.upfronthosting.co.za>
Message-ID: <1208351802.68.0.761515819343.issue1622@psf.upfronthosting.co.za>


Alan McIntyre <alan.mcintyre at gmail.com> added the comment:

Is there anything else that needs to be addressed before this can be
committed?  At the moment I don't know of anything, just wanted to make
sure somebody wasn't waiting on me.  

As a reminder, issues #1526 and #1746 should be closed if this patch is
committed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1622>
__________________________________

From report at bugs.python.org  Wed Apr 16 15:21:04 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 13:21:04 +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: <1208352064.01.0.707585518488.issue2122@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

now this insanity is even documented with svn revision 62359
(http://hgpy.de/py/trunk/rev/442252bce780)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
__________________________________

From report at bugs.python.org  Wed Apr 16 17:29:16 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 15:29:16 +0000
Subject: [issue2576] httplib read() very slow due to lack of socket buffer
In-Reply-To: <1207601711.27.0.24453345668.issue2576@psf.upfronthosting.co.za>
Message-ID: <1208359756.8.0.898544569763.issue2576@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2576>
__________________________________

From report at bugs.python.org  Wed Apr 16 18:03:01 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Apr 2008 16:03:01 +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: <1208361780.85.0.7288626435.issue2122@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Perhaps it would be better if the patch came with unit tests. I agree
that the situation right now is insane.

PS : I have no power to commit or even accept a patch :)

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
__________________________________

From report at bugs.python.org  Wed Apr 16 18:26:19 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 16:26:19 +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: <1208363179.24.0.586088290861.issue2122@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

I thought about this too, but I don't know of a way to provoke an error.
(Other than passing in illegal values, but the code tries to catch
those. And btw, raises an Exception on windows :)

One could currently pass in a negative value for size (this isn't caught
in the checks). e.g.

m.flush(500, -500) gives an 'error: [Errno 22] Invalid argument' on linux.

but then you don't want to rely on another bug for testing purposes.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2122>
__________________________________

From report at bugs.python.org  Wed Apr 16 18:29:01 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 16:29:01 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

on unix it does call msync however.


here is the relevant part from mmapmodule.c:

static void
mmap_object_dealloc(mmap_object *m_obj)
{
#ifdef MS_WINDOWS
	if (m_obj->data != NULL)
		UnmapViewOfFile (m_obj->data);
	if (m_obj->map_handle != INVALID_HANDLE_VALUE)
		CloseHandle (m_obj->map_handle);
	if (m_obj->file_handle != INVALID_HANDLE_VALUE)
		CloseHandle (m_obj->file_handle);
	if (m_obj->tagname)
		PyMem_Free(m_obj->tagname);
#endif /* MS_WINDOWS */

#ifdef UNIX
	if (m_obj->fd >= 0)
		(void) close(m_obj->fd);
	if (m_obj->data!=NULL) {
		msync(m_obj->data, m_obj->size, MS_SYNC);
		munmap(m_obj->data, m_obj->size);
	}
#endif /* UNIX */

	Py_TYPE(m_obj)->tp_free((PyObject*)m_obj);
}

----------
messages: 65552
nosy: schmir
severity: normal
status: open
title: mmap_object_dealloc does not call FlushViewOfFile on windows

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
__________________________________

From report at bugs.python.org  Wed Apr 16 18:30:26 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 16:30:26 +0000
Subject: [issue2644] errors from msync ignored in mmap_object_dealloc
In-Reply-To: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>
Message-ID: <1208363426.33.0.938357268178.issue2644@psf.upfronthosting.co.za>


New submission from Ralf Schmitt <schmir at gmail.com>:

mmapmodule.c's mmap_object_dealloc calls msync without checking for an
error.

----------
messages: 65553
nosy: schmir
severity: normal
status: open
title: errors from msync ignored in mmap_object_dealloc
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2644>
__________________________________

From report at bugs.python.org  Wed Apr 16 18:30:44 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 16:30:44 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1208363444.11.0.102430673586.issue2643@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
type:  -> behavior
versions: +Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
__________________________________

From report at bugs.python.org  Wed Apr 16 18:40:12 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 16 Apr 2008 16:40:12 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1208364011.8.0.265890387189.issue2643@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

The close method does not call msync or FlushViewOfFile.
I find this a bit strange cause explicitly closing the mmap will not
flush changes but relying on the garbage collector will flush changes.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
__________________________________

From report at bugs.python.org  Wed Apr 16 19:48:20 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Apr 2008 17:48:20 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208368100.26.0.359412408728.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

With range_eq5.patch applied on an x86-64 Linux box:

$ ./python 
Python 3.0a4+ (py3k:62359M, Apr 16 2008, 13:36:31) 
[GCC 3.4.6 20060404 (Red Hat 3.4.6-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> hash(range(1,2,3))
-4094131973719604815
>>> hash(((1,2,3)))
2528502973977326415


Also, please fix indentation at Objects/rangeobject.c:271.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 20:09:38 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Apr 2008 18:09:38 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208369378.28.0.400374347277.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

range_eq5.patch fails to reproduce tuple hash because in the tuple hash
implementation the len variable varies between iterations over items. I
would just use literals for the three different values of mult rather
than copying mult += (long)(82520L + 3 + 3).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 20:16:00 2008
From: report at bugs.python.org (Niall O'Higgins)
Date: Wed, 16 Apr 2008 18:16:00 +0000
Subject: [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>


New submission from Niall O'Higgins <niallo at unworkable.org>:

I do a lot of urllib2 reads of HTTP URLs.  From time to time, I see the
following exception being thrown:

  File "/usr/local/lib/python2.5/socket.py", line 291, in read
    data = self._sock.recv(recv_size)
  File "/usr/local/lib/python2.5/httplib.py", line 509, in read
    return self._read_chunked(amt)
  File "/usr/local/lib/python2.5/httplib.py", line 548, in _read_chunked
    chunk_left = int(line, 16)
ValueError: invalid literal for int() with base 16: ''

The chunked reading code does not expect an empty string.  I have
attached a patch which checks for ValueError in this case and sets
chunk_left to 0, which will break from the loop.  I am not entirely sure
if this is the correct fix, however, but it should illustrate the problem.

----------
components: Library (Lib)
files: httplib.py.diff
keywords: patch
messages: 65557
nosy: niallo
severity: normal
status: open
title: httplib throws ValueError
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10040/httplib.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2645>
__________________________________

From report at bugs.python.org  Wed Apr 16 20:20:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Apr 2008 18:20:06 +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: <1208370006.33.0.849207212811.issue1222@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


Removed file: http://bugs.python.org/file9341/1222.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
__________________________________

From report at bugs.python.org  Wed Apr 16 20:20:53 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Apr 2008 18:20:53 +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: <1208370053.03.0.56161526549.issue1222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Here is an updated patch against trunk.

----------
keywords: +patch
Added file: http://bugs.python.org/file10041/1222.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
__________________________________

From report at bugs.python.org  Wed Apr 16 20:21:46 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Wed, 16 Apr 2008 18:21:46 +0000
Subject: [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208370106.04.0.296563892076.issue2645@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

thanks for the patch.  can you check the HTTP/1.1 RFC and see what it
says  (if anything) about handling this case?

also, do you happen to get this consistently from any particular urls or
servers or is this pretty random just happening under load as you fetch
a bunch of stuff?

i'm wondering if this happens because we just haven't received/read
enough data yet.  (i haven't looked closely at the code yet, hopefully
that is clear by reading it)

----------
nosy: +gregory.p.smith

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2645>
__________________________________

From report at bugs.python.org  Wed Apr 16 20:23:20 2008
From: report at bugs.python.org (Tal Einat)
Date: Wed, 16 Apr 2008 18:23:20 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1208370200.66.0.770996122779.issue1529142@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

Thanks for taking the time to review this patch, Guilherme. For the
record, on which OS+Python have you tested this?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_____________________________________

From report at bugs.python.org  Wed Apr 16 20:27:58 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Apr 2008 18:27:58 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208370478.73.0.501875542937.issue2632@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

As A.M. Kuchling said in the other bug :), there is no need to fix 2.5.2
as the offending change is posterior to the release.
By the way, somewhat really ought to close either this bug or #2601,
discussing things in parallel in two different bug entries is too confusing.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Wed Apr 16 20:31:00 2008
From: report at bugs.python.org (Jeff Hall)
Date: Wed, 16 Apr 2008 18:31:00 +0000
Subject: [issue2640] "excel" csv option generates multiple lines
In-Reply-To: <1208302811.61.0.637817233502.issue2640@psf.upfronthosting.co.za>
Message-ID: <1bc395c10804161130w1dceeb55w78aa9057efdfda54@mail.gmail.com>


Jeff Hall <hall.jeff at gmail.com> added the comment:

you're absolutely correct, i apologize.

On Tue, Apr 15, 2008 at 7:40 PM, Skip Montanaro <report at bugs.python.org>
wrote:

>
> Skip Montanaro <skip at pobox.com> added the comment:
>
> What platform are you on?  Did you open the output file in
> binary mode?  I sort of suspect you failed to add 'b' to the
> file mode and are getting a text file.
>
> ----------
> nosy: +skip.montanaro
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2640>
> __________________________________
>

Added file: http://bugs.python.org/file10042/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2640>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
Url: http://mail.python.org/pipermail/python-bugs-list/attachments/20080416/fc78c75b/attachment.txt 

From report at bugs.python.org  Wed Apr 16 20:36:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 16 Apr 2008 18:36:44 +0000
Subject: [issue2483] int and float accept bytes, complex does not
In-Reply-To: <1206462120.7.0.66925954466.issue2483@psf.upfronthosting.co.za>
Message-ID: <1208371004.74.0.234524614549.issue2483@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2483>
__________________________________

From report at bugs.python.org  Wed Apr 16 21:13:52 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Wed, 16 Apr 2008 19:13:52 +0000
Subject: [issue1529142] Allowing multiple instances of IDLE with sub-processes
Message-ID: <1208373232.42.0.665805060487.issue1529142@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

I tested under Linux (Ubuntu distro), Python trunk

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1529142>
_____________________________________

From report at bugs.python.org  Wed Apr 16 21:37:39 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Wed, 16 Apr 2008 19:37:39 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208374659.38.0.0413352541712.issue2630@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

While it may be desirable to to have repr(unicode) return a non-ASCII
string, the suggested approach is not suitable to solve the problem.

repr() is usually used in logging and applications/users/tools don't
expect to suddenly find non-ASCII or even mixed encodings in a log file.

If you do want to have this more flexible, then make the encoding used
by unicode_repr() adjustable, turn the existing code into a codec (e.g.
"unicode-repr") and leave it setup as default.

Users who wish to see non-ASCII repr(unicode) data can then adjust the
used encoding to their liking.

This is both more flexible and backwards compatible with 2.x.

Also note that the separation of the Unicode database from the
interpreter core was done to keep the interpreter footprint manageable.
It's not a good idea to just dump the complete table set into
unicodeobject.c via an #include. If you need to reference APIs from
modules in C, the usual approach is to create a PyCObject which is then
exported by the module (see e.g. the datetime module) and imported by
code needing it.

BTW: "printable" is not a defined term in Unicode. What is or is not
printable really depends on the use case, e.g. there are quite a few
code points in Unicode that don't result in any glyph being "printed" to
the screen. A Unicode string could then look as if it had fewer code
points than it actually does - which is not really what you want when
debugging code or sifting through log files.

----------
nosy: +lemburg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Wed Apr 16 21:40:12 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 16 Apr 2008 19:40:12 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208374812.41.0.631979191559.issue2603@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Why would you want to have hash(range(a,b,c)) == hash((a,b,c)) ?
It'd be more logical to have hash(range(a,b,c)) ==
hash(tuple(range(a,b,c))) ... which is not the same thing at all :)

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 22:01:03 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Wed, 16 Apr 2008 20:01:03 +0000
Subject: [issue2640] "excel" csv option generates multiple lines
In-Reply-To: <1208281138.97.0.0353161636631.issue2640@psf.upfronthosting.co.za>
Message-ID: <1208376063.91.0.761187361918.issue2640@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2640>
__________________________________

From report at bugs.python.org  Wed Apr 16 22:16:18 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 16 Apr 2008 20:16:18 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1208374812.41.0.631979191559.issue2603@psf.upfronthosting.co.za>
Message-ID: <d38f5330804161248u49baeaabl563c02e98607a12c@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 16, 2008 at 3:40 PM, Antoine Pitrou <report at bugs.python.org> wrote:
..
>  Why would you want to have hash(range(a,b,c)) == hash((a,b,c)) ?

No particular reason other than that this is easy to test and gives
some assurance that hash values are reasonable.

>  It'd be more logical to have hash(range(a,b,c)) ==
>  hash(tuple(range(a,b,c))) ... which is not the same thing at all :)

No, this is not correct because range(..) == range(..) is not the same
as tuple(range(..)) == tuple(range(..)) in the proposed
implementation.  See Guido's example above and Benjamin's test case in
the eq5 patch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Wed Apr 16 23:40:06 2008
From: report at bugs.python.org (John (J5) Palmieri)
Date: Wed, 16 Apr 2008 21:40:06 +0000
Subject: [issue2646] Python does not accept unicode keywords
In-Reply-To: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>
Message-ID: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>


New submission from John (J5) Palmieri <johnp at redhat.com>:

# given this function

def a(**kwargs):
    pass

# this works
a(**{'b':'c'})

# this throws a format error
a(**{u'b':'c'})

I am using a web framework (TurboGears w/ genshi templating) which often
pass around dictionaries as keyword arguments in order to have 1 to 1
representation of json data and URL parameters.  This is usually fine
except when using libraries such as simplejson which encodes all of the
keywords as unicode.

Attached is a patch which is most likely just the tip of the iceberg but
hopefully it turns out to be this easy.

----------
components: Library (Lib)
files: allow_unicode_keywords.patch
keywords: patch
messages: 65567
nosy: j5
severity: normal
status: open
title: Python does not accept unicode keywords
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10043/allow_unicode_keywords.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2646>
__________________________________

From report at bugs.python.org  Thu Apr 17 00:15:49 2008
From: report at bugs.python.org (John (J5) Palmieri)
Date: Wed, 16 Apr 2008 22:15:49 +0000
Subject: [issue2646] Python does not accept unicode keywords
In-Reply-To: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>
Message-ID: <1208384149.4.0.834381042685.issue2646@psf.upfronthosting.co.za>


John (J5) Palmieri <johnp at redhat.com> added the comment:

Someone has convinced me that it is not worth bothering the dev team
since they will have this fixed in P3k the right way. If it is easy then
please fix this, otherwise feel free to close.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2646>
__________________________________

From report at bugs.python.org  Thu Apr 17 03:24:30 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Apr 2008 01:24:30 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208395470.68.0.875423706037.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

When I was trying to get the hash to resemble tuple's, it occurred to
me: Why not just hash a tuple?

Added file: http://bugs.python.org/file10044/range_eq6.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Thu Apr 17 05:02:00 2008
From: report at bugs.python.org (Richard Esplin)
Date: Thu, 17 Apr 2008 03:02:00 +0000
Subject: [issue2647] XML munges apos entity in tag content
In-Reply-To: <1208401320.5.0.728937941745.issue2647@psf.upfronthosting.co.za>
Message-ID: <1208401320.5.0.728937941745.issue2647@psf.upfronthosting.co.za>


New submission from Richard Esplin <richjunk1 at byu.net>:

I would like it to leave my &apos; alone, just like it does with my &lt;
and &gt;

Python 2.5.1 (r251:54863, Sep 21 2007, 22:46:31)
[GCC 4.2.1 (SUSE Linux)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from xml.dom import minidom
>>> doc = minidom.parseString("<tag>&lt;a&apos;b&gt;</tag>")
>>> doc.toxml()
u'<?xml version="1.0" ?><tag>&lt;a\'b&gt;</tag>'
>>>

----------
components: XML
messages: 65570
nosy: resplin
severity: normal
status: open
title: XML munges apos entity in tag content
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2647>
__________________________________

From report at bugs.python.org  Thu Apr 17 05:11:41 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Apr 2008 03:11:41 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1208395470.68.0.875423706037.issue2603@psf.upfronthosting.co.za>
Message-ID: <d38f5330804162011h24d17f4fm7e707d595f90313@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 16, 2008 at 9:24 PM, Benjamin Peterson wrote:
..
> Why not just hash a tuple?

There are a few reasons, but neither is good enough to have another
round of code review :-)

1. It is strange to have the hash function allocate new objects.  If
that was a type frequently used as a dict key, I would be concerned
about a possibility that dictionary lookup may trigger gc.

2. While reproducing hash(tuple) is a good starting point, there may
be a reason to choose different values for the magic constants.

3. If you don't want to mess with hash(tuple) complexity, a simple xor
of start/stop/step hashes (maybe with a check to prevent accidental -1
return) should be good enough.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Thu Apr 17 06:43:50 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Apr 2008 04:43:50 +0000
Subject: [issue2646] Python does not accept unicode keywords
In-Reply-To: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>
Message-ID: <1208407430.17.0.748110669736.issue2646@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I would say this is a good idea for 2.6.

Note that C functions are more forgiving:

>>> from datetime import *
>>> date(1,2,**{u'day':10})
datetime.date(1, 2, 10)
>>> dict(**{u'x':1,2:3,():5})
{u'x': 1, 2: 3, (): 5}

but

>>> date(1,2,**{u'day':10,u'x':20})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: keywords must be strings

I would not advocate making ** completely promiscuous (as in dict(..) 
above), but permitting unicode strings will allow for easier 3.0 
transitions.

I'll submit a patch.

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2646>
__________________________________

From report at bugs.python.org  Thu Apr 17 07:26:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 17 Apr 2008 05:26:24 +0000
Subject: [issue2646] Python does not accept unicode keywords
In-Reply-To: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>
Message-ID: <1208409984.91.0.210981442007.issue2646@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


Added file: http://bugs.python.org/file10045/issue2646.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2646>
__________________________________

From report at bugs.python.org  Thu Apr 17 07:37:52 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Thu, 17 Apr 2008 05:37:52 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208410672.63.0.18035127743.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

>  If you do want to have this more flexible, then make the encoding used
>  by unicode_repr() adjustable, turn the existing code into a codec (e.g.
>  "unicode-repr") and leave it setup as default.

Turning code in unicode_repr() into a codec is good idea. I'll write two
codecs(existing repr and new Unicode friendly codec) and post a revised
patch later.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Thu Apr 17 07:40:32 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 17 Apr 2008 05:40:32 +0000
Subject: [issue2605] Descriptor instance attributes not interpreted
	consistently
In-Reply-To: <1207822509.14.0.860100540347.issue2605@psf.upfronthosting.co.za>
Message-ID: <1208410832.37.0.0815545861092.issue2605@psf.upfronthosting.co.za>


Piet Delport <pjdelport at gmail.com> added the comment:

Related: #643841 (new-style special method lookup)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2605>
__________________________________

From report at bugs.python.org  Thu Apr 17 07:44:21 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 17 Apr 2008 05:44:21 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1208411061.28.0.0434613646669.issue643841@psf.upfronthosting.co.za>


Piet Delport <pjdelport at gmail.com> added the comment:

Somewhat related: #2605 (descriptor __get__/__set__/__delete__)

----------
nosy: +pjd

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
____________________________________

From report at bugs.python.org  Thu Apr 17 08:05:02 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 17 Apr 2008 06:05:02 +0000
Subject: [issue2647] XML munges apos entity in tag content
In-Reply-To: <1208401320.5.0.728937941745.issue2647@psf.upfronthosting.co.za>
Message-ID: <1208412302.03.0.3409813091.issue2647@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

That's not a bug. The two XML documents are completely equivalent. If
you rely on the lexical representation of specific characters, you
should reconsider your usage of XML. toxml could have chosen to
represent < as &#60;, and that still would have been correct (IOW, it
doesn't even know anymore that you represented it as &lt; in the input).

----------
nosy: +loewis
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2647>
__________________________________

From report at bugs.python.org  Thu Apr 17 08:13:33 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 17 Apr 2008 06:13:33 +0000
Subject: [issue2646] Python does not accept unicode keywords
In-Reply-To: <1208382006.33.0.385183415053.issue2646@psf.upfronthosting.co.za>
Message-ID: <1208412813.78.0.120448788213.issue2646@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
versions: +Python 2.6 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2646>
__________________________________

From report at bugs.python.org  Thu Apr 17 08:43:39 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Apr 2008 06:43:39 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208414619.13.0.577694998653.issue2603@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

No need to get hung-up on the hash function.  I can fix that up after a 
checkin and use something simple like: hashvalue = (start*prime1+seqlen)
*prime2+step.  That doesn't involve object creation and it produces the 
same hash value for range(5,10,2) and range(5,9,2) which are equivalent.

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Thu Apr 17 08:48:05 2008
From: report at bugs.python.org (Piet Delport)
Date: Thu, 17 Apr 2008 06:48:05 +0000
Subject: [issue2605] Descriptor instance attributes not interpreted
	consistently
In-Reply-To: <1207822509.14.0.860100540347.issue2605@psf.upfronthosting.co.za>
Message-ID: <1208414885.59.0.300778793732.issue2605@psf.upfronthosting.co.za>


Piet Delport <pjdelport at gmail.com> added the comment:

>From the Py3K list: 
http://mail.python.org/pipermail/python-3000/2007-March/006304.html

The sentiment appears to be to leave the behavior
implementation-defined.  It seems straightforward to update inspect and
pydoc to mirror typeobject.c, but i'm not sure where this leaves the
documentation.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2605>
__________________________________

From report at bugs.python.org  Thu Apr 17 09:21:18 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 17 Apr 2008 07:21:18 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208416878.52.0.92859867792.issue2603@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> It produces the same hash value for range(5,10,2) and range(5,9,2) 
> which are equivalent.
If "equivalent" means "__eq__", they are not.

This does not invalidate your formula, of course: different objects may
have the same hash.
It is also simple to understand: just mix the numbers together.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Thu Apr 17 09:33:56 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Apr 2008 07:33:56 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208417636.85.0.820159639928.issue2603@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

That was a typo.  The pair was range(5,10,2)-->[5, 7, 9] and range
(5,11,2)-->[5, 7, 9].  The formula works because the it uses seqlen 
instead of a stop value.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Thu Apr 17 11:47:55 2008
From: report at bugs.python.org (Carsten Grohmann)
Date: Thu, 17 Apr 2008 09:47:55 +0000
Subject: [issue2648] decimal receipe moneyfmt suppress leading 0
In-Reply-To: <1208425675.07.0.106835376727.issue2648@psf.upfronthosting.co.za>
Message-ID: <1208425675.07.0.106835376727.issue2648@psf.upfronthosting.co.za>


New submission from Carsten Grohmann <cgrohmann at users.sourceforge.net>:

The current version of the receipe moneyfmt doesn't have a leading "0" 
for 1 < value < -1.

The attached patch adds a new parameter "zero". The parameter is empty 
per default and can set to "0" print a leading "0". The examples are 
updated also.

Possibly the new option should be "0" per default.

Regards,
Carsten

----------
assignee: georg.brandl
components: Documentation
files: moneyfmt.diff
keywords: patch
messages: 65581
nosy: cgrohmann, georg.brandl
severity: normal
status: open
title: decimal receipe moneyfmt suppress leading 0
versions: Python 2.5
Added file: http://bugs.python.org/file10046/moneyfmt.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2648>
__________________________________

From report at bugs.python.org  Thu Apr 17 12:12:35 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Thu, 17 Apr 2008 10:12:35 +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: <1208427154.89.0.870771148381.issue1222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I see that http://wiki.python.org/moin/PythonBugDay says "need to test
on non-MacOS platform". Actually, I've tested the patch under Mandriva
and Debian Linux.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
__________________________________

From report at bugs.python.org  Thu Apr 17 12:22:40 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Apr 2008 10:22:40 +0000
Subject: [issue2648] decimal receipe moneyfmt suppress leading 0
In-Reply-To: <1208425675.07.0.106835376727.issue2648@psf.upfronthosting.co.za>
Message-ID: <1208427760.76.0.592268348866.issue2648@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee: georg.brandl -> rhettinger
nosy: +rhettinger
type:  -> feature request
versions: +Python 2.6 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2648>
__________________________________

From report at bugs.python.org  Thu Apr 17 12:50:05 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 17 Apr 2008 10:50:05 +0000
Subject: [issue2648] decimal receipe moneyfmt suppress leading 0
In-Reply-To: <1208425675.07.0.106835376727.issue2648@psf.upfronthosting.co.za>
Message-ID: <1208429405.74.0.957879653776.issue2648@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Thanks for the contribution.

Changed to be non-optional and applied as r62364 but not backported.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2648>
__________________________________

From report at bugs.python.org  Thu Apr 17 13:56:45 2008
From: report at bugs.python.org (Mark Summerfield)
Date: Thu, 17 Apr 2008 11:56:45 +0000
Subject: [issue2649] poss. patch for fnmatch.py to add {.htm,
	html} style globbing
In-Reply-To: <1208433404.5.0.648159158993.issue2649@psf.upfronthosting.co.za>
Message-ID: <1208433404.5.0.648159158993.issue2649@psf.upfronthosting.co.za>


New submission from Mark Summerfield <mark at qtrac.eu>:

At the moment fnmatch.py (and therefore glob.py) support:
* . [chars] [!chars]

The attached version of fnmatch.py extends this to:
* . [chars] [!chars] {one,two,...}

There are 2 changes from the original fnmatch.py file:
(1) The documentation for the fnmatch() function has been updated to
reflect the new functionality
(2) The translate() function has been completely replaced.
I ran test_fnmatch.py and test_glob.py and both ran without errors.

----------
components: Library (Lib)
files: fnmatch.py
messages: 65584
nosy: mark
severity: normal
status: open
title: poss. patch for fnmatch.py to add {.htm,html} style globbing
type: feature request
versions: Python 3.0
Added file: http://bugs.python.org/file10047/fnmatch.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2649>
__________________________________

From report at bugs.python.org  Thu Apr 17 16:14:10 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 17 Apr 2008 14:14:10 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>


New submission from Russ Cox <rsc at swtch.com>:

import re
print re.escape("_")

Prints \_ but should be _.

This behavior differs from Perl and other systems: _ is an identifier
character and as such does not need to be escaped.

----------
messages: 65585
nosy: rsc
severity: normal
status: open
title: re.escape should not escape underscore
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 17 16:14:25 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 17 Apr 2008 14:14:25 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208441665.8.0.516063272735.issue2650@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
components: +Regular Expressions

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 17 16:33:24 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Apr 2008 14:33:24 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208442804.74.0.833965522587.issue2650@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
keywords: +easy

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 17 16:33:38 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Thu, 17 Apr 2008 14:33:38 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208442818.1.0.848733886079.issue2650@psf.upfronthosting.co.za>


Changes by Guido van Rossum <guido at python.org>:


----------
versions: +Python 2.6, Python 3.0 -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 17 19:24:42 2008
From: report at bugs.python.org (Rick Harris)
Date: Thu, 17 Apr 2008 17:24:42 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>


New submission from Rick Harris <rconradharris at gmail.com>:

Here is a bug in Python 2.5 which would be nice to fix for Py3k (since
we are already breaking compatibility):

Take a string:
s = "Hello"

Create a KeyError exception with that string:
e = KeyError(s)

Counterintuitively, casting the exception to a string doesn't return the
same string:
str(e) != s

Instead, when KeyError is cast to a string it affixes single-quotes
around the string.

I have create a test which shows that the other built-in exceptions
(except for 3 Unicode Errors which seem to be unusual in that they don't
accept just a string), do indeed round-trip the string unaltered.

This actually caused a bug (in an old version of zope.DocumentTemplate).

I am including the test case I wrote for now; I will begin looking into
a solution shortly and hopefully whip up a patch.

----------
components: Interpreter Core
files: testExceptionStringRoundTrip.py
messages: 65586
nosy: rharris
severity: normal
status: open
title: Strings passed to KeyError do not round trip
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10048/testExceptionStringRoundTrip.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
__________________________________

From report at bugs.python.org  Thu Apr 17 19:42:11 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 17 Apr 2008 17:42:11 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1208454130.43.0.476028852328.issue2651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is a relevant comment inside the KeyError_str function:
    /* If args is a tuple of exactly one item, apply repr to args[0].
       This is done so that e.g. the exception raised by {}[''] prints
         KeyError: ''
       rather than the confusing
         KeyError
       alone.  The downside is that if KeyError is raised with an
explanatory
       string, that string will be displayed in quotes.  Too bad.
       If args is anything else, use the default BaseException__str__().
    */

Why is it so important to round trip?

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
__________________________________

From report at bugs.python.org  Thu Apr 17 20:38:17 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 17 Apr 2008 18:38:17 +0000
Subject: [issue2643] mmap_object_dealloc does not call FlushViewOfFile on
	windows
In-Reply-To: <1208363341.7.0.215523027719.issue2643@psf.upfronthosting.co.za>
Message-ID: <1208457497.24.0.83687495065.issue2643@psf.upfronthosting.co.za>


Changes by Trent Nelson <tnelson at onresolve.com>:


----------
nosy: +Trent.Nelson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2643>
__________________________________

From report at bugs.python.org  Thu Apr 17 21:48:05 2008
From: report at bugs.python.org (Rick Harris)
Date: Thu, 17 Apr 2008 19:48:05 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1208461685.43.0.0784544277887.issue2651@psf.upfronthosting.co.za>


Rick Harris <rconradharris at gmail.com> added the comment:

I think it is important to round-trip for at least two reasons:

1) Consistency. Other built-in exceptions behave this way, why should
KeyError be any different? Okay, technically 3 UnicodeErrors don't allow
just strings to be passed in (perhaps they should :-); but for common
exception classes, they all behave the same way.

To quote PEP-20: "Special cases aren't special enough to break the rules"

2) Intuitiveness. Decorating the string with quotes is unexpected; it
has already caused at least one bug and could cause more.

Ensuring intuitive round-trip behavior is an important enough issue that
is explicitly discussed in PEP 327 for the decimal type.

Why can't intuitiveness be restored to KeyError in Py3K?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
__________________________________

From report at bugs.python.org  Thu Apr 17 22:06:04 2008
From: report at bugs.python.org (Brad Miller)
Date: Thu, 17 Apr 2008 20:06:04 +0000
Subject: [issue2610] string representation of range
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1208462764.42.0.323855394508.issue2610@psf.upfronthosting.co.za>


Brad Miller <bonelake at gmail.com> added the comment:

Based on the discussion on python-dev  I've worked up a patch and tests 
for repr of dict_items, dict_keys, and dict_values.  I've also modified 
the patch and test for str of the range object.  (If there was a way to 
get the str(range(10)) to automatically display in the interactive shell 
that would be ideal.

I assume one combined patch for all of this is OK since its been part of 
the same discussion.

Brad

Added file: http://bugs.python.org/file10049/dv_range.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2610>
__________________________________

From report at bugs.python.org  Thu Apr 17 22:29:51 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Apr 2008 20:29:51 +0000
Subject: [issue2610] string representation of range and dictionary views
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1208464191.27.0.0829957409408.issue2610@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
title: string representation of range -> string representation of range and dictionary views

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2610>
__________________________________

From report at bugs.python.org  Thu Apr 17 22:44:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Apr 2008 20:44:16 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208465056.16.0.871421155437.issue2650@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It seems that escape is pretty dumb. The documentations says that
re.escape escapes all non-alphanumeric characters, and it does that
faithfully. It would seem more useful to have a list of meta-characters
and just escape those. This is more true in Py3k when str can have
thousands of possible characters that could be considered alphanumeric.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 17 23:26:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 17 Apr 2008 21:26:49 +0000
Subject: [issue2610] string representation of range and dictionary views
In-Reply-To: <1207858708.98.0.537185652213.issue2610@psf.upfronthosting.co.za>
Message-ID: <1208467609.85.0.97265388481.issue2610@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Some review of dv_range.patch:

- repr(d.keys()) depends on the internal ordering of items, their hash
values, the insertion order... the test seems fragile.
Or you may rely on the fact that ints are their own hash values, so a
small dict containing small keys will appear ordered. I suggest
something like {6: 1.2, 1: 'A', 7: 42, 4: None}

- empty dicts or empty ranges will display:
   <range: >
   <dict_items: >
Isn't there a better repr? At least this should appear in the tests.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2610>
__________________________________

From report at bugs.python.org  Thu Apr 17 23:48:18 2008
From: report at bugs.python.org (Brad Miller)
Date: Thu, 17 Apr 2008 21:48:18 +0000
Subject: [issue2610] string representation of range and dictionary views
In-Reply-To: <1208467609.85.0.97265388481.issue2610@psf.upfronthosting.co.za>
Message-ID: <59287CB2-E678-4A1F-8E03-710ABCB92018@gmail.com>


Brad Miller <bonelake at gmail.com> added the comment:

On Apr 17, 2008, at 4:26 PM, Amaury Forgeot d'Arc wrote:

>
> Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:
>
> Some review of dv_range.patch:
>
> - repr(d.keys()) depends on the internal ordering of items, their hash
> values, the insertion order... the test seems fragile.
> Or you may rely on the fact that ints are their own hash values, so a
> small dict containing small keys will appear ordered. I suggest
> something like {6: 1.2, 1: 'A', 7: 42, 4: None}

I wondered about that, but my assumption was that the hash function  
for strings and ints was equally unlikely to change.  I can go with  
all ints if that is really a safer assumption.

>
>
> - empty dicts or empty ranges will display:
>   <range: >
>   <dict_items: >
> Isn't there a better repr? At least this should appear in the tests.

I'm not sure how to represent that better.
<range: None>
<dict_items: None>       -- These seem misleading

<range: empty>
<dict_items: empty>       -- I'm not sure that is better than  
<dict_items: > and empty may not mean anything to non-english speakers

I'll be happy to add the test for the empty case after once I know  
what it should look like.

>
>
> ----------
> nosy: +amaury.forgeotdarc
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2610>
> __________________________________

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2610>
__________________________________

From report at bugs.python.org  Fri Apr 18 00:07:17 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Apr 2008 22:07:17 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1208470037.84.0.914186973889.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Attaching a new patch with a few improvements. I tried to implemented
Raymond's hash function (I think this is how the math should be done.).
The rich compare function now short-circuits when a value isn't equal.
Also, I made ranges with the same set of integers equal even if the stop
is different.

Added file: http://bugs.python.org/file10050/range_eq7.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Fri Apr 18 00:07:01 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 17 Apr 2008 22:07:01 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208470021.73.0.565229351615.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

I am very sorry to report (at least for me) that as of this moment, item 
9), although not yet complete, is stable and able to pass all the 
existing python regexp tests.  Because these tests are timed, I am using 
the timings from the first suite of tests to perform a benchmark of 
performance between old and new code.  Based on discussion with Andrew 
Kuchling, I have decided for the sake of simplicity, the "timing" of 
each version is to be calculated by the absolute minimum time to execute 
observed because it is believed this execution would have had the most 
continuous CPU cycles and thus most closely represents the true 
execution time.

It is this current conclusion that greatly saddens me, not that the 
effort has not been valuable in understanding the current engine.  
Indeed, I understand the current engine now well enough that I could 
proceed with the other modifications as-is rather than implementing them 
with the new engine.  Mind you, I will likely not bring over the copious  
comments that the new engine received when I translated it to a form 
without C_Macros and gotos, as that would require too much effort IMHO.

Anyway, all that being said, and keeping in mind that I am not 100% 
satisfied with the new engine and may still be able to wring some timing 
out of it -- not that I will spend much more time on this -- here is 
where we currently stand:

Old Engine: 6.574s
New Engine: 7.239s

This makes the old Engine 665ms faster over the entire first test_re.py 
suite, or 9% faster than the New Engine.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Fri Apr 18 00:11:34 2008
From: report at bugs.python.org (Inyeol Lee)
Date: Thu, 17 Apr 2008 22:11:34 +0000
Subject: [issue1184112] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <1208470294.56.0.862428093414.issue1184112@psf.upfronthosting.co.za>


Inyeol Lee <inyeol.lee at gmail.com> added the comment:

Missing trailing newline still triggers error as of 2.5.1:

>>> import parser
>>> parser.suite("pass\n ")
IndentationError: unexpected indent
>>> parser.suite("if True:\n pass\n ")
SyntaxError: invalid syntax

----------
nosy: +inyeollee

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1184112>
_____________________________________

From report at bugs.python.org  Fri Apr 18 00:26:08 2008
From: report at bugs.python.org (kevin)
Date: Thu, 17 Apr 2008 22:26:08 +0000
Subject: [issue2652] 64 bit python  memory leak usage
In-Reply-To: <1208471168.76.0.0271810352377.issue2652@psf.upfronthosting.co.za>
Message-ID: <1208471168.76.0.0271810352377.issue2652@psf.upfronthosting.co.za>


New submission from kevin <kevin3210 at gmail.com>:

For the code below.. memory usage keeps increasing continuously.. This
does not happen in a 32-bit machine python build. i think it might be
the datetime module where the problem might be..


linux kernel version (both on 32-bit and 64 bit machine)
linux - 2.6.24.4-64.fc8
python version (both on 32-bit and 64 bit machine)
Python 2.5.1 (r251:54863, Oct 30 2007, 13:45:26)


now = datetime.datetime.now()
oneday = datetime.timedelta(days=1)

def birthdaycompare(a, b):
   if a is None and b:
       return 1
   if a and b is None:
       return -1
   if a is None and b is None:
       return 0
   if a<b:
       return -1
   elif a==b:
       return 0
   else:
       return 1

def compare_by(fieldname):
   def comparedict(a,b):
       return birthdaycompare(a[fieldname], b[fieldname])
   return comparedict

def getbirthdays(friend_details):
   new_f = []
   birthday = None
   birthday_dt = None
   for f in friend_details:
       if f.has_key('birthday'):
           birthday = f['birthday']
       if birthday and birthday !='':
           birthday_split = birthday.split(',')[0]
           if birthday_split == 'February 29':
               birthday = 'February 28'
           try:
               birthday_dt =
datetime.datetime.strptime(birthday_split + ', ' + str(now.year) , '%B
%d, %Y')
               if birthday_dt < (now - oneday):
                   birthday_dt =
datetime.datetime.strptime(birthday_split + ', ' + str(now.year+1) ,
'%B %d, %Y')
           except:
               birthday=None
               birthday_dt=None

       f['birthday'] = birthday
       f['birthday_dt'] = birthday_dt
       new_f.append(f)
   new_f.sort(compare_by('birthday_dt'))

----------
files: data.log
messages: 65596
nosy: kevin3210
severity: normal
status: open
title: 64 bit python  memory leak usage
type: resource usage
versions: Python 2.5
Added file: http://bugs.python.org/file10051/data.log

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2652>
__________________________________

From report at bugs.python.org  Fri Apr 18 01:42:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 17 Apr 2008 23:42:44 +0000
Subject: [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1208475764.39.0.569495397718.issue2621@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Brett, comments?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2621>
__________________________________

From report at bugs.python.org  Fri Apr 18 02:22:43 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 18 Apr 2008 00:22:43 +0000
Subject: [issue2652] 64 bit python  memory leak usage
In-Reply-To: <1208471168.76.0.0271810352377.issue2652@psf.upfronthosting.co.za>
Message-ID: <1208478163.44.0.755261918737.issue2652@psf.upfronthosting.co.za>


Changes by Gregory P. Smith <greg at krypto.org>:


----------
nosy: +gregory.p.smith

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2652>
__________________________________

From report at bugs.python.org  Fri Apr 18 03:05:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Fri, 18 Apr 2008 01:05:46 +0000
Subject: [issue2621] rename test_support to support
In-Reply-To: <1207960346.09.0.959941490384.issue2621@psf.upfronthosting.co.za>
Message-ID: <1208480746.91.0.380395390734.issue2621@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I am going to assign this to me, but wait until Guido pronounces on PEP 
3108 before moving forward with a review.

----------
assignee:  -> brett.cannon

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2621>
__________________________________

From report at bugs.python.org  Fri Apr 18 03:08:17 2008
From: report at bugs.python.org (Russ Cox)
Date: Fri, 18 Apr 2008 01:08:17 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208465056.16.0.871421155437.issue2650@psf.upfronthosting.co.za>
Message-ID: <20080418011003.84E1C1E8C58@holo.morphisms.net>


Russ Cox <rsc at swtch.com> added the comment:

> It seems that escape is pretty dumb. The documentations says that
> re.escape escapes all non-alphanumeric characters, and it does that
> faithfully. It would seem more useful to have a list of meta-characters
> and just escape those. This is more true in Py3k when str can have
> thousands of possible characters that could be considered alphanumeric.

The usual convention is to escape everything that is
ASCII and not A-Za-z0-9_, in case other punctuation
becomes special in the future.  But I agree -- escaping
just the actual special characters makes the most sense.

Russ

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Fri Apr 18 03:19:36 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Apr 2008 01:19:36 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208481576.67.0.870709101003.issue2650@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Would you like to work on a patch?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Fri Apr 18 05:35:42 2008
From: report at bugs.python.org (atsuo ishimoto)
Date: Fri, 18 Apr 2008 03:35:42 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208166864.02.0.788613602223.issue2630@psf.upfronthosting.co.za>
Message-ID: <1208489742.4.0.540423106802.issue2630@psf.upfronthosting.co.za>


atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:

Is a codec which encode() returns an Unicode allowed in Python3? I
started to think codec is not nessesary, but python function is enough.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Fri Apr 18 09:17:06 2008
From: report at bugs.python.org (wr)
Date: Fri, 18 Apr 2008 07:17:06 +0000
Subject: [issue2653] string to float to int
In-Reply-To: <1208503026.4.0.816414644082.issue2653@psf.upfronthosting.co.za>
Message-ID: <1208503026.4.0.816414644082.issue2653@psf.upfronthosting.co.za>


New submission from wr <woutruijter at gmail.com>:

IDLE 1.2.1      
>>> print int(float('1.005')*1000)
1004

----------
components: None
messages: 65602
nosy: wr
severity: normal
status: open
title: string to float to int
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2653>
__________________________________

From report at bugs.python.org  Fri Apr 18 09:23:22 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Apr 2008 07:23:22 +0000
Subject: [issue2652] 64 bit python  memory leak usage
In-Reply-To: <1208471168.76.0.0271810352377.issue2652@psf.upfronthosting.co.za>
Message-ID: <1208503402.17.0.417077783515.issue2652@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Please provide a "main" function to test with.
I tried to write one based on your code; but memory usage was stable
after a few seconds.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2652>
__________________________________

From report at bugs.python.org  Fri Apr 18 09:34:58 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Apr 2008 07:34:58 +0000
Subject: [issue2653] string to float to int
In-Reply-To: <1208503026.4.0.816414644082.issue2653@psf.upfronthosting.co.za>
Message-ID: <1208504098.16.0.0457127955291.issue2653@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Yes, and 
  >>> 1.005 * 1000
  1004.9999999999999

Please read 
http://www.python.org/doc/faq/general/#why-are-floating-point-calculations-so-inaccurate

To perform exact base-10 calculation, you may use the Decimal module.
Or use round() instead of the int() truncation.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2653>
__________________________________

From report at bugs.python.org  Fri Apr 18 10:12:27 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Fri, 18 Apr 2008 08:12:27 +0000
Subject: [issue2653] string to float to int
In-Reply-To: <1208503026.4.0.816414644082.issue2653@psf.upfronthosting.co.za>
Message-ID: <1208506347.69.0.86336143163.issue2653@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

>>> int('%.0f' % (float('1.005')*1000))
1005

>>> int(Decimal('1.005')*1000)
1005

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2653>
__________________________________

From report at bugs.python.org  Fri Apr 18 10:46:12 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Fri, 18 Apr 2008 08:46:12 +0000
Subject: [issue2630] repr() should not escape non-ASCII characters
In-Reply-To: <1208489742.4.0.540423106802.issue2630@psf.upfronthosting.co.za>
Message-ID: <48085FC6.2070008@egenix.com>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

On 2008-04-18 05:35, atsuo ishimoto wrote:
> atsuo ishimoto <ishimoto at users.sourceforge.net> added the comment:
> 
> Is a codec which encode() returns an Unicode allowed in Python3?

Sure, why not ?

I think you have to ask another question: Is repr() allowed to
return a string (instead of Unicode) in Py3k ?

If not, then unicode_repr() will have to check the return value of
the codec and convert it back to Unicode as necessary.

> I started to think codec is not nessesary, but python function is enough.

That's what we currently have with unicode_repr(), but it doesn't
solve the problem.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2630>
__________________________________

From report at bugs.python.org  Fri Apr 18 11:26:24 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 18 Apr 2008 09:26:24 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208510784.65.0.149687431231.issue2632@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

However it should be fixed in release25-maint. Can anyone install curt's
patch? It does what the original fix intended to do.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Fri Apr 18 11:33:59 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Fri, 18 Apr 2008 09:33:59 +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: <1208511239.51.0.765619698382.issue2014@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

guido says it's ok to fix the issue in xmlrpclib only:
http://mail.python.org/pipermail/python-dev/2008-April/078396.html

I'm also attaching a dummy.diff in order to have a patch keyword...
If someone is willing to commit this, I'll check if it still applies to
trunk and maybe update the diff.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Fri Apr 18 11:36:17 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 18 Apr 2008 09:36:17 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1208511377.56.0.892064553052.issue2651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Here is another form of the same inconsistency:

>>> [].pop(0)
IndexError: pop from empty list
>>> {}.pop(0)
KeyError: 'pop(): dictionary is empty'

And my preferred one:
>>> unicodedata.lookup('"')
KeyError: 'undefined character name \'"\''

KeyError is special in that dict lookup raises the equivalent of
KeyError(key). Since the key may be any kind of (hashable) object, it's
preferable to repr() it.

I can see 3 solutions to the problem:

1- imitate IndexError for lists: the exception do not contain the key.

2- dict lookup builds the complete string message, and raise it
   raise KeyError("key not found: %r" % key)
then KeyError.__str__ can be removed.

3- like IOError, KeyError has "msg" and "key" attributes. then dict
lookup raises
   raise KeyError("key not found", key)
and KeyError.__str__ is something like:
   if self.key is not None:
       return "%s: %r" % (self.msg, self.key)
   else
       return str(self.msg)

Choice 1 is not an improvement.
Choice 2 has the correct behavior but leads to performance problems;
KeyErrors are very very common in the interpreter (namespace lookups...)
and formatting the message is costly.
Choice 3 may cause regression for code that use exception.args[0], but
otherwise seems the best to me. I'll try to come with a patch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
__________________________________

From report at bugs.python.org  Fri Apr 18 13:42:13 2008
From: report at bugs.python.org (Christian Heimes)
Date: Fri, 18 Apr 2008 11:42:13 +0000
Subject: [issue1731717] race condition in subprocess module
Message-ID: <1208518933.72.0.126331876272.issue1731717@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

This popped up on the mailing list today.

Please give this bug a proper review. I *believe* it's fixed but I'm not
sure.

----------
nosy: +tiran
priority: normal -> critical
type:  -> behavior
versions: +Python 2.5, Python 2.6, Python 3.0 -Python 2.4

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1731717>
_____________________________________

From report at bugs.python.org  Fri Apr 18 15:00:02 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 18 Apr 2008 13:00:02 +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: <1208523602.33.0.302725861388.issue2014@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

working on it

----------
assignee:  -> skip.montanaro
nosy: +skip.montanaro

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Fri Apr 18 15:03:22 2008
From: report at bugs.python.org (Ismail Donmez)
Date: Fri, 18 Apr 2008 13:03:22 +0000
Subject: [issue2654] Typo at
	http://docs.python.org/dev/3.0/howto/doanddont.html
In-Reply-To: <1208523802.33.0.053016703897.issue2654@psf.upfronthosting.co.za>
Message-ID: <1208523802.33.0.053016703897.issue2654@psf.upfronthosting.co.za>


New submission from Ismail Donmez <ismail at namtrac.org>:

At top it says "This document is placed in the public doman." should do
a s/doman/domain .

----------
assignee: georg.brandl
components: Documentation
messages: 65612
nosy: cartman, georg.brandl
severity: normal
status: open
title: Typo at http://docs.python.org/dev/3.0/howto/doanddont.html
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2654>
__________________________________

From report at bugs.python.org  Fri Apr 18 15:38:58 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 18 Apr 2008 13:38:58 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208525938.66.0.814295819027.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Here are the modification so far for item 9) in _sre.c plus some small
modifications to sre_constants.h which are only to get _sre.c to
compile; normally sre_constants.h is generated by sre_constants.py, so
this is not the final version of that file.  I also would have intended
to make SRE_CHARSET and SRE_COUNT use lookup tables, as well as maybe
others, but not likely any other lookup tables.  I also want to remove
alloc_pos out of the self object and make it a parameter to the ALLOC
parameter and probably get rid of the op_code attribute since it is only
used in 1 place to save one subtract in a very rare case.  But I want to
resolve the 10% problem first, so would appreciate it if people could
look at the REMOVE_SRE_MATCH_MACROS section of code and compare it to
the non-REMOVE_SRE_MATCH_MACROS version of SRE_MATCH and see if you can
suggest anything to make the former (new code) faster to get me that
elusive 10%.

----------
keywords: +patch
Added file: http://bugs.python.org/file10052/issue2636-09.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Fri Apr 18 16:23:20 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 18 Apr 2008 14:23:20 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208528600.01.0.0594079907468.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Here is a patch to implement item 7)

Added file: http://bugs.python.org/file10053/issue2636-07.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Fri Apr 18 16:45:24 2008
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 18 Apr 2008 14:45:24 +0000
Subject: [issue2250] rlcompleter raises Exception on bad input
In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za>
Message-ID: <1208529924.07.0.136363338448.issue2250@psf.upfronthosting.co.za>


Lorenz Quack <don at amberfisharts.com> added the comment:

I attached a patch for the docs.
It now states that the rlcompleter.Completer will catch and silence all
exceptions raised by evaluating the expression passed to complete()

Added file: http://bugs.python.org/file10054/rlcompleter.rst.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2250>
__________________________________

From report at bugs.python.org  Fri Apr 18 16:47:44 2008
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 18 Apr 2008 14:47:44 +0000
Subject: [issue2250] rlcompleter raises Exception on bad input
In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za>
Message-ID: <1208530064.35.0.76393755398.issue2250@psf.upfronthosting.co.za>


Lorenz Quack <don at amberfisharts.com> added the comment:

In the last patch I used the wrong ticks. I hope it's fine like this.

Added file: http://bugs.python.org/file10055/rlcompleter.rst.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2250>
__________________________________

From report at bugs.python.org  Fri Apr 18 16:47:52 2008
From: report at bugs.python.org (Lorenz Quack)
Date: Fri, 18 Apr 2008 14:47:52 +0000
Subject: [issue2250] rlcompleter raises Exception on bad input
In-Reply-To: <1204886997.65.0.75088007868.issue2250@psf.upfronthosting.co.za>
Message-ID: <1208530072.94.0.518161568008.issue2250@psf.upfronthosting.co.za>


Changes by Lorenz Quack <don at amberfisharts.com>:


Removed file: http://bugs.python.org/file10054/rlcompleter.rst.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2250>
__________________________________

From report at bugs.python.org  Fri Apr 18 16:50:45 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 18 Apr 2008 14:50:45 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1208530245.13.0.649694791501.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

This simple patch adds (?P#...)-style comment support.

Added file: http://bugs.python.org/file10056/issue2636-05.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Fri Apr 18 18:53:40 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 18 Apr 2008 16:53:40 +0000
Subject: [issue2654] Typo at
	http://docs.python.org/dev/3.0/howto/doanddont.html
In-Reply-To: <1208523802.33.0.053016703897.issue2654@psf.upfronthosting.co.za>
Message-ID: <1208537620.8.0.381884860066.issue2654@psf.upfronthosting.co.za>


A.M. Kuchling <lists at amk.ca> added the comment:

Fixed in r62373; thanks for reporting this!

----------
assignee: georg.brandl -> akuchling
nosy: +akuchling
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2654>
__________________________________

From report at bugs.python.org  Fri Apr 18 19:31:03 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Fri, 18 Apr 2008 17:31:03 +0000
Subject: [issue1184112] Missing trailing newline with comment raises
	SyntaxError
Message-ID: <1208539863.15.0.0383717155456.issue1184112@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Yeah, it's actually still blowing up for me to. I have no idea what I
actually tested when I thought it was working in 2.6/3.0 - I must have
managed to sneak an extra carriage return into the test string. So
reverting back to marking it as a non-easy interpreter core problem.

----------
components: +Interpreter Core -Documentation

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1184112>
_____________________________________

From report at bugs.python.org  Fri Apr 18 20:31:04 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Apr 2008 18:31:04 +0000
Subject: [issue2655] Create ctypes instances from buffer interface
In-Reply-To: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>
Message-ID: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

This patch implements a .from_buffer(source, offset=0) class method from
ctypes types.  'source' must expose a writeable buffer interface; the
created ctypes instance will share the internal buffer of the source
object; also it holds a reference to the source object to keep it alive.

The usual problems with the buffer interface are not hidden.

Open question:
Should there be an additional 'copy_from_buffer' class method that
accepts read-only buffer interface (as an alternative, an optional
'copy=False' parameter could be introduced)?

----------
assignee: theller
components: ctypes
files: from_buffer.patch
keywords: patch, patch
messages: 65620
nosy: theller
severity: normal
status: open
title: Create ctypes instances from buffer interface
versions: Python 2.6
Added file: http://bugs.python.org/file10057/from_buffer.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2655>
__________________________________

From report at bugs.python.org  Fri Apr 18 20:31:14 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 18 Apr 2008 18:31:14 +0000
Subject: [issue2655] Create ctypes instances from buffer interface
In-Reply-To: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>
Message-ID: <1208543474.35.0.481447735073.issue2655@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2655>
__________________________________

From report at bugs.python.org  Fri Apr 18 21:24:26 2008
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Apr 2008 19:24:26 +0000
Subject: [issue2416] % string formatting does not support %b
In-Reply-To: <1205898810.27.0.827801711663.issue2416@psf.upfronthosting.co.za>
Message-ID: <1208546666.56.0.272285670646.issue2416@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

On the python-3000 list we decided not to add new features to %
formatting, since it will be deprecated in favor of str.format.

----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2416>
__________________________________

From report at bugs.python.org  Fri Apr 18 21:24:55 2008
From: report at bugs.python.org (Eric Smith)
Date: Fri, 18 Apr 2008 19:24:55 +0000
Subject: [issue2416] % string formatting does not support %b
In-Reply-To: <1205898810.27.0.827801711663.issue2416@psf.upfronthosting.co.za>
Message-ID: <1208546695.54.0.642864168269.issue2416@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

I should have noted that the PEP was modified to remove %b and %#b
formatting.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2416>
__________________________________

From report at bugs.python.org  Fri Apr 18 22:36:30 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Fri, 18 Apr 2008 20:36:30 +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: <1208550989.94.0.727939363793.issue2014@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Checked in on trunk as r62378.  Will let the normal 3.0 merge process
suck it over to the py3k branch.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Fri Apr 18 23:02:44 2008
From: report at bugs.python.org (John Millikin)
Date: Fri, 18 Apr 2008 21:02:44 +0000
Subject: [issue2656] Autodoc should skip inherited methods
In-Reply-To: <1208552563.99.0.233047062632.issue2656@psf.upfronthosting.co.za>
Message-ID: <1208552563.99.0.233047062632.issue2656@psf.upfronthosting.co.za>


New submission from John Millikin <jmillikin at gmail.com>:

Using the following class layout:

class A (object):
	def a (self):
		"A.a"
		pass
class B (A):
	def b (self):
		"B.b"
		pass

If sphinx.ext.autodoc is used to extract documentation, the entry for
class B will have subentries for both the a() and b() methods. This is
unnecessary clutter. It would be nice if the inherited method was
skipped when documenting B, or even better if it was inserted as a
"stub" linking to the documentation for A.a().

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 65624
nosy: georg.brandl, jmillikin
severity: normal
status: open
title: Autodoc should skip inherited methods
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2656>
__________________________________

From report at bugs.python.org  Fri Apr 18 23:23:20 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 18 Apr 2008 21:23:20 +0000
Subject: [issue2458] Allow Python code to change Py3k warning flag
In-Reply-To: <1206221345.67.0.966605700107.issue2458@psf.upfronthosting.co.za>
Message-ID: <1208553799.7.0.10468803507.issue2458@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

As suggested by Christian, this patch changes the method names to
setpy3kwarn and getpy3kwarn.

----------
nosy: +tiran
Added file: http://bugs.python.org/file10058/change_py3kwarning2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2458>
__________________________________

From report at bugs.python.org  Sat Apr 19 00:41:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 18 Apr 2008 22:41:40 +0000
Subject: [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208558500.38.0.023173186042.issue2645@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2645>
__________________________________

From report at bugs.python.org  Sat Apr 19 00:51:09 2008
From: report at bugs.python.org (=?utf-8?q?Fernando_P=C3=A9rez?=)
Date: Fri, 18 Apr 2008 22:51:09 +0000
Subject: [issue2657] curses
In-Reply-To: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>
Message-ID: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>


New submission from Fernando P?rez <fer_perez at users.sourceforge.net>:

Curses sometimes fails to correctly initialize the terminal. 
Unfortunately I don't know how to reproduce the problem, it was reported
multiple times by ipython users, but I have no idea what causes it.  I
finally found a workaround by making a termios call that at least
restores terminal state (see attachment), but it's just a workaround,
not a real fix.

The issue manifests itself as follows: at some point (I don't know why),
a call to curses.initscr() doesn't actually set the terminal in the
usual mode where input isn't accepted, but instead the terminal
continues accepting normal input, issuing newlines, etc.  The only sign
that curses is active is that in a modern terminal, the scrollbar
changes to fill the screen.  After this, calling curses.endwin(),
instead of restoring terminal state, leaves the terminal in the mode
that typically initscr() would put it in: no input is displayed,
printouts swallow end-of-line characters, etc.

When this happened in ipython sessions, we'd just suggest users call
!reset (the system command), which would restore terminal state.  But
the problem is obviously in curses itself, because once this problem
appeared, running the attached script would always print 'False' for the
state condition checked there.

For now in IPython we have a workaround, but perhaps with this little
description/example, someone who knows the curses code might be able to
actually fix the real problem.  If I find a reliable way to trigger the
bug, I'll add comments here indicating so.

----------
components: Extension Modules
files: cursesbug.py
messages: 65626
nosy: fer_perez
severity: normal
status: open
title: curses
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10059/cursesbug.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2657>
__________________________________

From report at bugs.python.org  Sat Apr 19 01:32:19 2008
From: report at bugs.python.org (Niall O'Higgins)
Date: Fri, 18 Apr 2008 23:32:19 +0000
Subject: [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208561539.84.0.826789747928.issue2645@psf.upfronthosting.co.za>


Niall O'Higgins <niallo at unworkable.org> added the comment:

Unfortunately I do not get this consistently from any URL.  My code is
periodically polling a single HTTP server over the Internet.  Quite
possibly it is triggered by some random network/remote server condition. 

I have not had the chance to look deeply into the RFC yet.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2645>
__________________________________

From report at bugs.python.org  Sat Apr 19 08:23:33 2008
From: report at bugs.python.org (Piet Delport)
Date: Sat, 19 Apr 2008 06:23:33 +0000
Subject: [issue2604] doctest.DocTestCase fails when run repeatedly
In-Reply-To: <1207798847.15.0.203205049744.issue2604@psf.upfronthosting.co.za>
Message-ID: <1208586213.52.0.873928290249.issue2604@psf.upfronthosting.co.za>


Changes by Piet Delport <pjdelport at gmail.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file10060/reset_globs.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2604>
__________________________________

From report at bugs.python.org  Sat Apr 19 10:14:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Apr 2008 08:14:58 +0000
Subject: [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208592898.25.0.179806603657.issue2645@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

The trunk version does already handle this: it closes the connection and
raises IncompleteRead.

----------
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2645>
__________________________________

From report at bugs.python.org  Sat Apr 19 11:06:52 2008
From: report at bugs.python.org (Michael Amrhein)
Date: Sat, 19 Apr 2008 09:06:52 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1208596012.43.0.069600984327.issue1738@psf.upfronthosting.co.za>


Michael Amrhein <mamrhein at users.sourceforge.net> added the comment:

There is one small issue I would like to discuss:
While the comparison of directory and file names in phase1 is
case-insensitive on case-insensitive systems (os.path.normcase applied
to each name), the filtering of ignore and hide in phase0 isn't. 
I can't imagine a good reason for this and would like to change it by
also applying os.name.normcase to each name in ignore and hide.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
__________________________________

From report at bugs.python.org  Sat Apr 19 14:41:34 2008
From: report at bugs.python.org (Christoph Schneeberger)
Date: Sat, 19 Apr 2008 12:41:34 +0000
Subject: [issue2658] decode_header() fails on multiline headers
In-Reply-To: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za>
Message-ID: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za>


New submission from Christoph Schneeberger <cschnee at telemedia.ch>:

email.Header.decode_header() does not correctly deal with multiline
Headerlines.
header.py in revision 54371 (1) changes the behaviour, whereas
previously multiline headers where parsed correctly, header.py 54371
introduced a new regex part, that renders such headers invalid and they
won't be parsed as expected.
Given the following header line (doesn't matter if its parsed from a
mail or read from a string) which represents IMHO a valid RFC2047 header
line:

from email.Header import decode_header
decode_header('=?windows-1252?Q?=22M=FCller_T=22?=\r\n <T.Mueller at xxx.com>')

this will result in:
header.py (54371):
[('=?windows-1252?Q?=22M=FCller_T=22?=\r\n <T.Mueller at xxx.com>', None)]

resp. with header.py (54370):
[('"M\xfcller T"', 'windows-1252'), (' <T.Mueller at xxx.com>', None)]

Actually both seem parsed wrong, but with 54370 the result looks more
sane (the space should be IMO removed). 
Once the CRLF sequence is removed from the header it works fine and all
looks as expected:
>>> decode_header('=?windows-1252?Q?=22M=FCller_T=22?= <T.Mueller at xxx.com>')
[('"M\xfcller T"', 'windows-1252'), ('<T.Mueller at xxx.com>', None)]

This problem might or might not be related to 
- issue 1372770 
- issue 1467619

(1) http://svn.python.org/view?rev=54371&view=rev

----------
components: Library (Lib)
messages: 65630
nosy: cschnee
severity: normal
status: open
title: decode_header() fails on multiline headers
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2658>
__________________________________

From report at bugs.python.org  Sat Apr 19 17:33:03 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Apr 2008 15:33:03 +0000
Subject: [issue2658] decode_header() fails on multiline headers
In-Reply-To: <1208608894.4.0.0735061784066.issue2658@psf.upfronthosting.co.za>
Message-ID: <1208619183.95.0.717339639819.issue2658@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> barry
nosy: +barry

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2658>
__________________________________

From report at bugs.python.org  Sat Apr 19 18:59:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Apr 2008 16:59:01 +0000
Subject: [issue2639] shutil.copyfile() documentation is vague
In-Reply-To: <1208275866.73.0.43584708825.issue2639@psf.upfronthosting.co.za>
Message-ID: <1208624338.77.0.84160391249.issue2639@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r62389.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2639>
__________________________________

From report at bugs.python.org  Sat Apr 19 18:59:38 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Apr 2008 16:59:38 +0000
Subject: [issue2634] os.execvpe() docs need to be more specific
In-Reply-To: <1208233905.92.0.0192378489654.issue2634@psf.upfronthosting.co.za>
Message-ID: <1208624378.22.0.789859311758.issue2634@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r62390.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2634>
__________________________________

From report at bugs.python.org  Sat Apr 19 18:59:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Apr 2008 16:59:40 +0000
Subject: [issue2633] Improve subprocess.Popen() documentation ("env" parameter)
In-Reply-To: <1208205877.08.0.141694096579.issue2633@psf.upfronthosting.co.za>
Message-ID: <1208624380.79.0.0270308299915.issue2633@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r62391.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2633>
__________________________________

From report at bugs.python.org  Sat Apr 19 19:00:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 19 Apr 2008 17:00:25 +0000
Subject: [issue2631] IMPORT_NAME Documentation is incomplete
In-Reply-To: <1208197331.08.0.00587234594445.issue2631@psf.upfronthosting.co.za>
Message-ID: <1208624425.1.0.140906682813.issue2631@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r62392.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2631>
__________________________________

From report at bugs.python.org  Sat Apr 19 22:00:59 2008
From: report at bugs.python.org (Sylvain Fourmanoit)
Date: Sat, 19 Apr 2008 20:00:59 +0000
Subject: [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>


New submission from Sylvain Fourmanoit <syfou at users.sourceforge.net>:

The textwrap module in standard library breaks hyphenated words given
the opportunity; I don't think that's absolutely obvious from the
current doc, and it's something worth mentioning. 

Here is a short addition to the library reference guide.

Initial discussion started here:
http://mail.python.org/pipermail/stdlib-sig/2008-April/000265.html

----------
components: Library (Lib)
files: textwrap_hyphens_doc.patch
keywords: patch
messages: 65635
nosy: fourmanoit
severity: normal
status: open
title: textwrap handling of hyphenation
versions: Python 2.6
Added file: http://bugs.python.org/file10061/textwrap_hyphens_doc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2659>
__________________________________

From report at bugs.python.org  Sat Apr 19 22:07:30 2008
From: report at bugs.python.org (Sylvain Fourmanoit)
Date: Sat, 19 Apr 2008 20:07:30 +0000
Subject: [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208635650.19.0.467028814544.issue2659@psf.upfronthosting.co.za>


Sylvain Fourmanoit <syfou at users.sourceforge.net> added the comment:

I also think it would be nice if a public interface to completely avoid
breaking hyphenated words would be included; patch included: it's pretty
light, and should have no impact on any code currently using textwrap.

Added file: http://bugs.python.org/file10062/textwrap_break_on_hyphens.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2659>
__________________________________

From report at bugs.python.org  Sat Apr 19 22:16:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 19 Apr 2008 20:16:46 +0000
Subject: [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208636206.01.0.066426297335.issue2659@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> georg.brandl
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2659>
__________________________________

From report at bugs.python.org  Sat Apr 19 23:05:02 2008
From: report at bugs.python.org (Brandon Ehle)
Date: Sat, 19 Apr 2008 21:05:02 +0000
Subject: [issue2660] 2to3 throws a utf8 decode error on a iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>


New submission from Brandon Ehle <azverkan at gmail.com>:

While running the 2to3 script on the scons codebase, I ran into an
UnicodeDecodeError.

Attached is just the portion of the script that causes the error.

2to3 throws an error on the string regardless of whether the unicode
string literal is prepended on the front.

RefactoringTool: Skipping implicit fixer: buffer
RefactoringTool: Skipping implicit fixer: idioms
RefactoringTool: Skipping implicit fixer: ws_comma
Traceback (most recent call last):
  File "/usr/local/bin/2to3", line 5, in <module>
    sys.exit(refactor.main())
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 81, in main
    rt.refactor_args(args)
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 188, in
refactor_args
    self.refactor_file(arg)
  File "/usr/local/lib/python3.0/lib2to3/refactor.py", line 217, in
refactor_file
    input = f.read() + "\n" # Silence certain parse errors
  File "/usr/local/lib/python3.0/io.py", line 1611, in read
    decoder.decode(self.buffer.read(), final=True))
  File "/usr/local/lib/python3.0/io.py", line 1199, in decode
    output = self.decoder.decode(input, final=final)
  File "/usr/local/lib/python3.0/codecs.py", line 300, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf8' codec can't decode bytes in position 59-60:
invalid data

----------
assignee: collinwinter
components: 2to3 (2.x to 3.0 conversion tool)
files: 2to3bug.py
messages: 65637
nosy: azverkan, collinwinter
severity: normal
status: open
title: 2to3 throws a utf8 decode error on a iso-8859-1 string
versions: Python 3.0
Added file: http://bugs.python.org/file10063/2to3bug.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2660>
__________________________________

From report at bugs.python.org  Sat Apr 19 23:48:49 2008
From: report at bugs.python.org (Collin Winter)
Date: Sat, 19 Apr 2008 21:48:49 +0000
Subject: [issue2660] 2to3 throws a utf8 decode error on a iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1208641729.72.0.0569124152043.issue2660@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

2to3 running under Python 2.5.1 handles this file just fine. 2to3
running under 3.0a4+ (r62404) fails as detailed below. However, that
file doesn't run correctly under Python itself:

collinwinter at Silves:~/src/python/py3k$ ./python
/home/collinwinter/Desktop/2to3bug.py 
  File "/home/collinwinter/Desktop/2to3bug.py", line 3
    collinwinter at Silves:~/src/python/py3k

This suggests this problem isn't 2to3-specific. Refiling this issue
against py3k's Unicode support.

----------
assignee: collinwinter -> 
components: +Unicode -2to3 (2.x to 3.0 conversion tool)
priority:  -> high

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2660>
__________________________________

From report at bugs.python.org  Sun Apr 20 00:09:33 2008
From: report at bugs.python.org (David Anderson)
Date: Sat, 19 Apr 2008 22:09:33 +0000
Subject: [issue2661] Mapping tests cannot be passed by user implementations
In-Reply-To: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>
Message-ID: <1208642973.7.0.825847798287.issue2661@psf.upfronthosting.co.za>


New submission from David Anderson <dave at natulte.net>:

Some test cases in Lib/test/mapping_tests.py are problematic for users
wishing to test their own implementations of the mapping protocol: 

 - TestHashMappingProtocol.test_repr() requires the user implementations
to look like a dict when repr() is applied. It is unclear why this is
required of conforming mapping protocol implementations.
 - TestMappingProtocol.test_fromkeys() cannot pass for any
implementation that uses its constructor in fromkeys(), because baddict1
defines a constructor accepting no arguments. It should accept *args,
**kwargs to be sane for user implementations that handle passing data
sources to the constructor.
 - TestHashMappingProtocol.test_mutatingiteration(), for some faulty
implementations, makes the iteration degrade into an infinite loop.
Making the test more strict (eg. keeping an explicit iteration count and
failing if it goes >1) would be more helpful to buggy implementations.

These all seem like trivial issues. If it is agreed that the repr_test
should be removed from the ABC tests, I can provide a patch implementing
these three corrections.

----------
components: Library (Lib)
messages: 65639
nosy: danderson
severity: normal
status: open
title: Mapping tests cannot be passed by user implementations
type: behavior
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2661>
__________________________________

From report at bugs.python.org  Sun Apr 20 00:16:59 2008
From: report at bugs.python.org (Collin Winter)
Date: Sat, 19 Apr 2008 22:16:59 +0000
Subject: [issue2660] Py3k fails to parse a file with an iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1208643419.44.0.959019510755.issue2660@psf.upfronthosting.co.za>


Changes by Collin Winter <collinw at gmail.com>:


----------
title: 2to3 throws a utf8 decode error on a iso-8859-1 string -> Py3k fails to parse a file with an iso-8859-1 string

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2660>
__________________________________

From report at bugs.python.org  Sun Apr 20 02:33:20 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Sun, 20 Apr 2008 00:33:20 +0000
Subject: [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208651600.44.0.299157600254.issue2645@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

could you backport that to release25-maint if it isn't there already?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2645>
__________________________________

From report at bugs.python.org  Sun Apr 20 03:38:10 2008
From: report at bugs.python.org (Brandon Ehle)
Date: Sun, 20 Apr 2008 01:38:10 +0000
Subject: [issue2660] Py3k fails to parse a file with an iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1208655490.1.0.228965994055.issue2660@psf.upfronthosting.co.za>


Brandon Ehle <azverkan at gmail.com> added the comment:

Someone on the #python IRC channel suggested that the default for python
3.0 for unicode string literals is reversed from python 2.5.

If you remove the unicode string literal (u'') from the front of the
string, it runs fine under python 3.0 and fails under 2.5 and 2.6 instead.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2660>
__________________________________

From report at bugs.python.org  Sun Apr 20 03:40:02 2008
From: report at bugs.python.org (Brandon Ehle)
Date: Sun, 20 Apr 2008 01:40:02 +0000
Subject: [issue2660] Py3k fails to parse a file with an iso-8859-1 string
In-Reply-To: <1208639102.05.0.334372746111.issue2660@psf.upfronthosting.co.za>
Message-ID: <1208655602.68.0.333622582695.issue2660@psf.upfronthosting.co.za>


Brandon Ehle <azverkan at gmail.com> added the comment:

Also, I can confirm that running 2to3 with Python 2.6 correctly converts
the script but running 2to3 with Python 3.0 results in a
UnicodeDecodeError exception.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2660>
__________________________________

From report at bugs.python.org  Sun Apr 20 10:00:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 20 Apr 2008 08:00:40 +0000
Subject: [issue2645] httplib throws ValueError
In-Reply-To: <1208369760.69.0.00152295436269.issue2645@psf.upfronthosting.co.za>
Message-ID: <1208678440.25.0.425088523723.issue2645@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I decided not to do that since it changes the exception raised, which I
guess the release managers won't view as a bugfix.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2645>
__________________________________

From report at bugs.python.org  Sun Apr 20 13:52:04 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sun, 20 Apr 2008 11:52:04 +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: <1208692324.84.0.693266299898.issue2014@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

Skip, thanks for handling this.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2014>
__________________________________

From report at bugs.python.org  Sun Apr 20 15:15:19 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Apr 2008 13:15:19 +0000
Subject: [issue2635] textwrap: bug in 'fix_sentence_endings' option
In-Reply-To: <1208238885.76.0.507566596531.issue2635@psf.upfronthosting.co.za>
Message-ID: <1208697318.85.0.295995519597.issue2635@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I can reproduce the problem, and agree with the analysis.

Giuseppe, do you have time to produce a patch that fixes
this problem and adds appropriate tests to test_textwrap.py?

----------
keywords: +easy
nosy: +marketdickinson
priority:  -> normal
versions: +Python 2.5, Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2635>
__________________________________

From report at bugs.python.org  Sun Apr 20 15:30:47 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 20 Apr 2008 13:30:47 +0000
Subject: [issue2662] Allows HUGE_VAL as extern variable
In-Reply-To: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>
Message-ID: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

>/* On Windows HUGE_VAL is an extern variable and not a constant. Since the
>   special value arrays need a constant we have to roll our own infinity
>   and nan. */

This patch removes this limitation.

----------
components: Extension Modules
messages: 65646
nosy: ocean-city
severity: normal
status: open
title: Allows HUGE_VAL as extern variable
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2662>
__________________________________

From report at bugs.python.org  Sun Apr 20 15:34:55 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Sun, 20 Apr 2008 13:34:55 +0000
Subject: [issue2662] Allows HUGE_VAL as extern variable
In-Reply-To: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>
Message-ID: <1208698495.71.0.701720457614.issue2662@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


----------
keywords: +patch
Added file: http://bugs.python.org/file10064/cmathmodule.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2662>
__________________________________

From report at bugs.python.org  Sun Apr 20 15:35:17 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Apr 2008 13:35:17 +0000
Subject: [issue2662] Allows HUGE_VAL as extern variable
In-Reply-To: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>
Message-ID: <1208698517.86.0.0666638355701.issue2662@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Sounds good.

What patch?  :-)

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2662>
__________________________________

From report at bugs.python.org  Sun Apr 20 15:37:45 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Apr 2008 13:37:45 +0000
Subject: [issue2662] Allows HUGE_VAL as extern variable
In-Reply-To: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>
Message-ID: <1208698665.15.0.257364732838.issue2662@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Got it. Thanks.  This may also fix the failure to build cmath on alpha 
Tru64.

----------
assignee:  -> marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2662>
__________________________________

From report at bugs.python.org  Sun Apr 20 16:33:42 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Apr 2008 14:33:42 +0000
Subject: [issue2662] Allows HUGE_VAL as extern variable
In-Reply-To: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>
Message-ID: <1208702022.77.0.225406207663.issue2662@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2662>
__________________________________

From report at bugs.python.org  Sun Apr 20 18:14:27 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sun, 20 Apr 2008 16:14:27 +0000
Subject: [issue2662] Allows HUGE_VAL as extern variable
In-Reply-To: <1208698247.44.0.753659543665.issue2662@psf.upfronthosting.co.za>
Message-ID: <1208708066.4.0.390412588716.issue2662@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Applied in r62418.

Thank you very much!

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2662>
__________________________________

From report at bugs.python.org  Sun Apr 20 18:27:13 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 20 Apr 2008 16:27:13 +0000
Subject: [issue2562] Cannot use non-ascii letters in disutils if setuptools is
	used.
In-Reply-To: <1207475239.5.0.0696358951433.issue2562@psf.upfronthosting.co.za>
Message-ID: <1208708833.01.0.666864726215.issue2562@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I suppose the simplest way to deal with the problem is to force utf-8
encoding for the concerned fields, since this problem will dissapear in 3k.
 
Here's a simplified patch, that does it, so write_pkg_file behaves as
expected.

Added file: http://bugs.python.org/file10065/distutils.unicode.simplified.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2562>
__________________________________

From report at bugs.python.org  Sun Apr 20 20:16:22 2008
From: report at bugs.python.org (Greg Detre)
Date: Sun, 20 Apr 2008 18:16:22 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1208715382.38.0.79048497822.issue1160@psf.upfronthosting.co.za>


Greg Detre <greg at gregdetre.co.uk> added the comment:

Dear all,

I've just switched from linux to a mac, and I'm suddenly starting to
experience this issue with a machine-generated regexp that I depend on.
Are there any plans to fix this in a future version of python?

Thank you,
   Greg

----------
nosy: +greg at gregdetre.co.uk

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
__________________________________

From report at bugs.python.org  Sun Apr 20 22:04:37 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Sun, 20 Apr 2008 20:04:37 +0000
Subject: [issue2623] Patch: xmlrpclib client ignores datetime tzinfo when
	creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1208721877.58.0.328686881915.issue2623@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2623>
__________________________________

From report at bugs.python.org  Sun Apr 20 23:28:24 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 20 Apr 2008 21:28:24 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>


New submission from Tarek Ziad? <ziade.tarek at gmail.com>:

Here's a first draft of a small addon to shutil.copytree.

This patch allows excluding some folders or files from the copy, given
glob-style patterns. A callable can also be provided instead of the
patterns, for a more complex filtering.

I didn't upgrade Doc/shutil.rst yet in this patch, as this can be done
when the change will be accepted and in its final shape I guess.

----------
components: Library (Lib)
files: shutil.copytree.filtering.patch
keywords: patch
messages: 65652
nosy: tarek
severity: normal
status: open
title: shutil.copytree glob-style filtering [patch]
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10066/shutil.copytree.filtering.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 21 00:27:24 2008
From: report at bugs.python.org (Gustavo J. A. M. Carneiro)
Date: Sun, 20 Apr 2008 22:27:24 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1208730444.23.0.732198729143.issue2663@psf.upfronthosting.co.za>


Changes by Gustavo J. A. M. Carneiro <gjcarneiro at gmail.com>:


----------
nosy: +gustavo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 21 01:03:42 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 20 Apr 2008 23:03:42 +0000
Subject: [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208732622.54.0.185808950823.issue2659@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Two things:
- I think the added argument should come at the end of the argument
list, so that code currently passing `drop_whitespace` positionally
isn't broken by the change
- it would be nice to have unit tests

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2659>
__________________________________

From report at bugs.python.org  Mon Apr 21 01:41:20 2008
From: report at bugs.python.org (Sylvain Fourmanoit)
Date: Sun, 20 Apr 2008 23:41:20 +0000
Subject: [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208734880.2.0.839958494473.issue2659@psf.upfronthosting.co.za>


Sylvain Fourmanoit <syfou at users.sourceforge.net> added the comment:

Thanks for the feedback. Enclosed patch:

- moves the added "break_on_hyphens" argument at the end of the argument
list
- adds a unit test for the new attribute

Added file: http://bugs.python.org/file10067/textwrap_break_on_hyphens_2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2659>
__________________________________

From report at bugs.python.org  Mon Apr 21 01:43:41 2008
From: report at bugs.python.org (Sylvain Fourmanoit)
Date: Sun, 20 Apr 2008 23:43:41 +0000
Subject: [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208735021.85.0.436462700889.issue2659@psf.upfronthosting.co.za>


Changes by Sylvain Fourmanoit <syfou at users.sourceforge.net>:


Removed file: http://bugs.python.org/file10061/textwrap_hyphens_doc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2659>
__________________________________

From report at bugs.python.org  Mon Apr 21 01:44:11 2008
From: report at bugs.python.org (Sylvain Fourmanoit)
Date: Sun, 20 Apr 2008 23:44:11 +0000
Subject: [issue2659] textwrap handling of hyphenation
In-Reply-To: <1208635259.55.0.563254480753.issue2659@psf.upfronthosting.co.za>
Message-ID: <1208735051.13.0.674378087567.issue2659@psf.upfronthosting.co.za>


Changes by Sylvain Fourmanoit <syfou at users.sourceforge.net>:


Added file: http://bugs.python.org/file10068/textwrap_hyphens_doc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2659>
__________________________________

From report at bugs.python.org  Mon Apr 21 01:53:05 2008
From: report at bugs.python.org (Giuseppe Scelsi)
Date: Sun, 20 Apr 2008 23:53:05 +0000
Subject: [issue2635] textwrap: bug in 'fix_sentence_endings' option
In-Reply-To: Message from Mark Dickinson <report@bugs.python.org> of "Sun,
	20 Apr 2008 13:15:19 GMT."
	<1208697318.85.0.295995519597.issue2635@psf.upfronthosting.co.za>
Message-ID: <200804202352.m3KNqwOX013275@bunyip.spd.analog.com>


Giuseppe Scelsi <giuseppe.scelsi at analog.com> added the comment:

Mark,

I am not familiar with the process and at this particular time I am
quite busy.  I am happy to do it if it not urgent, but that might mean
after I come back from overseas in June.  Otherwise please go ahead with
the changes, for someone familiar with the process it should be a very
simple matter.  PLease let me know.

Thanks and regards,

Giuseppe

----

> Mark Dickinson <dickinsm at gmail.com> added the comment:
>
> I can reproduce the problem, and agree with the analysis.
>
> Giuseppe, do you have time to produce a patch that fixes
> this problem and adds appropriate tests to test_textwrap.py?
>
> ----------
> keywords: +easy
> nosy: +marketdickinson
> priority:  -> normal
> versions: +Python 2.5, Python 2.6
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2635>
> __________________________________

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2635>
__________________________________

From report at bugs.python.org  Mon Apr 21 02:15:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Apr 2008 00:15:03 +0000
Subject: [issue2651] Strings passed to KeyError do not round trip
In-Reply-To: <1208453081.65.0.886847251895.issue2651@psf.upfronthosting.co.za>
Message-ID: <1208736903.01.0.0882638679972.issue2651@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Attached patch changes KeyError: when it has two arguments, they are
formatted with "%s: %r". Otherwise the base repr is called, and this
allows the round trip.

Standard objects (dict, set, UserDict, namedtuple, defaultdict, weak
dictionaries) now raise something like KeyError("not in dict", key). 

At least one place in the stdlib relied on the key being the first
argument to KeyError() (in ConfigParser.py)

I don't know if this incompatibility will break much code. At least we
can say that the current behavior is not documented.

----------
keywords: +patch
Added file: http://bugs.python.org/file10069/KeyError.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2651>
__________________________________

From report at bugs.python.org  Mon Apr 21 02:42:42 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 21 Apr 2008 00:42:42 +0000
Subject: [issue2664] The position of special value tables (cmathmodule.c)
In-Reply-To: <1208738562.06.0.91336742493.issue2664@psf.upfronthosting.co.za>
Message-ID: <1208738562.06.0.91336742493.issue2664@psf.upfronthosting.co.za>


New submission from Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:

If putting special value tables near function is preferable,
(as before) probably this patch helps.

----------
components: Extension Modules
files: cmathmodule.patch
keywords: patch
messages: 65657
nosy: ocean-city
severity: normal
status: open
title: The position of special value tables (cmathmodule.c)
versions: Python 2.6
Added file: http://bugs.python.org/file10070/cmathmodule.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2664>
__________________________________

From report at bugs.python.org  Mon Apr 21 02:48:07 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Mon, 21 Apr 2008 00:48:07 +0000
Subject: [issue2664] The position of special value tables (cmathmodule.c)
In-Reply-To: <1208738562.06.0.91336742493.issue2664@psf.upfronthosting.co.za>
Message-ID: <1208738887.02.0.357597635658.issue2664@psf.upfronthosting.co.za>


Changes by Hirokazu Yamamoto <ocean-city at users.sourceforge.net>:


----------
assignee:  -> marketdickinson
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2664>
__________________________________

From report at bugs.python.org  Mon Apr 21 10:38:14 2008
From: report at bugs.python.org (Leo)
Date: Mon, 21 Apr 2008 08:38:14 +0000
Subject: [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>


New submission from Leo <elescargot at hotmail.com>:

I recently upgraded from python 2.3 to 2.5. But idle doesn't launch
anymore, either with right-clicking a .py program an doing "edit with
IDLE" or with launching the idle.py file itself. 
When I launch idle with the command line, it gives the following error
several times:

Warning : configHandler.py - IdleConf.GetThemeDict- 
problem retrieving theme element 'buitlin-foreground'
from theme 'vert theme'
returning default value: '#000000'

Warning : configHandler.py - IdleConf.GetThemeDict- 
problem retrieving theme element 'buitlin-background'
from theme 'vert theme'
returning default value: '#ffffff'

----------
components: IDLE
messages: 65658
nosy: Leo
severity: normal
status: open
title: unable to launch IDLE on windows XP
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2665>
__________________________________

From report at bugs.python.org  Mon Apr 21 11:18:19 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Apr 2008 09:18:19 +0000
Subject: [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208769499.02.0.304197744438.issue2665@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"buitlin"? Is is a typo while copying the error message?

The warnings are normal, these theme elements were added later. They
will disappear when you save the theme again.

Now, idle starts another process to interpret the commands, and use
sockets to communicate between them. You may have a firewall problem.

Can you try to run idle.py with the "-n" option? This does not create a
subprocess, all commands are run in the main process.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2665>
__________________________________

From report at bugs.python.org  Mon Apr 21 11:28:05 2008
From: report at bugs.python.org (Leo)
Date: Mon, 21 Apr 2008 09:28:05 +0000
Subject: [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208770085.66.0.254112137736.issue2665@psf.upfronthosting.co.za>


Leo <elescargot at hotmail.com> added the comment:

it's not "buitlin" but "builtin" of course.

idle launches when I use the command line, with or without "-n", but I'm
still unable to lauch it normally (by the right click or by the windows
menu ("D?marrer/Programmes/Python25/idle")).
Before, I used python 2.3 and it worked well. I uninstalled and
installed again python 2.5 several times but I still got the same
problem.. it isn't practical at all to lauch idle by the command line!
So I hope you'll have an idea to solve my problem...

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2665>
__________________________________

From report at bugs.python.org  Mon Apr 21 11:57:33 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Apr 2008 09:57:33 +0000
Subject: [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208771853.8.0.46466471043.issue2665@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I reproduced the problem.
- "python.exe idle.py"  works (with many warnings)
- "pythonw.exe idle.py" fails

pythonw.exe is a Windows (i.e. not a console) application, so sys.stderr
points to an invalid file descriptor; printing lot of warnings raises an
exception when the file tries to flush()...

As an immediate workaround, you may delete everything in the directory named
  c:/Documents and Settings/%USERNAME%/.idlerc
or if you feel it, add the missing entries in the file config-highlight.cfg.

I'll try to correct this problem for python2.5: replace 
   sys.stderr.write(warning) 
with
   try:
      sys.stderr.write(warning) 
   except IOError:
      pass

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2665>
__________________________________

From report at bugs.python.org  Mon Apr 21 12:31:22 2008
From: report at bugs.python.org (Leo)
Date: Mon, 21 Apr 2008 10:31:22 +0000
Subject: [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208773882.09.0.248043666158.issue2665@psf.upfronthosting.co.za>


Leo <elescargot at hotmail.com> added the comment:

ok, deleting the contents of .idlerc seems to work fine.
Thank you!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2665>
__________________________________

From report at bugs.python.org  Mon Apr 21 12:51:10 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 21 Apr 2008 10:51:10 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1208775070.42.0.620971233154.issue2663@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
nosy: +draghuram

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 21 13:16:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Apr 2008 11:16:15 +0000
Subject: [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208776575.99.0.473485655739.issue2665@psf.upfronthosting.co.za>


Changes by Amaury Forgeot d'Arc <amauryfa at gmail.com>:


----------
assignee:  -> amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2665>
__________________________________

From report at bugs.python.org  Mon Apr 21 15:42:00 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 21 Apr 2008 13:42:00 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1208785320.48.0.690880398869.issue2663@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On the interface, I would suggest renaming 'exclude' to 'ignore' for 
consistency with filecmp.dircmp. Also consider detecting file separator 
in the patterns and interpreting them as an absolute (if 
pattern.startswith(pathsep)) or relative with respect to src. 

On the implementation, consider making 'exclude_files' a set for a 
faster lookup.   It should also be possible to refactor the code to 
avoid checking the type of 'exclude' on every file and every recursion.

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 21 18:13:35 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Mon, 21 Apr 2008 16:13:35 +0000
Subject: [issue2459] speedup loops with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1208794415.28.0.606835266574.issue2459@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at argo.es>:


----------
nosy: +jcea

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
__________________________________

From report at bugs.python.org  Mon Apr 21 20:00:58 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Mon, 21 Apr 2008 18:00:58 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208800858.69.0.524324653467.issue2632@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

Twisted fixed their problem for issue 1092502 by making recv()ed data
short lived by putting it into a StringIO for buffering.

I've attached a patch that does that for the socket module -and- gets
rid of any possibility of doing tiny size recvs in read() which is the
cause of the poor performance that this issue was filed about.

My patch also documents what _rbufsize is used for (readline) and makes
sane use of it with read.

When viewing the change, it is best to view it side by side next to the
old version rather than trying to comprehend it as a diff.

I believe this really fixes both issue 1092502 while at the same time
prevents introduction of a speed problem (this issue).

----------
assignee:  -> gregory.p.smith
nosy: +gregory.p.smith
Added file: http://bugs.python.org/file10071/socket-strio-gps01.patch.txt

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Mon Apr 21 22:16:10 2008
From: report at bugs.python.org (Oleg Broytmann)
Date: Mon, 21 Apr 2008 20:16:10 +0000
Subject: [issue2666] webbrowser.py doesn't properly handle BROWSER env var
In-Reply-To: <1208808970.74.0.37867615759.issue2666@psf.upfronthosting.co.za>
Message-ID: <1208808970.74.0.37867615759.issue2666@psf.upfronthosting.co.za>


New submission from Oleg Broytmann <phd at phd.pp.ru>:

webbrowser.py ignores browsers listed in the BROWSER environment
variables if it doesn't recognize the browser. For example, if I add
"links2" to the BROWSER env var, webbrowser.py ignores it.

It is because _synthesize() doesn't know how to handle an unknown
browser. The attached patch checks if _synthesize() doesn't register a
browser and registers a GenericBrowser.

Another approach would be to register GenericBrowser in _synthesize().

----------
components: Library (Lib)
files: webbrowser.py.patch
keywords: patch
messages: 65665
nosy: phd
severity: normal
status: open
title: webbrowser.py doesn't properly handle BROWSER env var
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10072/webbrowser.py.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2666>
__________________________________

From report at bugs.python.org  Tue Apr 22 00:43:29 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 21 Apr 2008 22:43:29 +0000
Subject: [issue2665] unable to launch IDLE on windows XP
In-Reply-To: <1208767094.2.0.809332799665.issue2665@psf.upfronthosting.co.za>
Message-ID: <1208817809.44.0.166561807327.issue2665@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Committed r62448 & r62449.
Thanks for the report!

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2665>
__________________________________

From report at bugs.python.org  Tue Apr 22 00:32:56 2008
From: report at bugs.python.org (Forest Wilkinson)
Date: Mon, 21 Apr 2008 22:32:56 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208817176.06.0.338104201271.issue2632@psf.upfronthosting.co.za>


Changes by Forest Wilkinson <forest at users.sourceforge.net>:


----------
nosy: +forest

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 22 02:58:26 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 22 Apr 2008 00:58:26 +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: <1208825905.94.0.286532122526.issue2135@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Closed at Doug's request. My importlib work, once it lands, will supplant 
all of this.

----------
resolution:  -> rejected
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2135>
__________________________________

From report at bugs.python.org  Tue Apr 22 04:09:54 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Apr 2008 02:09:54 +0000
Subject: [issue2664] The position of special value tables (cmathmodule.c)
In-Reply-To: <1208738562.06.0.91336742493.issue2664@psf.upfronthosting.co.za>
Message-ID: <1208830194.64.0.641979047331.issue2664@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2664>
__________________________________

From report at bugs.python.org  Tue Apr 22 04:13:10 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 22 Apr 2008 02:13:10 +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: <1208830390.63.0.13487671501.issue1879@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

This is now fixed in the trunk, as a result of the trunk-math merge.
Closing as 'out of date'.

----------
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1879>
__________________________________

From report at bugs.python.org  Tue Apr 22 08:02:38 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Tue, 22 Apr 2008 06:02:38 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1208844158.06.0.418053179741.issue2632@psf.upfronthosting.co.za>


Ralf Schmitt <schmir at gmail.com> added the comment:

(I think the twisted issue your talking about is:
http://twistedmatrix.com/trac/ticket/1079)

Your patch still contains this code:

                 recv_size = min(rbufsize, left)
                 data = self._sock.recv(recv_size)

This is IMHO wrong.  See my comments above.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Tue Apr 22 09:40:12 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Tue, 22 Apr 2008 07:40:12 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1208850011.93.0.970099018341.issue2663@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I changed the patch based on all remarks. For the absolute path, I was
wondering if it would be useful since calls are recursive, relative to
the visited directory.

Added file: http://bugs.python.org/file10073/shutil.copytree.filtering.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Tue Apr 22 11:52:17 2008
From: report at bugs.python.org (gmarketer)
Date: Tue, 22 Apr 2008 09:52:17 +0000
Subject: [issue2667] Remove multiple inheritance in Python 3000
In-Reply-To: <1208857936.63.0.151733564558.issue2667@psf.upfronthosting.co.za>
Message-ID: <1208857936.63.0.151733564558.issue2667@psf.upfronthosting.co.za>


New submission from gmarketer <gmarketer at gmail.com>:

Please remove ability to multiple inheritance in Python 3000.

Multiple inheritance is bad for design, rarely used and contains many 
problems for usual users.

Every program can be designed only with single inheritance.

----------
components: None
messages: 65671
nosy: gmarketer
severity: normal
status: open
title: Remove multiple inheritance in Python 3000
type: feature request
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2667>
__________________________________

From report at bugs.python.org  Tue Apr 22 12:54:54 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 22 Apr 2008 10:54:54 +0000
Subject: [issue2667] Remove multiple inheritance in Python 3000
In-Reply-To: <1208857936.63.0.151733564558.issue2667@psf.upfronthosting.co.za>
Message-ID: <1208861694.87.0.580739780222.issue2667@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

I don't think this request is appropriate for bug tracker. If you are
really keen, bring it up on perhaps python-ideas mailing list.

----------
nosy: +draghuram
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2667>
__________________________________

From report at bugs.python.org  Tue Apr 22 13:25:16 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 22 Apr 2008 11:25:16 +0000
Subject: [issue2667] Remove multiple inheritance in Python 3000
In-Reply-To: <1208857936.63.0.151733564558.issue2667@psf.upfronthosting.co.za>
Message-ID: <1208863515.92.0.712576442037.issue2667@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

You are too late for Python 3000. You next change will be in about 10
years for Python 4000.

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2667>
__________________________________

From report at bugs.python.org  Tue Apr 22 14:04:25 2008
From: report at bugs.python.org (gmarketer)
Date: Tue, 22 Apr 2008 12:04:25 +0000
Subject: [issue2667] Remove multiple inheritance in Python 3000
In-Reply-To: <1208857936.63.0.151733564558.issue2667@psf.upfronthosting.co.za>
Message-ID: <1208865865.43.0.574506208045.issue2667@psf.upfronthosting.co.za>


gmarketer <gmarketer at gmail.com> added the comment:

I'm also think so.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2667>
__________________________________

From report at bugs.python.org  Tue Apr 22 18:49:05 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 22 Apr 2008 16:49:05 +0000
Subject: [issue2668] apply() documentation is slightly incorrect
In-Reply-To: <1208882945.04.0.253062304574.issue2668@psf.upfronthosting.co.za>
Message-ID: <1208882945.04.0.253062304574.issue2668@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Current Doc/library/functions.rst says "The use of apply() is exactly
equivalent to function(*args, **keywords)." which is no longer correct
because f(*args, **keywords) notation allows use of an arbitrary mapping
as keywords in 2.6, but apply(f, args, keywords) does not.

I don't think changing the code to allow arbitrary mapping in apply is
worth the trouble and even mentioning this difference explicitly in the
apply() docs is probably not justified.

My recommendation is to just s/exactly equivalent/equivalent/ in the
sentence quote above.

----------
assignee: georg.brandl
components: Documentation
messages: 65675
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: apply() documentation is slightly incorrect
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2668>
__________________________________

From report at bugs.python.org  Tue Apr 22 19:52:07 2008
From: report at bugs.python.org (Miki Tebeka)
Date: Tue, 22 Apr 2008 17:52:07 +0000
Subject: [issue2669] bsddb iterkeys sliently fails when database modified
	during iteration
In-Reply-To: <1208886727.18.0.175464776053.issue2669@psf.upfronthosting.co.za>
Message-ID: <1208886727.18.0.175464776053.issue2669@psf.upfronthosting.co.za>


New submission from Miki Tebeka <miki.tebeka at gmail.com>:

>>> db = bsddb.btopen("/tmp/n")
>>> for i in range(5):
	db[str(i)] = None
>>> db
{'1': '', '0': '', '3': '', '2': '', '4': ''}
>>> for k in db.iterkeys():
	print k
	del db[k]
0
>>> 

The Python "dict" object raises a RuntimeError when modifying the
dictionary during iteration, the database should do the same.

----------
components: Library (Lib)
messages: 65676
nosy: tebeka
severity: normal
status: open
title: bsddb iterkeys sliently fails when database modified during iteration
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2669>
__________________________________

From report at bugs.python.org  Tue Apr 22 20:25:30 2008
From: report at bugs.python.org (John Krukoff)
Date: Tue, 22 Apr 2008 18:25:30 +0000
Subject: [issue643841] New class special method lookup change
Message-ID: <1208888730.57.0.830098156043.issue643841@psf.upfronthosting.co.za>


John Krukoff <helot at comcast.net> added the comment:

I've been following the py3k maliing list disscussion for this issue, 
and wanted to add a note about the proposed solution described here:
http://mail.python.org/pipermail/python-3000/2008-April/013004.html

The reason I think this approach is valuable is that in all of the 
proxy classes I've written, I'm concerned about which behaviour of the 
proxied class I want to override, not which behaviour I want to keep. 
In other words, when I proxy something, my mental model has always 
been, okay, I want something that behaves just like X, except it does 
this (usually small bit) differently.

This is also why I expect my proxies to keep working the same when I 
change the proxied class, without having to go and update the proxy to 
also use the new behaviour.

So, yeah, very much in favor of a base proxy class in the standard 
library.

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue643841>
____________________________________

From report at bugs.python.org  Tue Apr 22 21:03:25 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 22 Apr 2008 19:03:25 +0000
Subject: [issue2440] Issues with getargs_n() and PyNumber_Index.
In-Reply-To: <1206050442.67.0.496216797611.issue2440@psf.upfronthosting.co.za>
Message-ID: <1208891004.93.0.858082922461.issue2440@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Update: the changes committed on r62269 and r62279 were incorrect and 
reverted in r62292.

Log:
Issue 2440: revert r62269 and r62279.  These changes were made in an 
effort to fix test_args2.Signed_TestCase.test_n(), which was failing on 
Windows x64 on the following line:  'self.failUnlessEqual(99, getargs_n
(Long()))'.  Although the two commits *did* fix the test on Windows 
x64, it's become clear that it's the test that's incorrect, and the 
changes to PyNumber_Index() in particular were not warranted (and 
actually violate PEP 357).  This commit will get us back to where we 
were at r62268, before I started butchering things.

The reworked patch fixes test_getargs2.py, such that it verifies Long() 
and Int() can't be used as indexes.  It also fixes the handling of 'n' 
in getargs.c's convertsimple().  Committed in r62462.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2440>
__________________________________

From report at bugs.python.org  Tue Apr 22 21:09:54 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 22 Apr 2008 19:09:54 +0000
Subject: [issue719888] tokenize module w/ coding cookie
Message-ID: <1208891394.87.0.410787652092.issue719888@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

This was fixed in trunk in r61573, and merged to py3k in r61982.

----------
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue719888>
____________________________________

From report at bugs.python.org  Tue Apr 22 21:15:29 2008
From: report at bugs.python.org (Trent Nelson)
Date: Tue, 22 Apr 2008 19:15:29 +0000
Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock)
In-Reply-To: <1195766591.59.0.212085206705.issue1489@psf.upfronthosting.co.za>
Message-ID: <1208891729.13.0.796895546328.issue1489@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Hey, if we can get rid of it, that's great.  You sound 95% certain in 
your last post that completely removing test_socket_ssl on trunk and 
py3k is the Right Thing -- any chance of getting you to 100% so I can 
go ahead and delete it and close this ticket?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1489>
__________________________________

From report at bugs.python.org  Tue Apr 22 21:34:48 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 22 Apr 2008 19:34:48 +0000
Subject: [issue1489] test_socket_ssl hangs on Windows (deadlock)
In-Reply-To: <1195766591.59.0.212085206705.issue1489@psf.upfronthosting.co.za>
Message-ID: <1208892888.58.0.0203882234257.issue1489@psf.upfronthosting.co.za>


Changes by Raghuram Devarakonda <draghuram at gmail.com>:


----------
title: test_socket_ssl hanhs on Windows (deadlock) -> test_socket_ssl hangs on Windows (deadlock)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1489>
__________________________________

From report at bugs.python.org  Tue Apr 22 21:43:38 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 22 Apr 2008 19:43: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: <1208893418.75.0.155221912523.issue2047@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

Can some one with commit privileges check in shutil_destinsrc.patch? The
change is rather simple and there is no point for issues such as these
to remain open for long time.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2047>
__________________________________

From report at bugs.python.org  Tue Apr 22 21:56:35 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Tue, 22 Apr 2008 19:56:35 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1208894195.38.0.0639589801886.issue2663@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

Is there any reason for rmtree also to not support this exclusion
feature? Both copytree and rmtree explicitly iterate over list of names
and as I see it, this exclusion is really about which names to ignore.
Already, copytree and rmtree have inconsistencies (rmtree has 'onerror'
while 'copytree' doesn't) and it would be nice to not add more.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Tue Apr 22 22:17:56 2008
From: report at bugs.python.org (Tom Lynn)
Date: Tue, 22 Apr 2008 20:17:56 +0000
Subject: [issue2670] urllib2 build_opener() fails if two handlers use the same
	default base class
In-Reply-To: <1208895476.65.0.692366839984.issue2670@psf.upfronthosting.co.za>
Message-ID: <1208895476.65.0.692366839984.issue2670@psf.upfronthosting.co.za>


New submission from Tom Lynn <tlynn at users.sourceforge.net>:

urllib2.py:424 (Py 2.4) or urllib2.py:443 (Py 2.5) in build_opener()::

        skip = []
        for klass in default_classes:
            for check in handlers:
                if inspect.isclass(check):
                    if issubclass(check, klass):
                        skip.append(klass)
                elif isinstance(check, klass):
                    skip.append(klass)
        for klass in skip:
           default_classes.remove(klass)

This can cause klass to be appended to skip multiple times,
which then causes an exception in the final line quoted above.

skip should be a set (and append changed to add), or "if klass
not in skip:" should be added before each "skip.append(klass)".

----------
components: Library (Lib)
messages: 65683
nosy: tlynn
severity: normal
status: open
title: urllib2 build_opener() fails if two handlers use the same default base class
type: behavior
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2670>
__________________________________

From report at bugs.python.org  Tue Apr 22 23:18:48 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Apr 2008 21:18:48 +0000
Subject: [issue2670] urllib2 build_opener() fails if two handlers use the same
	default base class
In-Reply-To: <1208895476.65.0.692366839984.issue2670@psf.upfronthosting.co.za>
Message-ID: <1208899128.59.0.0701990012462.issue2670@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Corrected as r62463 (trunk) and r62464 (2.5 branch).

Thanks for the report!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2670>
__________________________________

From report at bugs.python.org  Tue Apr 22 23:47:59 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 22 Apr 2008 21:47:59 +0000
Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock)
In-Reply-To: <1208891729.13.0.796895546328.issue1489@psf.upfronthosting.co.za>
Message-ID: <4b3e516a0804221447r7dae99d1i6505a209ef3ff348@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

On Tue, Apr 22, 2008 at 12:15 PM, Trent Nelson <report at bugs.python.org>
wrote:

>
> Trent Nelson <tnelson at onresolve.com> added the comment:
>
> Hey, if we can get rid of it, that's great.  You sound 95% certain in
> your last post that completely removing test_socket_ssl on trunk and
> py3k is the Right Thing -- any chance of getting you to 100% so I can
> go ahead and delete it and close this ticket?
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue1489>
> __________________________________
>

----------
title: test_socket_ssl hangs on Windows (deadlock) -> test_socket_ssl hanhs on Windows (deadlock)
Added file: http://bugs.python.org/file10074/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1489>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080422/394c4bb4/attachment.txt>

From report at bugs.python.org  Tue Apr 22 23:48:42 2008
From: report at bugs.python.org (Bill Janssen)
Date: Tue, 22 Apr 2008 21:48:42 +0000
Subject: [issue1489] test_socket_ssl hanhs on Windows (deadlock)
In-Reply-To: <4b3e516a0804221447r7dae99d1i6505a209ef3ff348@mail.gmail.com>
Message-ID: <4b3e516a0804221448x1c245b8cp5a703806b6f5c185@mail.gmail.com>


Bill Janssen <bill.janssen at gmail.com> added the comment:

Sorry, didn't mean to be indeterminate.  Sure, nuke it.  The tests are now
all in test_ssl.py.

Bill

On Tue, Apr 22, 2008 at 2:47 PM, Bill Janssen <bill.janssen at gmail.com>
wrote:

>
>
> On Tue, Apr 22, 2008 at 12:15 PM, Trent Nelson <report at bugs.python.org>
> wrote:
>
> >
> > Trent Nelson <tnelson at onresolve.com> added the comment:
> >
> > Hey, if we can get rid of it, that's great.  You sound 95% certain in
> > your last post that completely removing test_socket_ssl on trunk and
> > py3k is the Right Thing -- any chance of getting you to 100% so I can
> > go ahead and delete it and close this ticket?
> >
> > __________________________________
> > Tracker <report at bugs.python.org>
> > <http://bugs.python.org/issue1489>
> > __________________________________
> >
>
>

Added file: http://bugs.python.org/file10075/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1489>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080422/2cf40d7f/attachment.txt>

From report at bugs.python.org  Wed Apr 23 00:07:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 22 Apr 2008 22:07:19 +0000
Subject: [issue2671] PyErr_WarnPy3k
In-Reply-To: <1208902039.11.0.586606723559.issue2671@psf.upfronthosting.co.za>
Message-ID: <1208902039.11.0.586606723559.issue2671@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

Attaching a patch that adds a PyErr_WarnPy3k function.

----------
components: Interpreter Core
files: py3kwarn_c.patch
keywords: patch
messages: 65687
nosy: benjamin.peterson, tiran
severity: normal
status: open
title: PyErr_WarnPy3k
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10076/py3kwarn_c.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2671>
__________________________________

From report at bugs.python.org  Wed Apr 23 00:26:46 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 22 Apr 2008 22:26:46 +0000
Subject: [issue2623] Patch: xmlrpclib client ignores datetime tzinfo when
	creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1208903205.89.0.962757226549.issue2623@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Leonard,

Can you reformulate your patch in terms of the current xmlrpclib module
code?  It no longer applies cleanly.  Also, to be considered it will
definitely need new test cases and may well need documentation changes.

Also, note that the XML-RPC "spec" is notoriously vague.  If you're
going to be messing about with the serialized form of datetime objects I
think you'll need to demonstrate that it doesn't break interoperability
with implementations for other languages.

----------
assignee:  -> skip.montanaro
nosy: +skip.montanaro

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2623>
__________________________________

From report at bugs.python.org  Wed Apr 23 00:32:29 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 22 Apr 2008 22:32:29 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1208903549.24.0.213835160981.issue1767370@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Donovan, can you recreate this patch using the current Subversion trunk?
 The patch program complains:

    **** malformed patch at line 125: Index:
trunk.2/Lib/SimpleXMLRPCServer.py

Thanks,

Skip

----------
nosy: +skip.montanaro

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_____________________________________

From report at bugs.python.org  Wed Apr 23 00:36:34 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 22 Apr 2008 22:36:34 +0000
Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/
	xmlrpmclib
In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za>
Message-ID: <1208903794.6.0.546831697691.issue1327@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Can this ticket be closed?  I've still yet to see anything here that
anyone could actually do anything with.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1327>
__________________________________

From report at bugs.python.org  Wed Apr 23 00:37:12 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Tue, 22 Apr 2008 22:37:12 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1208903832.43.0.274556779783.issue1767370@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Also, please post the patch in uncompressed form.

----------
nosy: +rhettinger

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_____________________________________

From report at bugs.python.org  Wed Apr 23 00:42:41 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Tue, 22 Apr 2008 22:42:41 +0000
Subject: [issue1327] Python 2.4+ spends too much time in PyEval_EvalFrame w/
	xmlrpmclib
In-Reply-To: <1193348023.13.0.92829206249.issue1327@psf.upfronthosting.co.za>
Message-ID: <1208904161.52.0.502702058878.issue1327@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

"Requested info not available", closing this ticket.

----------
resolution:  -> works for me
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1327>
__________________________________

From report at bugs.python.org  Wed Apr 23 00:46:18 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 22 Apr 2008 22:46:18 +0000
Subject: [issue1753732] xmlrpclib.Binary doesn't say which base64 spec it
	implements
Message-ID: <1208904378.32.0.618757779718.issue1753732@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

I updated xmlrpclib.rst with your documentation changes (r62465).
Is it okay to close this ticket?

Skip

----------
assignee:  -> skip.montanaro
nosy: +skip.montanaro

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1753732>
_____________________________________

From report at bugs.python.org  Wed Apr 23 00:47:40 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 22 Apr 2008 22:47:40 +0000
Subject: [issue2623] Patch: xmlrpclib client ignores datetime tzinfo when
	creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1208904460.39.0.209212044411.issue2623@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


----------
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2623>
__________________________________

From report at bugs.python.org  Wed Apr 23 04:44:44 2008
From: report at bugs.python.org (John Arbash Meinel)
Date: Wed, 23 Apr 2008 02:44:44 +0000
Subject: [issue2672] speed of set.update([])
In-Reply-To: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>
Message-ID: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>


New submission from John Arbash Meinel <john at arbash-meinel.com>:

I was performance profiling some of my own code, and I ran into
something unexpected. Specifically,
set.update(empty_generator_expression) was significantly slower than
set.update(empty_list_expression).

I double checked my findings with timeit:

With python 2.4.3:

$ python -m timeit -s 'x = set(range(10000))' 'x.update([])'
1000000 loops, best of 3: 0.296 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update(y for y in [])'
1000000 loops, best of 3: 0.837 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update([y for y in []])'
1000000 loops, best of 3: 0.462 usec per loop

With 2.5.1 (on a different machine)
$ python -m timeit -s 'x = set(range(10000))' 'x.update([])'
1000000 loops, best of 3: 0.265 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update(y for y in [])'
1000000 loops, best of 3: 0.717 usec per loop
$ python -m timeit -s 'x = set(range(10000))' 'x.update([y for y in []])'
1000000 loops, best of 3: 0.39 usec per loop

So generally, it is about 2x faster to create the empty list expression
and pass it in than to use an empty generator.

----------
components: Interpreter Core
messages: 65694
nosy: jameinel
severity: normal
status: open
title: speed of set.update([])
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Wed Apr 23 04:44:55 2008
From: report at bugs.python.org (John Arbash Meinel)
Date: Wed, 23 Apr 2008 02:44:55 +0000
Subject: [issue2672] speed of set.update([])
In-Reply-To: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>
Message-ID: <1208918695.37.0.64025856092.issue2672@psf.upfronthosting.co.za>


Changes by John Arbash Meinel <john at arbash-meinel.com>:


----------
type:  -> performance

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Wed Apr 23 05:25:47 2008
From: report at bugs.python.org (Hirokazu Yamamoto)
Date: Wed, 23 Apr 2008 03:25:47 +0000
Subject: [issue2222] Memory leak in os.rename?
In-Reply-To: <1204549533.94.0.102574866059.issue2222@psf.upfronthosting.co.za>
Message-ID: <1208921147.09.0.0248312266191.issue2222@psf.upfronthosting.co.za>


Hirokazu Yamamoto <ocean-city at users.sourceforge.net> added the comment:

I reimplemented patch without O&, and made test for all platforms.
Unfortunately Windows doesn't have os.link and os.symlink, so for
os.rename only.

Added file: http://bugs.python.org/file10077/test_and_fix.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2222>
__________________________________

From report at bugs.python.org  Wed Apr 23 05:59:35 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Apr 2008 03:59:35 +0000
Subject: [issue2672] speed of set.update([])
In-Reply-To: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>
Message-ID: <1208923175.46.0.433829167404.issue2672@psf.upfronthosting.co.za>


Changes by Raymond Hettinger <rhettinger at users.sourceforge.net>:


----------
assignee:  -> rhettinger
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Wed Apr 23 07:08:34 2008
From: report at bugs.python.org (Beverley Eyre)
Date: Wed, 23 Apr 2008 05:08:34 +0000
Subject: [issue2673] error on optparse page
In-Reply-To: <1208927314.01.0.909798143433.issue2673@psf.upfronthosting.co.za>
Message-ID: <1208927314.01.0.909798143433.issue2673@psf.upfronthosting.co.za>


New submission from Beverley Eyre <fbe2 at comcast.net>:

There is an error (maybe a typo) on this page:
http://docs.python.org/lib/optparse-callback-example-6.html.

The last line of the example should have ->
callback=vararg_callback not callback=varargs

Not a big deal.

----------
assignee: georg.brandl
components: Documentation
messages: 65696
nosy: fbe2, georg.brandl
severity: normal
status: open
title: error on optparse page

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2673>
__________________________________

From report at bugs.python.org  Wed Apr 23 09:48:11 2008
From: report at bugs.python.org (Leonard Clark)
Date: Wed, 23 Apr 2008 07:48:11 +0000
Subject: [issue2623] Patch: xmlrpclib client ignores datetime tzinfo when
	creating iso8601 dates
In-Reply-To: <1207980709.57.0.906116162724.issue2623@psf.upfronthosting.co.za>
Message-ID: <1208936891.34.0.127325061957.issue2623@psf.upfronthosting.co.za>


Leonard Clark <lclark at 2bdx.net> added the comment:

While the XML-RPC spec is vague with regards to respecting time zone
information, the iso8601 document is not vague as to how to properly
serialize it.

Some XML-RPC libraries (like ours) completely ignore time zone
information.  I will make every effort to test this against as many
libraries as I can.

While I'm at it, I'll see about adding support for time zone information
in server results.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2623>
__________________________________

From report at bugs.python.org  Wed Apr 23 15:59:47 2008
From: report at bugs.python.org (Johan Tufvesson)
Date: Wed, 23 Apr 2008 13:59:47 +0000
Subject: [issue2674] unittest.TestProgram uses sys.exit()
In-Reply-To: <1208959187.62.0.82904421242.issue2674@psf.upfronthosting.co.za>
Message-ID: <1208959187.62.0.82904421242.issue2674@psf.upfronthosting.co.za>


New submission from Johan Tufvesson <tuben at users.sourceforge.net>:

The class TestProgram (and its synonym "main") in module unittest is
(probably) meant to be an easy way to use the functionality of the
module unittest. It is very surprising (and error-prone) that it uses
sys.exit() with a status code instead of making a return with the same
status code.

Clean-up actions after the call to unittest.main() are not executed.

----------
components: Library (Lib)
messages: 65698
nosy: tuben
severity: normal
status: open
title: unittest.TestProgram uses sys.exit()
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2674>
__________________________________

From report at bugs.python.org  Wed Apr 23 16:13:24 2008
From: report at bugs.python.org (Paul Winkler)
Date: Wed, 23 Apr 2008 14:13:24 +0000
Subject: [issue1753732] xmlrpclib.Binary doesn't say which base64 spec it
	implements
Message-ID: <1208960004.63.0.101196708427.issue1753732@psf.upfronthosting.co.za>


Paul Winkler <pw_lists at slinkp.com> added the comment:

looks good to me, thanks!

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1753732>
_____________________________________

From report at bugs.python.org  Wed Apr 23 16:36:08 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Apr 2008 14:36:08 +0000
Subject: [issue1753732] xmlrpclib.Binary doesn't say which base64 spec it
	implements
Message-ID: <1208961368.65.0.773488916657.issue1753732@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1753732>
_____________________________________

From report at bugs.python.org  Wed Apr 23 17:41:40 2008
From: report at bugs.python.org (Pavel Bazant)
Date: Wed, 23 Apr 2008 15:41:40 +0000
Subject: [issue2675] Curses terminal resize problems when Python is in
	interactive mode
In-Reply-To: <1208965300.42.0.575050740888.issue2675@psf.upfronthosting.co.za>
Message-ID: <1208965300.42.0.575050740888.issue2675@psf.upfronthosting.co.za>


New submission from Pavel Bazant <maxplanck at seznam.cz>:

When python is in interactive mode, curses does not react to resize 
events properly.

test.py:

import curses

def run():
 stdscr=curses.initscr()
 key=0
 while(key!=ord('q')):
  key=stdscr.getch()
  stdscr.addstr(0,0,str(stdscr.getmaxyx())+' '+str(key))
  stdscr.refresh()
 curses.endwin()

run()

When this is run directly, everything is ok. When it is called via 
execfile() from the interactive prompt, it shows the right screen size 
after the first keypress, but behaves oddly after the resize.

IMHO, the following happens:
For some reason, env. variables LINES and COLUMNS are set but they are 
not reflected in the os.environ structure nor they respond to screen 
size changes. If these variables are set then the ncurses library (see 
man pages) uses their values instead of getting the term size via 
ioctl. 
The ncurses library receives a SIGWINCH and sees that LINES
and COLUMNS are set. However, their values are same as the
screen dimensions before the resize, so it is perplexed why there is
a SIGWINCH if the screen did not change and it just ungetchs an ERR
and ncurses internal structures are not changed appropriately.

>From the resizeterm man page:
"If the environment variables LINES or COLUMNS are set, this overrides 
the library's use of the window size obtained from the operating 
system. Thus, even if a SIGWINCH is received, no screen size change may 
be recorded. In that case, no KEY_RESIZE is queued for the next call to 
getch; an ERR will be returned instead."

Executing

import os
os.environ['LINES']="blah"
del os.environ['LINES']
os.environ['COLUMNS']="blah"
del os.environ['COLUMNS']

solves the problem for me.
Perhaps the problem has sth to do with python using readline
in interactive mode???
PB

----------
components: None
messages: 65700
nosy: pbazant
severity: normal
status: open
title: Curses terminal resize problems when Python is in interactive mode
type: behavior
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2675>
__________________________________

From report at bugs.python.org  Wed Apr 23 18:33:51 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 23 Apr 2008 16:33:51 +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: <1208968431.93.0.564171930396.issue1222@psf.upfronthosting.co.za>


Changes by Eric Smith <eric at trueblade.com>:


----------
nosy: +eric.smith

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
__________________________________

From report at bugs.python.org  Wed Apr 23 18:43:52 2008
From: report at bugs.python.org (Michael Amrhein)
Date: Wed, 23 Apr 2008 16:43:52 +0000
Subject: [issue1738] filecmp.dircmp does exact match only
In-Reply-To: <1199482445.72.0.241275927673.issue1738@psf.upfronthosting.co.za>
Message-ID: <1208969032.58.0.870810109404.issue1738@psf.upfronthosting.co.za>


Michael Amrhein <mamrhein at users.sourceforge.net> added the comment:

Here's a 2nd revised patch, which
* adds a keyword 'match' to the constructor of class 'dircmp'
* defaults 'match' to str.__eq__
* modifies method 'phase0': apply os.name.normcase to each name in
ignore and hide
* modifies the docs accordingly, incl. an example for using pattern matching
* modifies the test case for the default matching
* adds a test case for using pattern matching (fnmatch.fnmatch)

Added file: http://bugs.python.org/file10078/add_match_func.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1738>
__________________________________

From report at bugs.python.org  Wed Apr 23 19:00:17 2008
From: report at bugs.python.org (Daniel Diniz)
Date: Wed, 23 Apr 2008 17:00:17 +0000
Subject: [issue2676] email/message.py [Message.get_content_type]: Trivial
	regex hangs on pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>


New submission from Daniel Diniz <ajaksu at gmail.com>:

[Reported by Alberto Casado Mart?n [1]]

Message.get_content_type() hangs when very large values are split by the
regex:
ctype = paramre.split(value)[0].lower().strip() #line 439

paramre comes from line 26:
paramre = re.compile(r'\s*;\s*')

Unless the full fledged parser cited in the comment before line 26 is in
the works, I suggest splitting the string by ";" to get exactly the same
behavior in a more reliable way.


[1] http://mail.python.org/pipermail/python-dev/2008-April/078840.html

----------
components: Library (Lib)
files: message.py.patch
keywords: patch
messages: 65702
nosy: ajaksu2, barry
severity: normal
status: open
title: email/message.py [Message.get_content_type]: Trivial regex hangs on pathological input
versions: Python 2.6
Added file: http://bugs.python.org/file10079/message.py.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2676>
__________________________________

From report at bugs.python.org  Wed Apr 23 19:08:49 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Wed, 23 Apr 2008 17:08:49 +0000
Subject: [issue1381] cmath is numerically unsound
In-Reply-To: <1194116338.25.0.15025018351.issue1381@psf.upfronthosting.co.za>
Message-ID: <1208970529.13.0.5127670827.issue1381@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Substantial fixes for the cmath module went into the trunk and the py3k 
branches as part of the merge of the trunk-math branch.  These fixes 
address the asinh problems in this issue, amongst other things.  See 
r62380 (trunk) and r62384 (py3k).

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1381>
__________________________________

From report at bugs.python.org  Wed Apr 23 19:55:14 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Wed, 23 Apr 2008 17:55:14 +0000
Subject: [issue1767370] Make xmlrpc use HTTP/1.1 and keepalive
Message-ID: <1208973314.27.0.969668632437.issue1767370@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1767370>
_____________________________________

From report at bugs.python.org  Wed Apr 23 22:19:55 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 23 Apr 2008 20:19:55 +0000
Subject: [issue2672] speed of set.update([])
In-Reply-To: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>
Message-ID: <1208981995.67.0.765672635502.issue2672@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

This has nothing to do with set.update, the difference is due to the
time to setup the generator:

$ python -m timeit -s 'x = set(range(10000)); y = []' 'x.update(y)'
1000000 loops, best of 3: 0.38 usec per loop
$ python -m timeit -s 'x = set(range(10000)); y = (i for i in [])'
'x.update(y)'
1000000 loops, best of 3: 0.335 usec per loop

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Wed Apr 23 22:38:28 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 23 Apr 2008 20:38:28 +0000
Subject: [issue2672] speed of set.update([])
In-Reply-To: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>
Message-ID: <1208983108.06.0.379658732126.issue2672@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

I concur.  The source code for set_update() in Objects/setobject.c 
shows that both versions are accessed through the iterator protocol, so 
what you're seeing are the basic performance differences (start-up and 
per-item costs) for genexps vs list iterators.

----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Wed Apr 23 22:38:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Apr 2008 20:38:49 +0000
Subject: [issue2673] error on optparse page
In-Reply-To: <1208927314.01.0.909798143433.issue2673@psf.upfronthosting.co.za>
Message-ID: <1208983129.32.0.173954578533.issue2673@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thank you! Fixed in r62469.

----------
nosy: +benjamin.peterson
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2673>
__________________________________

From report at bugs.python.org  Wed Apr 23 22:44:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 23 Apr 2008 20:44:02 +0000
Subject: [issue2676] email/message.py [Message.get_content_type]: Trivial
	regex hangs on pathological input
In-Reply-To: <1208970017.45.0.457761108735.issue2676@psf.upfronthosting.co.za>
Message-ID: <1208983442.75.0.204425063155.issue2676@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
assignee:  -> barry
type:  -> resource usage

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2676>
__________________________________

From report at bugs.python.org  Thu Apr 24 01:39:05 2008
From: report at bugs.python.org (Russ Cox)
Date: Wed, 23 Apr 2008 23:39:05 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1208993945.24.0.323738880671.issue2650@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
keywords: +patch
Added file: http://bugs.python.org/file10080/re.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 24 02:14:45 2008
From: report at bugs.python.org (David Wolever)
Date: Thu, 24 Apr 2008 00:14:45 +0000
Subject: [issue2431] 2to3 is rather slow
In-Reply-To: <1205991054.16.0.327808127723.issue2431@psf.upfronthosting.co.za>
Message-ID: <1208996085.73.0.533298006359.issue2431@psf.upfronthosting.co.za>


David Wolever <wolever at cs.toronto.edu> added the comment:

I've cleaned up and applied the patch in r62470.
As Collin suggested, I'm leaving the ticket open to use in the future.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2431>
__________________________________

From report at bugs.python.org  Thu Apr 24 03:30:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Apr 2008 01:30:05 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1209000605.53.0.452414546715.issue2650@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks.

The loop in escape should really use enumerate instead of "for i in
range(len(pattern))".

Instead of using a loop, can't the test just use
"self.assertEqual(re.esacpe(same), same)?" Also, please add tests for
what re.escape should escape.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 24 05:22:50 2008
From: report at bugs.python.org (David Wolever)
Date: Thu, 24 Apr 2008 03:22:50 +0000
Subject: [issue2412] Check 2to3 for support of print function.
In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za>
Message-ID: <1209007370.44.0.647380508178.issue2412@psf.upfronthosting.co.za>


David Wolever <wolever at cs.toronto.edu> added the comment:

Here is a patch that will detect a `from __future__ import print_function` 
and adjust the grammar appropriately.

Any objections?

----------
keywords: +patch
Added file: http://bugs.python.org/file10081/print_function_detection.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2412>
__________________________________

From report at bugs.python.org  Thu Apr 24 08:47:20 2008
From: report at bugs.python.org (Humberto Diogenes)
Date: Thu, 24 Apr 2008 06:47:20 +0000
Subject: [issue1883] Adapt pydoc to new doc system
In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
Message-ID: <1209019640.54.0.380626876351.issue1883@psf.upfronthosting.co.za>


Humberto Diogenes <humberto at digi.com.br> added the comment:

It looks like there are no automated tests for pydoc; it's even listed in test_sundry.py.

There's only one file Lib/test/pydocfodder.py which defines "Something just to look at 
via pydoc", but isn't used anywhere (I grepped and found nothing).

I've attached a patch just to document one point where pydoc behavior differs from 2.5 to 
3.0: describe() used to return 'instance of ClassX', now it returns only 'ClassX' (which 
means this test will pass in 2.5 but not in 3.0).

Functions main and test_main were copied from test_modulefinder.

----------
keywords: +patch
nosy: +hdiogenes
Added file: http://bugs.python.org/file10082/py3k-test_pydoc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1883>
__________________________________

From report at bugs.python.org  Thu Apr 24 11:06:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 09:06:08 +0000
Subject: [issue1883] Adapt pydoc to new doc system
In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
Message-ID: <1209027968.78.0.710461523482.issue1883@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

It's not a difference between versions, but a difference between
old-style and new-style classes (which derive from object).
In 3.0, all classes are new-style...

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1883>
__________________________________

From report at bugs.python.org  Thu Apr 24 12:01:26 2008
From: report at bugs.python.org (Ludovico Gardenghi)
Date: Thu, 24 Apr 2008 10:01:26 +0000
Subject: [issue2677] Argument rules in callables do not apply when function
	uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>


New submission from Ludovico Gardenghi <garden at acheronte.it>:

(It seems strange to me that this issue hasn't been raised in the past,
maybe I just failed to find it in the BTS. In that case please excuse me
and please point me to the original discussion.)

The Language Reference, section 5.3.4, states that, for every callable
object:

"[...] If keyword arguments are present, they are first converted to
positional arguments, as follows. First, a list of unfilled slots is
created for the formal parameters. [...] Next, for each keyword
argument, the identifier is used to determine the corresponding slot (if
the identifier is the same as the first formal parameter name, the first
slot is used, and so on). [...]"

This is not true if the function is defined using the C function
PyArg_ParseTuple, and this happens a lot in the standard library. I
discovered it trying to call os.open("filename", flag=os.O_RDONLY), just
to make an example. In this case it seems useless to specify the
keyword, but I have to write a generic "wrapping" function that takes a
function name and its arguments (as keyword arguments) and call the
original function after having changed the content of some of the arguments.

Apart from the reason, I believe that this behavior is inconsistent with
the language definition and should be fixed. I'm very new to Python, but
maybe the format string of ParseTuple should be extended in order to
accept also the name of the positional arguments? Or something like
ParseTupleAndKeywords should be used instead?

I tried only on Python 2.4 and 2.5 but I took a look at the source code
of 2.6 and 3.0 and I believe the issue is still there.

----------
components: Library (Lib)
messages: 65712
nosy: garden
severity: normal
status: open
title: Argument rules in callables do not apply when function uses PyArg_ParseTuple
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 12:03:03 2008
From: report at bugs.python.org (Ludovico Gardenghi)
Date: Thu, 24 Apr 2008 10:03:03 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209031383.99.0.291714560366.issue2677@psf.upfronthosting.co.za>


Changes by Ludovico Gardenghi <garden at acheronte.it>:


----------
title: Argument rules in callables do not apply when function uses PyArg_ParseTuple -> Argument rules for callables do not apply when function implementation uses PyArg_ParseTuple

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 12:22:16 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 24 Apr 2008 10:22:16 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209032536.21.0.94173852655.issue2677@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I fail to see the problem. The open function really doesn't have a named
parameter called flags; the positional parameters are unnamed. So there
is no violation of the language reference, AFAICT. Perhaps it would be
useful to point out that some parameters are available only for
positional passing, as they are unnamed.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 12:35:12 2008
From: report at bugs.python.org (Ludovico Gardenghi)
Date: Thu, 24 Apr 2008 10:35:12 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209033312.75.0.825606815764.issue2677@psf.upfronthosting.co.za>


Ludovico Gardenghi <garden at acheronte.it> added the comment:

I'd believe you when you say "positional parameters are unnamed", but:

- the language reference contains terms such as "first formal parameter
name". This means that positional parameters *may* have a name but may
also have no name?
- if you define a python function as "def f(a, b, c):" you can call it
using keyword arguments instead of positional (e.g. f(1, c=3, b=2)).

Could you please explain me what I'm still missing? (I repeat - I met
python for the first time 2 weeks ago, so it may very well be the case
that I'm completely wrong)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 12:50:20 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 24 Apr 2008 10:50:20 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209033312.75.0.825606815764.issue2677@psf.upfronthosting.co.za>
Message-ID: <481065E9.2070309@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I'd believe you when you say "positional parameters are unnamed", but:
> 
> - the language reference contains terms such as "first formal parameter
> name". This means that positional parameters *may* have a name but may
> also have no name?

Correct (although that is actually my interpretation of the
implementation; it's probably not a feature of the language itself).

> - if you define a python function as "def f(a, b, c):" you can call it
> using keyword arguments instead of positional (e.g. f(1, c=3, b=2)).

Unnamed positional parameters are only available in C code. You cannot
write a function with unnamed parameters in Python.

> Could you please explain me what I'm still missing? (I repeat - I met
> python for the first time 2 weeks ago, so it may very well be the case
> that I'm completely wrong)

It's just how PyArg_ParseTuple works: it doesn't receive any parameter
names for the positional parameters, so it can't possibly do the
matching that the language prescribes for positional parameters.
Instead, PyArg_ParseTuple operates *just* by position, hence it
effectively implements unnamed positional parameters.

You are not completely wrong. It's just that this detail is something
most people recognize at some point and accept as a fact, regardless
of what the language specification says (and, as I claim, that text
isn't incorrect - or the implementation isn't incorrect -- it's just
underspecified, failing to mention a detail specific to CPython)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 13:08:45 2008
From: report at bugs.python.org (Ludovico Gardenghi)
Date: Thu, 24 Apr 2008 11:08:45 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209035325.46.0.0471563034996.issue2677@psf.upfronthosting.co.za>


Ludovico Gardenghi <garden at acheronte.it> added the comment:

> You are not completely wrong. It's just that this detail is something
> most people recognize at some point and accept as a fact, regardless
> of what the language specification says (and, as I claim, that text
> isn't incorrect - or the implementation isn't incorrect -- it's just
> underspecified, failing to mention a detail specific to CPython)

Ok. I think I'll end up accepting it as a fact, too :) and work around
the issue. IMHO it would be perfectly acceptable to say "if you use
CPython and extend python with some C functions you must expect this
behavior", but it's slightly less acceptable that different modules from
the standard library have different behaviors (depending on which
language has been used to implement them):

- open(mode='r', name='filename') works
- os.open(flag=os.O_RDONLY, filename='filename') does not work
- calendar.weekday(2008, day=24, month=4) works
- math.fmod(x=10, y=3) does not work
- ...

>From the point of view of someone who writes python code there should be
no difference between the behavior of these calls, as long as they are
included in the standard python library. IMHO, again.

Maybe yes, the easier but probably harmless solution is to change the
documentation and point out that "in general, you can't". Maybe this
somehow leans towards promoting a bug to the rank of feature? ;-)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 13:14:14 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 24 Apr 2008 11:14:14 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209035325.46.0.0471563034996.issue2677@psf.upfronthosting.co.za>
Message-ID: <48106B83.9070607@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Maybe yes, the easier but probably harmless solution is to change the
> documentation and point out that "in general, you can't". Maybe this
> somehow leans towards promoting a bug to the rank of feature? ;-)

The language spec is stuck between saying what the abstract Python
language is supposed to do, and describing what CPython precisely
does. You shouldn't use keyword arguments to pass non-optional
positional arguments, IMO, but the text describes precisely what
happens if you do - for Python functions. The more vague
specification then shouldn't say "you can't" (because that would
indicate that you get an exception when you try), but "it's
unspecified", then going on to say what CPython happens to do
in some release.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 13:29:41 2008
From: report at bugs.python.org (Ludovico Gardenghi)
Date: Thu, 24 Apr 2008 11:29:41 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209036581.85.0.300793385592.issue2677@psf.upfronthosting.co.za>


Ludovico Gardenghi <garden at acheronte.it> added the comment:

At present, "unspecified" is surely better than "you can't", that's a
good point. I understand the difficulties of balancing the reference
between the abstract definition and the actual implementation. But I
still believe that this should not be an unspecified behavior, either in
one direction or another. At least somewhere in the future.

Anyway, thanks for the explanation :)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 13:42:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 24 Apr 2008 11:42:10 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209037330.79.0.787577898485.issue2677@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Making it a documentation issue; I don't think the implementation should
change. Georg, if you don't see the need for action, feel free to close it.

----------
assignee:  -> georg.brandl
components: +Documentation -Library (Lib)
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Thu Apr 24 14:02:49 2008
From: report at bugs.python.org (Nikolay Kim)
Date: Thu, 24 Apr 2008 12:02:49 +0000
Subject: [issue2678] hmac performance optimization
In-Reply-To: <1209038569.77.0.0418872220243.issue2678@psf.upfronthosting.co.za>
Message-ID: <1209038569.77.0.0418872220243.issue2678@psf.upfronthosting.co.za>


New submission from Nikolay Kim <fafhrd91 at gmail.com>:

i removed lambda in _strxor function

----------
components: Library (Lib)
files: hmac.py.diff
keywords: patch
messages: 65720
nosy: fafhrd
severity: normal
status: open
title: hmac performance optimization
type: performance
versions: Python 2.5
Added file: http://bugs.python.org/file10083/hmac.py.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2678>
__________________________________

From report at bugs.python.org  Thu Apr 24 14:38:30 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 12:38:30 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1209040710.15.0.0584534174667.issue2650@psf.upfronthosting.co.za>


Russ Cox <rsc at swtch.com> added the comment:

> The loop in escape should really use enumerate 
> instead of "for i in range(len(pattern))".

It needs i to edit s[i].

> Instead of using a loop, can't the test just
> use "self.assertEqual(re.esacpe(same), same)?" 

Done.

> Also, please add tests for what re.escape should escape.

That's handled in the existing test over all bytes 0-255.

Added file: http://bugs.python.org/file10084/re.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Thu Apr 24 15:19:13 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 13:19:13 +0000
Subject: [issue2678] hmac performance optimization
In-Reply-To: <1209038569.77.0.0418872220243.issue2678@psf.upfronthosting.co.za>
Message-ID: <1209043153.92.0.134064553404.issue2678@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

issue1618455 (r53065) already improved performance and was probably
better: _strxor does not exist anymore, and has been replaced by a call
to translate().

----------
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2678>
__________________________________

From report at bugs.python.org  Thu Apr 24 15:52:20 2008
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 24 Apr 2008 13:52:20 +0000
Subject: [issue2679] email.feedparser regex duplicate
In-Reply-To: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za>
Message-ID: <1209045140.34.0.682842030487.issue2679@psf.upfronthosting.co.za>


New submission from Jim Jewett <jimjjewett at users.sourceforge.net>:

feedparser defines four regexs for end-of-line, but two are redundant.

NLCRE checks for the three common line endings.
NLCRE_crack also captures the line ending.
NLCRE_eol also adds a $ to ensure it is at the end.
NLCRE_bol ... is identical to NLCRE_crack.

It should either use a ^ to insist on line-start, or be explicitly the 
same.  (e.g., NLCRE_bol=NLCRE_crack.)  (It gets away with not listing the ^ 
because the current code only uses NLCRE_bol.match.

(Actually, if the regexes are considered private, then the current code 
could just use the bound methods directly ... setting NLCRE_bol to the
 .match method, NLCRE_eol to the .search method, and NLCRE_crack to the
 .split method.)

----------
components: Library (Lib)
messages: 65723
nosy: jimjjewett
severity: normal
status: open
title: email.feedparser regex duplicate
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2679>
__________________________________

From report at bugs.python.org  Thu Apr 24 16:01:02 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Apr 2008 14:01:02 +0000
Subject: [issue1496032] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Message-ID: <1209045662.78.0.287730450606.issue1496032@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

There are some current math and cmath test failures on the Debian alpha 
buildbots (2.6 and 3.0), and I think there's a good possibility that 
adding -mieee to BASECFLAGS would fix these.

I'm struggling to find the right way to do this in configure.in.
I've found the GCC specific section for BASECFLAGS (around line 800), but 
I don't know how to write a test for an alpha CPU (rather than a test for 
a specific operating system).  Any hints or pointers?

----------
nosy: +marketdickinson

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1496032>
_____________________________________

From report at bugs.python.org  Thu Apr 24 16:23:36 2008
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 24 Apr 2008 14:23:36 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1209047016.15.0.349101733511.issue2636@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

> These features are to bring the Regexp code closer in line with Perl 5.10

Why 5.1 instead of 5.8 or at least 5.6?  Is it just a scope-creep issue?

> as well as add a few python-specific

because this also adds to the scope.


> 2) Make named matches direct attributes 
> of the match object; i.e. instead of m.group('foo'), 
> one will be able to write simply m.foo.

> 3) (maybe) make Match objects subscriptable, such 
> that m[n] is equivalent to m.group(n) and allow slicing.

(2) and (3) would both be nice, but I'm not sure it makes sense to do 
*both* instead of picking one.

> 5) Add a well-formed, python-specific comment modifier, 
> e.g. (?P#...);  

[handles parens in comments without turning on verbose, but is slower]

Why?  It adds another incompatibility, so it has to be very useful or 
clear.  What exactly is the advantage over just turning on verbose?

> 9) C-Engine speed-ups. ...
> a number of Macros are being eliminated where appropriate.

Be careful on those, particular on str/unicode and different compile options.

----------
nosy: +jimjjewett

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Thu Apr 24 16:31:54 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 14:31:54 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1209047514.22.0.0556880588315.issue2636@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> > These features are to bring the Regexp code closer in line 
> > with Perl 5.10
> 
> Why 5.1 instead of 5.8 or at least 5.6?  Is it just a scope-creep issue?

5.10.0 comes after 5.8 and is the latest version (2007/12/18)! 
Yes it is confusing.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Thu Apr 24 18:06:29 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Thu, 24 Apr 2008 16:06:29 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1209053188.95.0.38218801405.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Thanks Jim for your thoughts!

Armaury has already explained about Perl 5.10.0.  I suppose it's like
Macintosh version numbering, since Mac Tiger went from version 10.4.9 to
10.4.10 and 10.4.11 a few years ago.  Maybe we should call Python 2.6
Python 2.06 just in case.  But 2.6 is the known last in the 2 series so
it's not a problem for us!  :)

>> as well as add a few python-specific
>
> because this also adds to the scope.

At this point the only python-specific changes I am proposing would be
items 2, 3 (discussed below), 5 (discussed below), 6 and 7.  6 is only a
documentation change, the code is already implemented.  7 is just a
better behavior.  I think it is RARE one compiles more than 100 unique
regular expressions, but you never know as projects tend to grow over
time, and in the old code the 101st would be recompiled even if it was
just compiled 2 minutes ago.  The patch is available so I leave it to
the community to judge for themselves whether it is worth it, but as you
can see, it's not a very large change.

>> 2) Make named matches direct attributes 
>> of the match object; i.e. instead of m.group('foo'), 
>> one will be able to write simply m.foo.
>
>> 3) (maybe) make Match objects subscriptable, such 
>> that m[n] is equivalent to m.group(n) and allow slicing.
>
> (2) and (3) would both be nice, but I'm not sure it makes sense to do 
> *both* instead of picking one.

Well, I think named matches are better than numbered ones, so I'd
definitely go with 2.  The problem with 2, though, is that it still
leaves the rather typographically intense m.group(n), since I cannot
write m.3.  However, since capture groups are always numbered
sequentially, it models a list very nicely.  So I think for indexing by
group number, the subscripting operator makes sense.  I was not
originally suggesting m['foo'] be supported, but I can see how that may
come out of 3.  But there is a restriction on python named matches that
they have to be valid python and that strikes me as 2 more than 3
because 3 would not require such a restriction but 2 would.  So at least
I want 2, but it seems IMHO m[1] is better than m.group(1) and not in
the least hard or a confusing way of retrieving the given group.  Mind
you, the Match object is a C-struct with python binding and I'm not
exactly sure how to add either feature to it, but I'm sure the C-API
manual will help with that.

>> 5) Add a well-formed, python-specific comment modifier, 
>> e.g. (?P#...);  
>
> [handles parens in comments without turning on verbose, but is slower]
>
> Why?  It adds another incompatibility, so it has to be very useful or 
> clear.  What exactly is the advantage over just turning on verbose?

Well, Larry Wall and Guido agreed long ago that we, the python
community, own all expressions of the form (?P...) and although I'd be
my preference to make (?#...) more in conformance with understanding
parenthesis nesting, changing the logic behind THAT would make python
non-standard.  So as far as any conflicting design, we needn't worry.

As for speed, the this all occurs in the parser and does not effect the
compiler or engine.  It occurs only after a (?P has been read and then
only as the last check before failure, so it should not be much slower
except when the expression is invalid.  The actual execution time to
find the closing brace of (?P#...) is a bit slower than that for (?#...)
but not by much.

Verbose is generally a good idea for anything more than a trivial
Regular Expression.  However, it can have overhead if not included as
the first flag: an expression is always checked for verbose
post-compilation and if it is encountered, the expression is compiled a
second time, which is somewhat wasteful.  But the reason I like the
(?P#...) over (?#...) is because I think people would more tend to assume:

r'He(?# 2 (TWO) ls)llo' should match "Hello" but it doesn't.

That expression only matches "He ls)llo", so I created the (?P#...) to
make the comment match type more intuitive:

r'He(?P# 2 (TWO) ls)llo' matches "Hello".

>> 9) C-Engine speed-ups. ...
>> a number of Macros are being eliminated where appropriate.
>
> Be careful on those, particular on str/unicode and different
> compile options.

Will do; thanks for the advice!  I have only observed the UNICODE flag
controlling whether certain code is used (besides the ones I've added)
and have tried to stay true to that when I encounter it.  Mind you,
unless I can get my extra 10% it's unlikely I'd actually go with item 9
here, even if it is easier to read IMHO.  However, I want to run the new
engine proposal through gprof to see if I can track down some bottlenecks.

At some point, I hope to get my current changes on Launchpad if I can
get that working.  If I do, I'll give a link to how people can check out
my working code here as well.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Thu Apr 24 18:29:58 2008
From: report at bugs.python.org (Carlos Scheidegger)
Date: Thu, 24 Apr 2008 16:29:58 +0000
Subject: [issue2680] gotcha: _fields_ is final but accepts lists
In-Reply-To: <1209054598.56.0.869643516556.issue2680@psf.upfronthosting.co.za>
Message-ID: <1209054598.56.0.869643516556.issue2680@psf.upfronthosting.co.za>


New submission from Carlos Scheidegger <cscheid at sci.utah.edu>:

When creating ctypes.Structure classes dynamically, there's a gotcha.
_fields_ is final, but it takes a list that can be appended to. I'm not
sure this is a bug, but I would argue it is a lot more surprising than
it could be:

Python 2.5.2 (r252:60911, Apr 21 2008, 11:17:30) 
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> class Foo(ctypes.Structure):
...  _fields_ = [('dim', ctypes.c_int)]
... 
>>> x = Foo()
>>> x.dim = 1
>>> x.dim = '123' # This is ok, and expected
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: an integer is required
>>> 
>>> 
>>> class Bar(ctypes.Structure):
...  pass
... 
>>> x._fields_ = []
>>> x._fields_.append(('dim', ctypes.c_int))
>>> x = Bar()
>>> x.dim = '123' # This, however, is strange
>>>

This was somewhat foreseen, since _fields_ is final:

>>> class Baz(ctypes.Structure):
...  pass
... 
>>> Baz._fields_ = []
>>> Baz._fields_ = [('dim', ctypes.c_int)]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: _fields_ is final

Would it not make sense for _fields_ to require a tuple, so that it
cannot be mutated? I realize this is a big change. Currently, ctypes
accepts tuples as the input to _fields_. Maybe a warning should be
issued when a list is assigned to _fields_?

----------
assignee: theller
components: ctypes
messages: 65728
nosy: cscheid, theller
severity: normal
status: open
title: gotcha: _fields_ is final but accepts lists
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2680>
__________________________________

From report at bugs.python.org  Thu Apr 24 18:31:23 2008
From: report at bugs.python.org (Lukas Meuser)
Date: Thu, 24 Apr 2008 16:31:23 +0000
Subject: [issue2681] octal literals beginning with 8 don't raise a SyntaxError
In-Reply-To: <1209054682.92.0.234885445722.issue2681@psf.upfronthosting.co.za>
Message-ID: <1209054682.92.0.234885445722.issue2681@psf.upfronthosting.co.za>


New submission from Lukas Meuser <lukas-pydev at quittenbrod.de>:

Octal literals containing an 8 or a 9 should raise a SyntaxError, but 8 ist 
accepted as the first character of such a literal (e.g., 0o8 or 0o876, but 
not 0o678). Those literals evaluate to 0.0.
The fix for this is trivial, a patch against current SVN (r62479) is 
attached.

----------
components: Interpreter Core
files: octal_literals.diff
keywords: patch
messages: 65729
nosy: lukas.meuser
severity: normal
status: open
title: octal literals beginning with 8 don't raise a SyntaxError
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10085/octal_literals.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2681>
__________________________________

From report at bugs.python.org  Thu Apr 24 19:42:57 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 17:42:57 +0000
Subject: [issue2680] gotcha: _fields_ is final but accepts lists
In-Reply-To: <1209054598.56.0.869643516556.issue2680@psf.upfronthosting.co.za>
Message-ID: <1209058977.78.0.362619100484.issue2680@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The __slots__ member of a class object has the same behavior.
You may mutate it (even replace it) but this has no effect: only the
value available when the "class" statement was executed is relevant.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2680>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:12:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 18:12:15 +0000
Subject: [issue2681] octal literals beginning with 8 don't raise a SyntaxError
In-Reply-To: <1209054682.92.0.234885445722.issue2681@psf.upfronthosting.co.za>
Message-ID: <1209060735.24.0.519640502138.issue2681@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Corrected as r62480.
I changed your patch a little bit: it seemed more logical to use 
   (c < '0' || c >= '8')
As it is the exact counterpart of 
   ('0' <= c && c < '8')
used a few lines below.

Thanks for the report!

----------
nosy: +amaury.forgeotdarc
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2681>
__________________________________

From report at bugs.python.org  Thu Apr 24 19:54:08 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 24 Apr 2008 17:54:08 +0000
Subject: [issue2680] gotcha: _fields_ is final but accepts lists
In-Reply-To: <1209058977.78.0.362619100484.issue2680@psf.upfronthosting.co.za>
Message-ID: <4810C937.1040801@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> The __slots__ member of a class object has the same behavior.
> You may mutate it (even replace it) but this has no effect: only the
> value available when the "class" statement was executed is relevant.

The rules in ctypes are a little bit more complicated (but thanks for the
__slots__ example, Amaury):

The _fields_ sequence is used when the class statement is executed (if
_fields_ are given), or when _fields_ are assigned to the class.
The third case appears when an instance of a structure class without _fields_
is actually *used*: by creating an instance of the class, by using the
class in another structure _fields_ definition; in this case the structure class
is built with an empty _fields_ list.

To answer the OP quetsions:  Yes, disallowing lists as _fields_ would break
too much code.  Also, I think tuples in lists are easier to read than nested tuples.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2680>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:21:49 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 24 Apr 2008 18:21:49 +0000
Subject: [issue2655] Create ctypes instances from buffer interface
In-Reply-To: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>
Message-ID: <1209061309.15.0.851618253554.issue2655@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

The suggestion by Lenard Lindstrom was an additional method named
'from_buffer_copy'.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2655>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:23:48 2008
From: report at bugs.python.org (John Arbash Meinel)
Date: Thu, 24 Apr 2008 18:23:48 +0000
Subject: [issue2672] speed of set.update(
In-Reply-To: <1208981995.67.0.765672635502.issue2672@psf.upfronthosting.co.za>
Message-ID: <4810D028.5040702@arbash-meinel.com>


John Arbash Meinel <john at arbash-meinel.com> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alexander Belopolsky wrote:
> Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:
> 
> This has nothing to do with set.update, the difference is due to the
> time to setup the generator:
> 
> $ python -m timeit -s 'x = set(range(10000)); y = []' 'x.update(y)'
> 1000000 loops, best of 3: 0.38 usec per loop
> $ python -m timeit -s 'x = set(range(10000)); y = (i for i in [])'
> 'x.update(y)'
> 1000000 loops, best of 3: 0.335 usec per loop
> 
> ----------
> nosy: +belopolsky
> 
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2672>
> __________________________________
> 

That is true, though if I just force a generator overhead:

% python -m timeit -s 'x = set(range(10000)); y = []' 'x.update(y)'
1000000 loops, best of 3: 0.204 usec per loop
% python -m timeit -s 'x = set(range(10000)); y = (i for i in [])'
'x.update(y)'
10000000 loops, best of 3: 0.173 usec per loop
% python -m timeit -s 'x = set(range(10000)); l = []' 'x.update(i for i
in l)'
1000000 loops, best of 3: 0.662 usec per loop
 python -m timeit -s 'x = set(range(10000)); l = []; y = (i for i in l)'
'(i for i in l); x.update(y)'
1000000 loops, best of 3: 1.87 usec per loop

So if you compare consuming a generator multiple times to creating it
each time, it is 0.662 usec - 0.173 usec = 0.489 usec to create a generator.

So why does: "(i for i in l); x.update(y)" take an additional 1.208 usec.

(I'm certainly willing to believe that set.update() is generator/list
agnostic, but something weird is still happening.)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIENAoJdeBCYSNAAMRAk2yAJ4okAalR6zWD0/E5XHei/ckce+L7QCgstEQ
l+6+bl7oAJMhdJ70viqicnQ=
=pLX6
-----END PGP SIGNATURE-----

----------
title: speed of set.update([]) -> speed of set.update(

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:09:26 2008
From: report at bugs.python.org (Jim Jewett)
Date: Thu, 24 Apr 2008 18:09:26 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1209060566.4.0.565320166669.issue2636@psf.upfronthosting.co.za>


Jim Jewett <jimjjewett at users.sourceforge.net> added the comment:

Python 2.6 isn't the last, but Guido has said that there won't be a 2.10.

> Match object is a C-struct with python binding
> and I'm not exactly sure how to add either feature to it

I may be misunderstanding -- isn't this just a matter of writing the 
function and setting it in the tp_as_sequence and tp_as_mapping slots?

> Larry Wall and Guido agreed long ago that we, the python
> community, own all expressions of the form (?P...)

Cool -- that reference should probably be added to the docs.  For someone 
trying to learn or translate regular expressions, it helps to know that (?P
 ...) is explicitly a python extension (even if Perl adopts it later).

Definately put the example in the doc.  

    r'He(?# 2 (TWO) ls)llo' should match "Hello" but it doesn't.  Maybe 
even without the change, as doco on the current situation.

Does VERBOSE really have to be the first flag, or does it just have to be on 
the whole pattern instead of an internal switch?

I'm not sure I fully understand what you said about template.  Is this a 
special undocumented switch, or just an internal optimization mode that 
should be triggered whenever the repeat operators don't happen to occur?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:07:10 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 24 Apr 2008 18:07:10 +0000
Subject: [issue2682] cyclic reference in ctypes CFunctionType objects
In-Reply-To: <1209060430.76.0.330100057141.issue2682@psf.upfronthosting.co.za>
Message-ID: <1209060430.76.0.330100057141.issue2682@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

Zachary Pincus posted a message about this cyclic reference in ctypes
CFunctionType objects.  The reference has the problem that these objects
are cleaned up later than expected.

The attached patch fixes this problem by removing the cyclic reference.

----------
assignee: theller
components: ctypes
files: cthunk.patch
keywords: patch
messages: 65733
nosy: theller
severity: normal
status: open
title: cyclic reference in ctypes CFunctionType objects
type: resource usage
versions: Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10086/cthunk.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2682>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:37:47 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Thu, 24 Apr 2008 18:37:47 +0000
Subject: [issue2682] cyclic reference in ctypes CFunctionType objects
In-Reply-To: <1209060430.76.0.330100057141.issue2682@psf.upfronthosting.co.za>
Message-ID: <1209062267.63.0.800079898715.issue2682@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please elaborate your (apparent) concerns about this patch? IOW,
why did you not check it in?

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2682>
__________________________________

From report at bugs.python.org  Thu Apr 24 19:54:50 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 24 Apr 2008 17:54:50 +0000
Subject: [issue2680] gotcha: _fields_ is final but accepts lists
In-Reply-To: <1209054598.56.0.869643516556.issue2680@psf.upfronthosting.co.za>
Message-ID: <1209059690.6.0.267222318652.issue2680@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Closing as won't fix.

----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2680>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:45:05 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 24 Apr 2008 18:45:05 +0000
Subject: [issue2682] cyclic reference in ctypes CFunctionType objects
In-Reply-To: <1209062267.63.0.800079898715.issue2682@psf.upfronthosting.co.za>
Message-ID: <4810D528.2030504@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

> Can you please elaborate your (apparent) concerns about this patch? IOW,
> why did you not check it in?

I have no concerns about the patch, and I am currently committing it.
I'm uploading so that I can points others to it, and (hopefully) to test
it before some alpha release.

It is part of my workflow: I develop a patch, test it locally, upload it
and eventually commit it sonner or later, sometimes changing things
depending on feedback I get.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2682>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:57:59 2008
From: report at bugs.python.org (Thomas Heller)
Date: Thu, 24 Apr 2008 18:57:59 +0000
Subject: [issue2682] cyclic reference in ctypes CFunctionType objects
In-Reply-To: <1209060430.76.0.330100057141.issue2682@psf.upfronthosting.co.za>
Message-ID: <1209063479.07.0.0598159101869.issue2682@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Fixed in trunk and py3k, committed as rev 62481 (trunk), rev 62484 (py3k).

I'll leave this open until the decision about backporting to
release25-maint is made.

----------
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2682>
__________________________________

From report at bugs.python.org  Thu Apr 24 21:29:35 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Thu, 24 Apr 2008 19:29:35 +0000
Subject: [issue2672] speed of set.update(
In-Reply-To: <4810D028.5040702@arbash-meinel.com>
Message-ID: <d38f5330804241229p796acbc4x7280c37a644b2e30@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Thu, Apr 24, 2008 at 2:23 PM, John Arbash Meinel
<report at bugs.python.org> wrote:
..
>  So if you compare consuming a generator multiple times to creating it
>  each time, it is 0.662 usec - 0.173 usec = 0.489 usec to create a generator.
>
>  So why does: "(i for i in l); x.update(y)" take an additional 1.208 usec.
>
>  (I'm certainly willing to believe that set.update() is generator/list
>  agnostic, but something weird is still happening.)

I've seen a similar strangeness in timings:

$ python -m timeit '(i for i in [])'
100000 loops, best of 3: 4.16 usec per loop

but

$ python -m timeit -s 'x = set()' 'x.update(i for i in [])'
1000000 loops, best of 3: 1.31 usec per loop

on the other hand,

$ python -m timeit -s 'x = []' 'x.extend(i for i in [])'
100000 loops, best of 3: 4.54 usec per loop

How can x.update(i for i in []) take *less* time than simply creating a genexp?

Note that there is no apparent bytecode tricks here:

  1           0 LOAD_CONST               0 (<code object <genexpr> at
0xf7e88920, file "<stdin>", line 1>)
              3 MAKE_FUNCTION            0
              6 BUILD_LIST               0
              9 GET_ITER
             10 CALL_FUNCTION            1
             13 RETURN_VALUE
>>> dis(lambda:x.update(i for i in []))
  1           0 LOAD_GLOBAL              0 (x)
              3 LOAD_ATTR                1 (update)
              6 LOAD_CONST               0 (<code object <genexpr> at
0xf7e88920, file "<stdin>", line 1>)
              9 MAKE_FUNCTION            0
             12 BUILD_LIST               0
             15 GET_ITER
             16 CALL_FUNCTION            1
             19 CALL_FUNCTION            1
             22 RETURN_VALUE

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Thu Apr 24 20:57:20 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Thu, 24 Apr 2008 18:57:20 +0000
Subject: [issue2683] subprocess.Popen.communicate takes bytes, not str
In-Reply-To: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>
Message-ID: <1209063440.61.0.967116488341.issue2683@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

subprocess.Popen.communicate is documented as taking a string as the 
input argument. Instead is accepts only a binary stream (bytes).

Python 3.0a4 (r30a4:62126, Apr  3 2008, 15:34:18) [MSC v.1500 32 bit 
(Intel)] on
 win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from subprocess import Popen, PIPE
>>> p = Popen('command.com', stdin=PIPE)
>>> p.communicate("dir\n")
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python30\lib\subprocess.py", line 588, in communicate
    self.stdin.write(input)
  File "C:\Python30\lib\io.py", line 844, in write
    raise TypeError("can't write str to binary stream")
TypeError: can't write str to binary stream

----------
components: Extension Modules
messages: 65740
nosy: kermode
severity: normal
status: open
title: subprocess.Popen.communicate takes bytes, not str
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2683>
__________________________________

From report at bugs.python.org  Thu Apr 24 21:51:29 2008
From: report at bugs.python.org (Charles Merriam)
Date: Thu, 24 Apr 2008 19:51:29 +0000
Subject: [issue2684] Logging Module still failing for %(filename)s, __init__
In-Reply-To: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>
Message-ID: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>


New submission from Charles Merriam <charles.merriam at gmail.com>:

About same as problem in 2.4 Issue1470422 closed without a test case on
MacOS X/Python 2.4.
Also same as
http://mail.python.org/pipermail/python-bugs-list/2004-July/024111.html
and so on back for years.

What happens:

chasm at chasm-laptop:~/py$ cat x.py
import logging
logging.basicConfig(level=logging.DEBUG,
                   
format="%(levelname)s:%(pathname)s:%(lineno)d:%(message)s")
from logging import debug

if __name__ == "__main__":
    debug("Hello")
chasm at chasm-laptop:~/py$ python x.py
DEBUG:logging/__init__.py:1327:Hello

What should happen:

It should print DEBUG: x.py:3:Hello

Why it fails:

Because logging guesses that the right sys._getframe(level) should be
level 3 in __init__.py:71, in currentFrame
if hasattr(sys, '_getframe'): currentframe = lambda: sys._getframe(3)

What should happen:

It shouldn't guess.  In Python 2.5, the lambda might count.  In any
case, the level is off by one (4).  I suggest that it get set by walking
up the stack from until it exits the stack frame.

----------
components: Library (Lib)
messages: 65743
nosy: CharlesMerriam
severity: normal
status: open
title: Logging Module still failing for %(filename)s, __init__
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2684>
__________________________________

From report at bugs.python.org  Thu Apr 24 21:53:52 2008
From: report at bugs.python.org (Charles Merriam)
Date: Thu, 24 Apr 2008 19:53:52 +0000
Subject: [issue2684] Logging Module still failing for %(filename)s, __init__
In-Reply-To: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>
Message-ID: <1209066832.94.0.0185812721141.issue2684@psf.upfronthosting.co.za>


Charles Merriam <charles.merriam at gmail.com> added the comment:

oops, last line should be "exits the stack frames for the logging
module.  This should be a once-per-program-execution event"

Hmm.. tracker should have a preview button.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2684>
__________________________________

From report at bugs.python.org  Thu Apr 24 22:31:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Thu, 24 Apr 2008 20:31:23 +0000
Subject: [issue2471] imp.get_magic() should return bytes, not bytearray
In-Reply-To: <1206341976.98.0.341393013827.issue2471@psf.upfronthosting.co.za>
Message-ID: <1209069083.07.0.361762367965.issue2471@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This was fixed as r62484.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2471>
__________________________________

From report at bugs.python.org  Thu Apr 24 22:36:15 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 20:36:15 +0000
Subject: [issue2471] imp.get_magic() should return bytes, not bytearray
In-Reply-To: <1206341976.98.0.341393013827.issue2471@psf.upfronthosting.co.za>
Message-ID: <1209069375.33.0.239082587889.issue2471@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Oops, sorry for missing the tracker item.
The change was sleeping in my workspace for some time...
Thanks for closing it.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2471>
__________________________________

From report at bugs.python.org  Thu Apr 24 22:38:24 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Apr 2008 20:38:24 +0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1209069504.47.0.247324034415.issue799428@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file9938/bugfix_and_revamp_nametowidget.diff

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
____________________________________

From report at bugs.python.org  Thu Apr 24 22:38:39 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Apr 2008 20:38:39 +0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1209069519.45.0.912050238413.issue799428@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

There was a problem with my previous patch if the widget name was just '.'
New patch attached

Added file: http://bugs.python.org/file10087/bugfix_and_revamp_nametowidget.diff

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
____________________________________

From report at bugs.python.org  Thu Apr 24 22:40:06 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Apr 2008 20:40:06 +0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1209069606.43.0.243496909395.issue799428@psf.upfronthosting.co.za>


Changes by Guilherme Polo <ggpolo at gmail.com>:


Removed file: http://bugs.python.org/file10087/bugfix_and_revamp_nametowidget.diff

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
____________________________________

From report at bugs.python.org  Thu Apr 24 22:40:36 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Thu, 24 Apr 2008 20:40:36 +0000
Subject: [issue799428] tk_focusNext() fails
Message-ID: <1209069636.36.0.688276578792.issue799428@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Sorry for the previous patch, correct one attached now

Added file: http://bugs.python.org/file10088/bugfix_and_revamp_nametowidget.diff

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue799428>
____________________________________

From report at bugs.python.org  Thu Apr 24 22:55:49 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 20:55:49 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1209070549.64.0.182753580809.issue2636@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Thu Apr 24 23:02:18 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:02:18 +0000
Subject: [issue2537] re.compile(r'((x|y+)*)*') should fail
In-Reply-To: <1207157766.7.0.917289707609.issue2537@psf.upfronthosting.co.za>
Message-ID: <1209070938.38.0.263485342514.issue2537@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2537>
__________________________________

From report at bugs.python.org  Thu Apr 24 23:04:00 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:04:00 +0000
Subject: [issue1160] Medium size regexp crashes python
In-Reply-To: <1189670456.94.0.669298411185.issue1160@psf.upfronthosting.co.za>
Message-ID: <1209071040.19.0.16869832864.issue1160@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1160>
__________________________________

From report at bugs.python.org  Thu Apr 24 23:05:17 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:05:17 +0000
Subject: [issue1662581] the re module can perform poorly: O(2**n) versus
	O(n**2)
Message-ID: <1209071117.4.0.00574070578398.issue1662581@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1662581>
_____________________________________

From report at bugs.python.org  Thu Apr 24 23:06:35 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:06:35 +0000
Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported
Message-ID: <1209071195.97.0.701901845256.issue433030@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue433030>
____________________________________

From report at bugs.python.org  Thu Apr 24 23:07:01 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:07:01 +0000
Subject: [issue1693050] \w not helpful for non-Roman scripts
Message-ID: <1209071221.71.0.398780039171.issue1693050@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1693050>
_____________________________________

From report at bugs.python.org  Thu Apr 24 23:07:36 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 21:07:36 +0000
Subject: [issue1883] Adapt pydoc to new doc system
In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
Message-ID: <1209071256.76.0.737974707996.issue1883@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

Humberto, I added your test file in trunk.
I added some other tests: now pydocfodder.py is used by a basic "smoke
test".
The tests revealed two bugs in python3.0...  Thanks!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1883>
__________________________________

From report at bugs.python.org  Thu Apr 24 23:08:30 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:08:30 +0000
Subject: [issue1647489] zero-length match confuses re.finditer()
Message-ID: <1209071310.15.0.658449808846.issue1647489@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1647489>
_____________________________________

From report at bugs.python.org  Thu Apr 24 23:10:58 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:10:58 +0000
Subject: [issue1297193] Search is to long with regex like ^(.+|dontmatch)*$
Message-ID: <1209071458.25.0.784175747199.issue1297193@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1297193>
_____________________________________

From report at bugs.python.org  Thu Apr 24 23:11:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Apr 2008 21:11:52 +0000
Subject: [issue2685] Add -mieee to compile flags, when available
In-Reply-To: <1209071512.37.0.789314022887.issue2685@psf.upfronthosting.co.za>
Message-ID: <1209071512.37.0.789314022887.issue2685@psf.upfronthosting.co.za>


New submission from Mark Dickinson <dickinsm at gmail.com>:

test_math and test_cmath currently fail on Debian/alpha, apparently due to 
mishandling of subnormal numbers.  I have high hopes that this can be 
fixed by compiling with -mieee.

The attached patch modifies the configure script to always use the -mieee 
option on gcc, when available.

----------
components: Build
files: mieee.patch
keywords: patch
messages: 65750
nosy: marketdickinson
severity: normal
status: open
title: Add -mieee to compile flags, when available
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10089/mieee.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2685>
__________________________________

From report at bugs.python.org  Thu Apr 24 23:12:05 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:12:05 +0000
Subject: [issue1721518] Small case which hangs
Message-ID: <1209071525.94.0.110965615719.issue1721518@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1721518>
_____________________________________

From report at bugs.python.org  Thu Apr 24 23:12:50 2008
From: report at bugs.python.org (Russ Cox)
Date: Thu, 24 Apr 2008 21:12:50 +0000
Subject: [issue433024] SRE: (?flag) isn't properly scoped
Message-ID: <1209071570.69.0.54940621528.issue433024@psf.upfronthosting.co.za>


Changes by Russ Cox <rsc at swtch.com>:


----------
nosy: +rsc

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue433024>
____________________________________

From report at bugs.python.org  Thu Apr 24 23:12:52 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Thu, 24 Apr 2008 21:12:52 +0000
Subject: [issue2685] Add -mieee to compile flags, when available
In-Reply-To: <1209071512.37.0.789314022887.issue2685@psf.upfronthosting.co.za>
Message-ID: <1209071572.94.0.0884529232634.issue2685@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

See also issue 1496032.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2685>
__________________________________

From report at bugs.python.org  Thu Apr 24 23:24:49 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Thu, 24 Apr 2008 21:24:49 +0000
Subject: [issue2672] speed of set.update(
In-Reply-To: <1208918684.07.0.896118455388.issue2672@psf.upfronthosting.co.za>
Message-ID: <1209072289.81.0.669976050802.issue2672@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

John, when y=[], the update method has to create a new list iterator on 
each invocation.  But when y is a genexp, it is self-iterable (iow, iter
(y) will return self, not a new object).

Also, when doing timings, it can be helpful to factor-out the attribute 
lookup:

python -m timeit -s 'x=set(range(10000)); y=[]; xu=x.update' 'xu(y)'

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Thu Apr 24 23:39:39 2008
From: report at bugs.python.org (John Arbash Meinel)
Date: Thu, 24 Apr 2008 21:39:39 +0000
Subject: [issue2672] speed of set.update(
In-Reply-To: <1209072289.81.0.669976050802.issue2672@psf.upfronthosting.co.za>
Message-ID: <4810FE04.4070303@arbash-meinel.com>


John Arbash Meinel <john at arbash-meinel.com> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Raymond Hettinger wrote:
> Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:
> 
> John, when y=[], the update method has to create a new list iterator on 
> each invocation.  But when y is a genexp, it is self-iterable (iow, iter
> (y) will return self, not a new object).
> 
> Also, when doing timings, it can be helpful to factor-out the attribute 
> lookup:
> 
> python -m timeit -s 'x=set(range(10000)); y=[]; xu=x.update' 'xu(y)'
> 
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2672>
> __________________________________
> 

Sure, I wasn't surprised at the "set.update(y)" versus "set.update([])"

What I was surprised at is the time for:

"(i for i in [])" being about 4x longer than
"set.update(i for i in [])"

Anyway, the original issue is probably closed, whether we want to track
into the generator stuff or not is probably a different issue.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIEP4EJdeBCYSNAAMRAq+MAKC6tLjEtIBX7YgLNoYEfqjRKB4DzACglXjh
cEVLEP5Hu3vpeVgVYdTbAVc=
=94ja
-----END PGP SIGNATURE-----

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2672>
__________________________________

From report at bugs.python.org  Fri Apr 25 00:14:49 2008
From: report at bugs.python.org (Trent Nelson)
Date: Thu, 24 Apr 2008 22:14:49 +0000
Subject: [issue2686] Any chance we could double the height of the 'Comment:'
	text area on tracker?
In-Reply-To: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>
Message-ID: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>


New submission from Trent Nelson <tnelson at onresolve.com>:

I'd give my left arm for the comment box to be at least double its
current height.  Once you've written more than a paragraph, it becomes a
nuisance having to scroll up and down to re-read what you've written
before typing more.  Quick win?

----------
assignee: loewis
components: None
messages: 65754
nosy: Trent.Nelson, loewis
severity: normal
status: open
title: Any chance we could double the height of the 'Comment:' text area on tracker?
type: feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2686>
__________________________________

From report at bugs.python.org  Fri Apr 25 00:19:06 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Thu, 24 Apr 2008 22:19:06 +0000
Subject: [issue2686] Any chance we could double the height of the 'Comment:'
	text area on tracker?
In-Reply-To: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>
Message-ID: <1209075546.63.0.0555665364139.issue2686@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

+1
But you should file this in the Meta-Tracker; click "Report Tracker
Problem" at the bottom of the left bar.

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2686>
__________________________________

From report at bugs.python.org  Fri Apr 25 02:41:14 2008
From: report at bugs.python.org (Gregory P. Smith)
Date: Fri, 25 Apr 2008 00:41:14 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1209084074.7.0.171080341031.issue2632@psf.upfronthosting.co.za>


Gregory P. Smith <greg at krypto.org> added the comment:

available for an easy side by side review here:

 http://codereview.appspot.com/212

Also, yes I think you're right Ralf.  With these changes I should be
able to return that to a max() within the while True: for sized reads
and things will work as desired.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Fri Apr 25 03:16:37 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:16:37 +0000
Subject: [issue1376292] Write user's version of RefGuide
Message-ID: <1209086197.32.0.93626125301.issue1376292@psf.upfronthosting.co.za>


bob gailer <bgailer at alum.rpi.edu> added the comment:

I find a Reference Manual and a Library Reference. I presume you are
referring to the Reference Manual. True?

I might be interested in helping create the shorter friendlier guide. I
suggest we create some guidelines or specifications for it. This might
be a task for several of us, each taking a section, or some other form
of collaboration.

----------
nosy: +bgailer

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 03:17:26 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:17:26 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <207f01c8a672$13417a80$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

----------
title: Write user's version of RefGuide -> Write user's version of
Added file: http://bugs.python.org/file10090/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/3eaeaf5d/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:17:49 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:17:49 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <208801c8a672$21a9d540$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10091/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/eb0780bd/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:18:18 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:18:18 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <209101c8a672$33bd84c0$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10092/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/df845bbd/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:18:37 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:18:37 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <209a01c8a672$3ea7b540$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10093/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/47f35942/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:19:21 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:19:21 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20a301c8a672$57f7cf80$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10094/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/5c1827f6/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:19:40 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:19:40 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20ac01c8a672$62e22710$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10095/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/32fc52f9/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:20:21 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:20:21 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20b501c8a672$7c219f80$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10096/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/50399644/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:20:45 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:20:45 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20be01c8a672$8aa1c800$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10097/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/c0297247/attachment-0001.txt>

From report at bugs.python.org  Fri Apr 25 03:21:21 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:21:21 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20c701c8a672$a05bea40$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10098/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/8723eaf8/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:21:45 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:21:45 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20d001c8a672$aee317a0$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10099/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/2fe7ae33/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:22:21 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:22:21 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20d901c8a672$c49aeff0$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10100/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/f5741f90/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:22:45 2008
From: report at bugs.python.org (bob gailer)
Date: Fri, 25 Apr 2008 01:22:45 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <20e201c8a672$d31fac50$0165010a@mail2world.com>


bob gailer <bgailer at alum.rpi.edu> added the comment:

My new email address is bgailer at gmail dot com (not google dot com).
Please update your address book, and change the above into the form
user at domain.com. The old address will expire at the end of 2008.

Bob Gailer in Chapel Hill NC.

Added file: http://bugs.python.org/file10101/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/c240cc1e/attachment.txt>

From report at bugs.python.org  Fri Apr 25 03:50:43 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 25 Apr 2008 01:50:43 +0000
Subject: [issue2687] SSL example script fails mysteriously on MacOS
In-Reply-To: <1209088243.37.0.693180003312.issue2687@psf.upfronthosting.co.za>
Message-ID: <1209088243.37.0.693180003312.issue2687@psf.upfronthosting.co.za>


New submission from A.M. Kuchling <lists at amk.ca>:

On my MacOS 10.4.11 machine, the example SSL server and client in the
documentation don't work, and they fail with a mysterious error 0.  The
attached tarball contains my slightly-modified version of the scripts
and the test key/cert I'm using.  

When I run the server, and then the client, the output of the server is:

amk at amk:~/source/p/python$ ./python.exe server.py
Waiting for connection...
Connection received from ('127.0.0.1', 61915)
Traceback (most recent call last):
  File "server.py", line 16, in <module>
    certfile='cert.pem')
  File "/Users/amk/source/p/python/Lib/ssl.py", line 466, in wrap_socket
    ssl_version=ssl_version, ca_certs=ca_certs)
  File "/Users/amk/source/p/python/Lib/ssl.py", line 103, in __init__
    cert_reqs, ssl_version, ca_certs)
ssl.SSLError: [Errno 8] _ssl.c:429: EOF occurred in violation of protocol

And the client is:
amk at amk:~/source/p/python$ ./python.exe client.py
Traceback (most recent call last):
  File "client.py", line 10, in <module>
    ssl_sock.connect(('', 9000))
  File "/Users/amk/source/p/python/Lib/ssl.py", line 204, in connect
    self.ca_certs)
ssl.SSLError: [Errno 0] _ssl.c:327: error:00000000:lib(0):func(0):reason(0)
amk at amk:~/source/p/python$ 

The error 0 is very puzzling.

Perhaps I generated the key and cert incorrectly, and parsing them is
failing in this strange way?

----------
assignee: janssen
components: Extension Modules
files: ssl-example.tgz
messages: 65770
nosy: akuchling, janssen
priority: high
severity: normal
status: open
title: SSL example script fails mysteriously on MacOS
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10102/ssl-example.tgz

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2687>
__________________________________

From report at bugs.python.org  Fri Apr 25 05:39:28 2008
From: report at bugs.python.org (Neal Norwitz)
Date: Fri, 25 Apr 2008 03:39:28 +0000
Subject: [issue1496032] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
In-Reply-To: <1209045662.78.0.287730450606.issue1496032@psf.upfronthosting.co.za>
Message-ID: <ee2a432c0804242039t4f500248habc4d2c3ac3ccbac@mail.gmail.com>


Neal Norwitz <nnorwitz at gmail.com> added the comment:

I think `uname -m` will be equal to "alpha" in this case.  There are
several uses of `uname -m` in configure.in.  You might need to add a
new section.  It might also be possible to clean up various special
cases to make a generic `uname -m` section.  I didn't look too closely
though.

-m is the machine type

BTW, -m works on Tru64.  I also tested on Ubuntu and it reported
x86_64, on Debian it reported sparc.  On OSX.4, it reported "Power
Macintosh".

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1496032>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:48:56 2008
From: report at bugs.python.org (Humberto Diogenes)
Date: Fri, 25 Apr 2008 06:48:56 +0000
Subject: [issue1883] Adapt pydoc to new doc system
In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
Message-ID: <1209106136.46.0.505832466024.issue1883@psf.upfronthosting.co.za>


Humberto Diogenes <humberto at digi.com.br> added the comment:

Amaury, seems that there's duplicated from render_doc inside pydoc.doc. I 
removed it and everything kept working, including the new basic tests.

Added file: http://bugs.python.org/file10103/py3k-pydoc.doc-cleanup.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1883>
__________________________________

From report at bugs.python.org  Fri Apr 25 08:50:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:02 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106202.85.0.856803634972.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:07 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:07 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106207.64.0.917605518339.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:13 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:13 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106213.36.0.0986755202769.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:16 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:16 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106216.42.0.0628001535996.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:22 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106222.04.0.872957066608.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:10 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106210.46.0.254469917.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:28 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106228.99.0.724324826766.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:32 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:32 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106232.23.0.446445366009.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:19 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106219.24.0.872125950899.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:25 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:25 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106225.32.0.524625188099.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:35 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:35 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106235.31.0.3893878128.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:38 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:38 +0000
Subject: [issue1376292] Write user's version of
Message-ID: <1209106238.44.0.785576768041.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:50 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:50 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106250.23.0.0102503934359.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
title: Write user's version of -> Write user's version of the reference guide

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:56 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:56 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106256.08.0.745197905323.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10091/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:57 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106257.94.0.767391692726.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10092/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:01 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:01 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106261.52.0.978476199449.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10094/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:03 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:03 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106263.23.0.806351732442.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10095/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:54 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:54 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106254.2.0.173760460275.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10090/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:09 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:09 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106269.11.0.752406014862.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10098/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:10 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:10 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106270.63.0.677208724061.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10100/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:50:59 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:50:59 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106259.77.0.288461331612.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10093/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:12 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106272.16.0.765522102785.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10101/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:14 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:14 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106274.96.0.978177570269.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10097/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:05 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:05 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106265.19.0.428607067916.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10096/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:06 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:06 +0000
Subject: [issue1376292] Write user's version of the reference guide
Message-ID: <1209106266.8.0.140360816367.issue1376292@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


Removed file: http://bugs.python.org/file10099/unnamed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1376292>
_____________________________________

From report at bugs.python.org  Fri Apr 25 08:51:24 2008
From: report at bugs.python.org (Georg Brandl)
Date: Fri, 25 Apr 2008 06:51:24 +0000
Subject: [issue2686] Any chance we could double the height of the 'Comment:'
	text area on tracker?
In-Reply-To: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>
Message-ID: <1209106284.47.0.125643809426.issue2686@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2686>
__________________________________

From report at bugs.python.org  Fri Apr 25 08:53:25 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 25 Apr 2008 06:53:25 +0000
Subject: [issue2686] Any chance we could double the height of the 'Comment:'
	text area on tracker?
In-Reply-To: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>
Message-ID: <1209106405.27.0.583481883581.issue2686@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Fixed in r62496. Amaury was right - please do use the meta-tracker in
the future for this.

But what should I do with your left arm now :-?

FWIW, Safari users don't need to rely on the HTML page providing them
with enough space - they can increase the input field size by dragging
the lower-right corner of the field.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2686>
__________________________________

From report at bugs.python.org  Fri Apr 25 08:53:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 25 Apr 2008 06:53:31 +0000
Subject: [issue2686] Any chance we could double the height of the 'Comment:'
	text area on tracker?
In-Reply-To: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>
Message-ID: <1209106411.5.0.568761606714.issue2686@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
resolution: invalid -> fixed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2686>
__________________________________

From report at bugs.python.org  Fri Apr 25 11:13:47 2008
From: report at bugs.python.org (Trent Nelson)
Date: Fri, 25 Apr 2008 09:13:47 +0000
Subject: [issue2686] Any chance we could double the height of the 'Comment:'
	text area on tracker?
In-Reply-To: <1209075289.46.0.167133414688.issue2686@psf.upfronthosting.co.za>
Message-ID: <1209114826.85.0.983567767187.issue2686@psf.upfronthosting.co.za>


Trent Nelson <tnelson at onresolve.com> added the comment:

Perhaps you could sell my arm on eBay then forward me the proceeds such 
that I can buy a Mac and use Safari? ;-)

Will use meta tracker herein -- didn't even know that existed.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2686>
__________________________________

From report at bugs.python.org  Fri Apr 25 11:39:39 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 25 Apr 2008 09:39:39 +0000
Subject: [issue2682] cyclic reference in ctypes CFunctionType objects
In-Reply-To: <4810D528.2030504@ctypes.org>
Message-ID: <4811A6D2.9000205@ctypes.org>


Thomas Heller <theller at ctypes.org> added the comment:

>> Can you please elaborate your (apparent) concerns about this patch? IOW,
>> why did you not check it in?
> 
> I have no concerns about the patch, and I am currently committing it.
> I'm uploading so that I can points others to it, and (hopefully) to test
> it before some alpha release.
> 
> It is part of my workflow: I develop a patch, test it locally, upload it
> and eventually commit it sonner or later, sometimes changing things
> depending on feedback I get.

Martin, are there any problems with this approach?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2682>
__________________________________

From report at bugs.python.org  Fri Apr 25 12:27:52 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Fri, 25 Apr 2008 10:27:52 +0000
Subject: [issue2684] Logging Module still failing for %(filename)s, __init__
In-Reply-To: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>
Message-ID: <1209119272.6.0.660947801824.issue2684@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Can you confirm whether this problem occurs even after deleting all .pyc
and .pyo files, including in the Python library folders and your
application folders? Also, which specific platform is this happening on?

On your installation, is the line number 1327 the last line in
logging/__init__.py?

----------
assignee:  -> vsajip
nosy: +vsajip

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2684>
__________________________________

From report at bugs.python.org  Fri Apr 25 12:53:55 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Fri, 25 Apr 2008 10:53:55 +0000
Subject: [issue433030] SRE: Atomic Grouping (?>...) is not supported
Message-ID: <1209120835.47.0.0899092592198.issue433030@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Quick update (see thread 2636 for other updates to the Regex
functionality): I do have a design in my mind for how to accomplish both
Atomic Grouping and Possessive Qualifiers and it would work with either
the existing Engine design or the new design I have been playing with. 
It's just a matter of getting around to implementing it, testing it and
documenting it.

I currently am having problem with Bazaar / Launchpad which are beyond
the scope of this issue but are effecting my work.  Those issues can be
found on the Launchpad site if you look for Answers / Bugs originating
from "timehorse".

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue433030>
____________________________________

From report at bugs.python.org  Fri Apr 25 14:10:59 2008
From: report at bugs.python.org (Robert Greimel)
Date: Fri, 25 Apr 2008 12:10:59 +0000
Subject: [issue2688] Error when nesting many while loops
In-Reply-To: <1209125459.31.0.611110117308.issue2688@psf.upfronthosting.co.za>
Message-ID: <1209125459.31.0.611110117308.issue2688@psf.upfronthosting.co.za>


New submission from Robert Greimel <rgreimel at gmail.com>:

nesting 20 while loops works OK.
The 21st leads to the cryptic error message

python: Python/compile.c:295: PyAST_Compile: Assertion `co ||
PyErr_Occurred()' failed.
Abort

when trying to execute the script.

----------
components: None
messages: 65778
nosy: rgreimel
severity: normal
status: open
title: Error when nesting many while loops
type: compile error
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2688>
__________________________________

From report at bugs.python.org  Fri Apr 25 14:43:56 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Fri, 25 Apr 2008 12:43:56 +0000
Subject: [issue2688] Error when nesting many while loops
In-Reply-To: <1209125459.31.0.611110117308.issue2688@psf.upfronthosting.co.za>
Message-ID: <1209127436.56.0.958298357956.issue2688@psf.upfronthosting.co.za>


Guilherme Polo <ggpolo at gmail.com> added the comment:

Apparently this was fixed at rev 52504 python-trunk. 
Which python version did you use ?

----------
nosy: +gpolo

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2688>
__________________________________

From report at bugs.python.org  Fri Apr 25 15:04:17 2008
From: report at bugs.python.org (Robert Greimel)
Date: Fri, 25 Apr 2008 13:04:17 +0000
Subject: [issue2688] Error when nesting many while loops
In-Reply-To: <1209125459.31.0.611110117308.issue2688@psf.upfronthosting.co.za>
Message-ID: <1209128657.01.0.534159662844.issue2688@psf.upfronthosting.co.za>


Robert Greimel <rgreimel at gmail.com> added the comment:

Python 2.5 (r25:51908, Nov  6 2007, 15:55:44) 

from Fedora 7 (python-2.5-15.fc7)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2688>
__________________________________

From report at bugs.python.org  Fri Apr 25 15:21:22 2008
From: report at bugs.python.org (Ronald Oussoren)
Date: Fri, 25 Apr 2008 13:21:22 +0000
Subject: [issue2573] Can't change the framework name on OS X builds
In-Reply-To: <1207597645.11.0.369783030372.issue2573@psf.upfronthosting.co.za>
Message-ID: <1209129682.74.0.801198305284.issue2573@psf.upfronthosting.co.za>


Ronald Oussoren <ronaldoussoren at mac.com> added the comment:

The new patch looks great. I'll apply it next week.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2573>
__________________________________

From report at bugs.python.org  Fri Apr 25 15:58:00 2008
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 25 Apr 2008 13:58:00 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1209131880.82.0.291704084293.issue2622@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

AFA I understand it the ImportError comes when running a py2exe/app'ed
package where iterators.py hasn't been included.

I was just about to file a report about (I think) the same issue, seen
on XP when py2exe'ing code using the email module.

Exactly the same problem with a good(?) explanation can be found on
http://mail.python.org/pipermail/spambayes/2007-December/021485.html

The problem comes because the real module names now are lowercase, and
email/__init__.py plays tricks with _LOWERNAMES in order to keep the old
uppercase names working. The problem is that the email lib itself uses
the old (deprecated?) non-existing name.

IMHO the solution is to use right-cased names. I have (only) tested it
by changing the single reference to email.Iterators. I think this is a
safe bugfix which should be included in 2.5 ASAP.

A workaround is to import email.iterators from some other code or to
tell py2exe/pyapp explicitly include the modules in the package.

----------
nosy: +kiilerix

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Fri Apr 25 16:08:37 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 14:08:37 +0000
Subject: [issue2689] Fix indentation in range_item
Message-ID: <1209132516.74.0.59293636973.issue2689@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
components: Interpreter Core
files: range.diff
keywords: patch
nosy: belopolsky
severity: normal
status: open
title: Fix indentation in range_item
versions: Python 3.0
Added file: http://bugs.python.org/file10104/range.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2689>
__________________________________

From report at bugs.python.org  Fri Apr 25 16:16:57 2008
From: report at bugs.python.org (Paul Winkler)
Date: Fri, 25 Apr 2008 14:16:57 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209133017.5.0.909185534323.issue1180@psf.upfronthosting.co.za>


Paul Winkler <pw_lists at slinkp.com> added the comment:

Here's an alternate patch that uses a bit of dependency injection to
avoid the need for monkeypatches in setup/teardown. This means some
trivial changes to Distribution.__init__().  I slightly prefer this
approach, but some might argue it's an example of "test logic in
production".

I also added a line about the new option in Doc/install/index.rst.

Since I don't have checkin privileges, I will stop here. Can somebody
upstream (Martin?) please take one of these patches and apply it? Or
suggest further changes to either of these patches?  Or ... ?
Thanks.

Added file: http://bugs.python.org/file10105/python_distutils_1180_2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Fri Apr 25 16:44:40 2008
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 25 Apr 2008 14:44:40 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1209134680.59.0.727704049837.issue2622@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

This patch seems to fix the issue for me.

The easiest way to verify might be to create another patch and compare
them...

----------
keywords: +patch
Added file: http://bugs.python.org/file10106/emailcasings.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Fri Apr 25 17:30:19 2008
From: report at bugs.python.org (Barry A. Warsaw)
Date: Fri, 25 Apr 2008 15:30:19 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1209134680.59.0.727704049837.issue2622@psf.upfronthosting.co.za>
Message-ID: <B2A87CEF-630E-488D-B52D-D657B02912FA@python.org>


Barry A. Warsaw <barry at python.org> added the comment:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Apr 25, 2008, at 10:44 AM, Mads Kiilerich wrote:

>
> Mads Kiilerich <mads at kiilerich.com> added the comment:
>
> This patch seems to fix the issue for me.
>
> The easiest way to verify might be to create another patch and compare
> them...

The patch looks pretty good, +1.  The only part I'm not so sure about  
is the renaming in test_email.py since test_email_renamed.py is  
supposed to use the new names while test_email.py (in 2.5 at least) is  
supposed to test the backward compatible names.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iQCVAwUBSBH5BnEjvBPtnXfVAQJJNAP/VEIyMvObRz9SH5EL4Tu4KuVay5C/vvxC
AvlfRrmCNJXXRdU2ZfmiSG357Zc3JfRLhxZBSVpuMQidictxUZttcnqoFlwS2Edu
VwXWtihGjMncn4qdR2IlwEUitG6eSJlrsbo+RtaDSFXlWNyzA83O3mBffeIn8vYn
FLILF8aVaQQ=
=nxt/
-----END PGP SIGNATURE-----

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Fri Apr 25 17:32:02 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 15:32:02 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch makes range objects precompute their length on creation.  
This speeds up indexing and len at the expense of a small increase in 
range object size.  The main benefit, however is that unsupported length > 
sys.maxsize is detected early and confusing OverflowError from len(r) or 
r[i] is avoided.

See discussion starting at http://mail.python.org/pipermail/python-
3000/2008-April/013225.html .

----------
components: Interpreter Core
files: range-length.diff
keywords: patch
messages: 65786
nosy: belopolsky
severity: normal
status: open
title: Precompute range length
type: performance
versions: Python 3.0
Added file: http://bugs.python.org/file10107/range-length.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 17:46:06 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 25 Apr 2008 15:46:06 +0000
Subject: [issue2655] Create ctypes instances from buffer interface
In-Reply-To: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>
Message-ID: <1209138366.85.0.808224166657.issue2655@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Implemented from_buffer() and from_buffer_copy() as rev 62497 to SVN trunk.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2655>
__________________________________

From report at bugs.python.org  Fri Apr 25 17:46:11 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 25 Apr 2008 15:46:11 +0000
Subject: [issue2655] Create ctypes instances from buffer interface
In-Reply-To: <1208543464.32.0.977343399155.issue2655@psf.upfronthosting.co.za>
Message-ID: <1209138371.1.0.546101070363.issue2655@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


Removed file: http://bugs.python.org/file10057/from_buffer.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2655>
__________________________________

From report at bugs.python.org  Fri Apr 25 18:03:10 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 16:03:10 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

Attached patch adds documentation for the new in 2.5 APIs:

PyObject* PyLong_FromSsize_t(Py_ssize_t v)
PyObject* PyLong_FromSize_t(size_t v)

and

Py_ssize_t PyLong_AsSsize_t(PyObject *pylong)

----------
assignee: georg.brandl
components: Documentation
messages: 65788
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: Document size_t related long object APIs
versions: Python 2.5, Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________

From report at bugs.python.org  Fri Apr 25 18:03:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 16:03:24 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209139404.49.0.59688913583.issue2691@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________

From report at bugs.python.org  Fri Apr 25 18:04:37 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 16:04:37 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209139476.92.0.401380338735.issue2691@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

-

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________

From report at bugs.python.org  Fri Apr 25 18:05:36 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 16:05:36 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209139536.22.0.547045967493.issue2691@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________

From report at bugs.python.org  Fri Apr 25 18:10:39 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 16:10:39 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139698.07.0.876163562778.issue2691@psf.upfronthosting.co.za>
Message-ID: <d38f5330804250910x53c01e84jc12ce59f946e2369@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Web submission did not work.  Trying sending the patch as an e-mail attachment.

----------
keywords: +patch
Added file: http://bugs.python.org/file10108/doc-long.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: doc-long.diff
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080425/62323b84/attachment.txt>

From report at bugs.python.org  Fri Apr 25 18:17:31 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Apr 2008 16:17:31 +0000
Subject: [issue1496032] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Message-ID: <1209140251.8.0.199200201025.issue1496032@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Okay---I've added -mieee to BASECFLAGS in r62499, when uname -m reports 
alpha* and when gcc is the compiler;  I've also added a configure message 
that simply reports the output of uname -m, to aid debugging in case 
anything funny happens.

With luck, this should fix the problems reported by Bob Ippolito, as well 
as the current test_math and test_cmath failures.

Bob, if you're still listening, are you in a position to check whether 
this change fixes the failures you reported?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1496032>
_____________________________________

From report at bugs.python.org  Fri Apr 25 18:08:18 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 16:08:18 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209139698.07.0.876163562778.issue2691@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

For some reason the tracker web interface fails to upload the patch.  
Trying again with this message, if it fails again, will resubmit by e-
mail.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________

From report at bugs.python.org  Fri Apr 25 18:55:20 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Apr 2008 16:55:20 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209142520.32.0.6963312679.issue2690@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

So with this patch, range(10**100) produces an OverflowError:  is that 
right?

I don't much like this aspect of the change:   there are uses for

for i in range(ridiculously_large_number):
   ...
   if condition_that_occurs_early_in_practice:
       break

----------
nosy: +marketdickinson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 18:59:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Apr 2008 16:59:47 +0000
Subject: [issue2635] textwrap: bug in 'fix_sentence_endings' option
In-Reply-To: <1208238885.76.0.507566596531.issue2635@psf.upfronthosting.co.za>
Message-ID: <1209142787.52.0.0741688180476.issue2635@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Fixed for Python 2.6 in r62500.  Thanks for the report!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2635>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:00:02 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Apr 2008 17:00:02 +0000
Subject: [issue2635] textwrap: bug in 'fix_sentence_endings' option
In-Reply-To: <1208238885.76.0.507566596531.issue2635@psf.upfronthosting.co.za>
Message-ID: <1209142802.04.0.412324709504.issue2635@psf.upfronthosting.co.za>


Changes by Mark Dickinson <dickinsm at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2635>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:04:18 2008
From: report at bugs.python.org (Mads Kiilerich)
Date: Fri, 25 Apr 2008 17:04:18 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1209143058.81.0.758768207755.issue2622@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

OK. I had assumed that backward compatibility was tested in the _renamed
tests, so that these tests one day could be dropped together with
backward compatibility. I didn't notice that my search'n'replaces showed
me that I was wrong.

But a bugfix in a stable release really shouldn't change any tests
unless the tests are wrong. And I can't come up with a reasonable new
test. It could perhaps be tested that all modules could be py2exe'ed and
imported individually with automatic dependency resolving... But such a
test doesn't belong in the test suite.

I suggest that my patch is applied without the test cleanup.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:14:49 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 25 Apr 2008 17:14:49 +0000
Subject: [issue2692] bytes object wrongly exposes writeable buffer interface
In-Reply-To: <1209143688.91.0.550204497514.issue2692@psf.upfronthosting.co.za>
Message-ID: <1209143688.91.0.550204497514.issue2692@psf.upfronthosting.co.za>


New submission from Thomas Heller <theller at ctypes.org>:

IIUC, the bytes object should be immutable (in contrast to bytearray). 
But PyObject_FromWriteBuffer() does not fail.

It seems that the attached patch fixes it; however there are lots of
failures in the testsuite with the patch - even 'memoryview(b"abcd")' fails.

Index: stringobject.c
===================================================================
--- stringobject.c	(revision 62498)
+++ stringobject.c	(working copy)
@@ -966,7 +966,7 @@
 string_buffer_getbuffer(PyStringObject *self, Py_buffer *view, int flags)
 {
 	return PyBuffer_FillInfo(view, (void *)self->ob_sval, Py_SIZE(self),
-				 0, flags);
+				 1, flags);
 }
 
 static PySequenceMethods string_as_sequence = {

----------
components: Interpreter Core
messages: 65796
nosy: theller
severity: normal
status: open
title: bytes object wrongly exposes writeable buffer interface
versions: Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2692>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:23:27 2008
From: report at bugs.python.org (Bill Janssen)
Date: Fri, 25 Apr 2008 17:23:27 +0000
Subject: [issue2687] SSL example script fails mysteriously on MacOS
In-Reply-To: <1209088243.37.0.693180003312.issue2687@psf.upfronthosting.co.za>
Message-ID: <1209144207.57.0.965211656555.issue2687@psf.upfronthosting.co.za>


Bill Janssen <bill.janssen at gmail.com> added the comment:

No, the problem is with your "ca_certs" argument on the client side. 
You can't use a directory.  You must use a file containing a number of
concatenated certificates.  I'll beef up the documentation to make that
clearer.

----------
resolution:  -> wont fix
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2687>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:32:08 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 17:32:08 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209142520.32.0.6963312679.issue2690@psf.upfronthosting.co.za>
Message-ID: <d38f5330804251032tae9c886s9b0abb3de9b73b95@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 25, 2008 at 12:55 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
>  I don't much like this aspect of the change:   there are uses for
>
>  for i in range(ridiculously_large_number):

For this application, I would use "for i in itertools.count():"
instead.  The only caveat is that while count() lets you specify the
start, it does not provide for a step.   If that is a problem, I would
rather add step to count().

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:33:43 2008
From: report at bugs.python.org (Bob Kline)
Date: Fri, 25 Apr 2008 17:33:43 +0000
Subject: [issue2480] pickling of large recursive structures fails
In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
Message-ID: <1209144823.28.0.499711962133.issue2480@psf.upfronthosting.co.za>


Bob Kline <bkline at users.sourceforge.net> added the comment:

I just ran into this behavior with an attempt to pickle a dom tree for
an XML document whose nesting level never got deeper than nine child
nodes, and indeed it crashed the interpreter.  Throwing an exception
would be preferable, of course, to silent blowing up Python, but even
the exception seems to fly in the face of the documentation for the
pickle module [1] which claims (summarizing) that serializing recursive
objects using marshal will fail but pickling recursive objects will not
fail.  I can provide a repro for the XML/DOM pickling case if you think
that would be helpful, but that seems redundant since essentially you've
already illustrated the problem with your own repro case.  Thanks for
your work on the solution.

[1] http://docs.python.org/lib/node314.html

----------
nosy: +bkline
type:  -> crash

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2480>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:38:00 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Apr 2008 17:38:00 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1209145080.63.0.132363469969.issue2622@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> But such a test doesn't belong in the test suite.

py2exe uses the "modulefinder" module to find dependencies.

I tried this command::

    ./python -m modulefinder Lib\email\message.py

And among the output, there is::

    ....
    ? email.Generator imported from __main__, email.message
    ? email.Iterators imported from __main__, email.message
    ....

It surely can be turned into a unit test. For example::

    import email.message
    filename = email.message.__file__
    if filename.endswith(".pyc"):
        filename = filename[:-1]

    import modulefinder
    mf=modulefinder.ModuleFinder()
    mf.run_script(filename)
    assert "email.Generator" not in mf.any_missing()

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Fri Apr 25 19:48:08 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 25 Apr 2008 17:48:08 +0000
Subject: [issue2682] cyclic reference in ctypes CFunctionType objects
In-Reply-To: <4811A6D2.9000205@ctypes.org>
Message-ID: <48121955.3050006@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Martin, are there any problems with this approach?

No, it's fine. I was just puzzled.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2682>
__________________________________

From report at bugs.python.org  Fri Apr 25 20:08:36 2008
From: report at bugs.python.org (A.M. Kuchling)
Date: Fri, 25 Apr 2008 18:08:36 +0000
Subject: [issue2657] Curses sometimes fails to initialize terminal
In-Reply-To: <1208559068.96.0.196247088071.issue2657@psf.upfronthosting.co.za>
Message-ID: <1209146915.95.0.419726531511.issue2657@psf.upfronthosting.co.za>


Changes by A.M. Kuchling <lists at amk.ca>:


----------
assignee:  -> akuchling
nosy: +akuchling
title: curses -> Curses sometimes fails to initialize terminal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2657>
__________________________________

From report at bugs.python.org  Fri Apr 25 20:48:02 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Apr 2008 18:48:02 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209149282.65.0.442237787445.issue2690@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

I guess there needs to be a decision on whether to make range objects of 
length >= PY_SSIZE_T_MAX illegal; perhaps more discussion on python-dev 
would be worthwhile?

I can see three options, besides leaving things as they are:

(1) make large ranges illegal, as with this patch
(2) make large ranges legal, but don't allow indexing with indices
larger than PY_SSIZE_T_MAX.
(3) allow large ranges *and* large indices.

Option 3 seems to me like the ideal from the users' point of view, but I'm 
not sure whether it's easy/possible to implement it given that sq_item 
receives a Py_ssize_t for the index.

Option 2 seems messy:  half of one thing and half of the other, but I 
think it would be easy to implement.  This is what I'd personally prefer 
if Option 3 isn't feasible.

If Option 1 is indeed the preferred option, then the patch looks good to 
me, and works for me on OS X 10.5.  (Minor nitpick: it introduces some 
extra tab characters.)

Whatever happens, we probably also need a documentation update explaining 
the limitations on range.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 21:24:02 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 19:24:02 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209151442.37.0.142582679455.issue2690@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Option (3) would require changing both sq_item and sq_length signatures,
which is likely to have a large negative impact on performance.

Option (2) would either require a change for the sq_length signature, or
leave the problem of having valid range objects for which applying len()
would produce an OverflowError.

What are the use cases for ranges with length greater than maxsize? Note
that in 2.x all arguments to length are limited to 32 bit integers (even
on 64-bit platforms) and the main reason to support long start/stop/step
in 3.0  is because 2.x range() supports them.  On the other hand, since
2.x range() produces lists, it is limited in length to a fraction of
sys.maxsize.  Therefore none of the current uses of either range or
xrange require support of long length.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 21:37:23 2008
From: report at bugs.python.org (Wummel)
Date: Fri, 25 Apr 2008 19:37:23 +0000
Subject: [issue1158909] unpack error in getdefaultlocale() on certain locales
Message-ID: <1209152243.67.0.658492721067.issue1158909@psf.upfronthosting.co.za>


Wummel <calvin at users.sourceforge.net> added the comment:

This bug is fixed. The fix has been checked in by Georg Brandl on
20.1.2006 here:
http://svn.python.org/view/python/trunk/Lib/locale.py?rev=42100&r1=39572&r2=42100

So this bug has been fixed in Python 2.5 all along. Why did I have this
error then? Perhaps I tested with 2.4 back then. Anyway, I think this
bug can be closed.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1158909>
_____________________________________

From report at bugs.python.org  Fri Apr 25 21:42:41 2008
From: report at bugs.python.org (John J Lee)
Date: Fri, 25 Apr 2008 19:42:41 +0000
Subject: [issue2451] No way to disable socket timeouts in httplib, etc.
In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za>
Message-ID: <1209152561.22.0.742464208663.issue2451@psf.upfronthosting.co.za>


John J Lee <jjlee at users.sourceforge.net> added the comment:

Facundo, are you going to review this?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2451>
__________________________________

From report at bugs.python.org  Fri Apr 25 21:56:04 2008
From: report at bugs.python.org (Thomas Heller)
Date: Fri, 25 Apr 2008 19:56:04 +0000
Subject: [issue2682] cyclic reference in ctypes CFunctionType objects
In-Reply-To: <1209060430.76.0.330100057141.issue2682@psf.upfronthosting.co.za>
Message-ID: <1209153364.43.0.136615402636.issue2682@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Also fixed in release25-maint, rev 62504.

----------
resolution: accepted -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2682>
__________________________________

From report at bugs.python.org  Fri Apr 25 21:57:03 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Apr 2008 19:57:03 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209153423.63.0.27099972841.issue2690@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

I am currently working on a patch that allows large ranges and large
indices. The trick is to define tp_as_mapping->mp_subscript.
Then range_item() is rarely used, only by functions calling directly the
PySequence_* functions, instead of the abstract PyObject_*.

There is still a limit with len(), which seems bound by the size_t limit.
Most of the tests in test_builtin were re-enabled.

I join the current version of the patch.
I'm still working on further simplifications, and maybe supporting
slices on ranges...

Note: I found more useful to store a "range->end" member, which is the
multiple of "step" just beyond the "stop" limit.

----------
nosy: +amaury.forgeotdarc
Added file: http://bugs.python.org/file10109/anyrange.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 22:29:08 2008
From: report at bugs.python.org (Facundo Batista)
Date: Fri, 25 Apr 2008 20:29:08 +0000
Subject: [issue2451] No way to disable socket timeouts in httplib, etc.
In-Reply-To: <1206141378.11.0.857343736887.issue2451@psf.upfronthosting.co.za>
Message-ID: <1209155347.96.0.657293151168.issue2451@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Yes! :)

----------
assignee:  -> facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2451>
__________________________________

From report at bugs.python.org  Fri Apr 25 22:33:39 2008
From: report at bugs.python.org (Charles Merriam)
Date: Fri, 25 Apr 2008 20:33:39 +0000
Subject: [issue2684] Logging Module still failing for %(filename)s, __init__
In-Reply-To: <1209119272.6.0.660947801824.issue2684@psf.upfronthosting.co.za>
Message-ID: <b8c6f6c40804251333v5fe860e5i1903ef8c6e5de6f6@mail.gmail.com>


Charles Merriam <charles.merriam at gmail.com> added the comment:

In my installation, line 1327 is within the logging.debug()  function,
specifically at the
call to  apply(root.debug, (msg,)+args, kwargs)

chasm at chasm-laptop:~/py$ rm *.pyc
chasm at chasm-laptop:~/py$ python x.py
DEBUG:logging/__init__.py:1327:Hello
chasm at chasm-laptop:~/py$ uname -a
Linux chasm-laptop 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC
2008 i686 GNU/Linux
chasm at chasm-laptop:~/py$ python -V
Python 2.5.1

-and then-
chasm at chasm-laptop:/usr/lib/python2.5$ sudo rm -rf *.pyc *.pyo */*.pyc
*/*.pyo */*/*.pyc */*/*.pyo
chasm at chasm-laptop:/usr/lib/python2.5$ cd ~/py
chasm at chasm-laptop:~/py$ python x.py
DEBUG:x.py:7:Hello
chasm at chasm-laptop:~/py$

So it was somewhere in the library brunches.  The uname -a translates
to "Kbuntu Gutsy".  Python, and extras like pylint, coverage, and
nose, were installed via Kbuntu's package manager.

-- Charles

On Fri, Apr 25, 2008 at 3:27 AM, Vinay Sajip <report at bugs.python.org> wrote:
>
>  Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:
>
>  Can you confirm whether this problem occurs even after deleting all .pyc
>  and .pyo files, including in the Python library folders and your
>  application folders? Also, which specific platform is this happening on?
>
>  On your installation, is the line number 1327 the last line in
>  logging/__init__.py?
>
>  ----------
>  assignee:  -> vsajip
>  nosy: +vsajip
>
>
>
>  __________________________________
>  Tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue2684>
>  __________________________________
>

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2684>
__________________________________

From report at bugs.python.org  Fri Apr 25 22:37:36 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Apr 2008 20:37:36 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209155856.65.0.228224379393.issue2690@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> What are the use cases for ranges with length greater than maxsize?

Yeah---I'm a bit short on use cases.  The one that originally bit me with 
Python 2.x was when I was doing a search for a quadratic non-residue 
modulo a largeish prime;

for i in range(1, p):
    if (i_is_a_nonresidue_modulo_p):
        break

Here p might be a 200-digit prime number, and the situation is that half 
the integers between 1 and p-1 are 'quadratic residues', while the other 
half are 'quadratic nonresidues';  in practice the residues and 
nonresidues are mixed up fairly well, so the first nonresidue shows up 
pretty quickly, but there's no known small upper bound on when the first 
nonresidue appears.

Of course, it's not hard to rewrite this with a while loop instead;  it 
would just be a bit annoying if that were necessary, when the code above 
is so clear and direct, and the one obvious way to do it (TM).

I'd also note that it's not completely out of the question that something 
like range(10**10) would be useful on a 32-bit machine:  a long-running 
process might easily go through 10**10 iterations of something.

I agree it's a bit strange to have a semi-functional range object, that 
you can iterate over but not take the length of.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 22:37:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 20:37:56 +0000
Subject: [issue2689] Fix indentation in range_item
In-Reply-To: <1209155876.25.0.832408332215.issue2689@psf.upfronthosting.co.za>
Message-ID: <1209155876.25.0.832408332215.issue2689@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

I don't really see what's wrong with the indentation.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2689>
__________________________________

From report at bugs.python.org  Fri Apr 25 22:40:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 20:40:12 +0000
Subject: [issue1158909] unpack error in getdefaultlocale() on certain locales
Message-ID: <1209156012.37.0.905275305004.issue1158909@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
resolution:  -> fixed
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1158909>
_____________________________________

From report at bugs.python.org  Fri Apr 25 22:45:45 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 20:45:45 +0000
Subject: [issue2692] bytes object wrongly exposes writeable buffer interface
In-Reply-To: <1209143688.91.0.550204497514.issue2692@psf.upfronthosting.co.za>
Message-ID: <1209156345.36.0.0699765684161.issue2692@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2692>
__________________________________

From report at bugs.python.org  Fri Apr 25 22:57:45 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 20:57:45 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209155856.65.0.228224379393.issue2690@psf.upfronthosting.co.za>
Message-ID: <d38f5330804251357h10b226e7mbade6fc6661fab73@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 25, 2008 at 4:37 PM, Mark Dickinson <report at bugs.python.org> wrote:
..
>  for i in range(1, p):
>     if (i_is_a_nonresidue_modulo_p):
>         break
>
>  Here p might be a 200-digit prime number, and the situation is that half
>  the integers between 1 and p-1 are 'quadratic residues', while the other
>  half are 'quadratic nonresidues';  in practice the residues and
>  nonresidues are mixed up fairly well, so the first nonresidue shows up
>  pretty quickly, but there's no known small upper bound on when the first
>  nonresidue appears.

Hmm, AFAIKT there is always at least one non-residue between 1 and p
and therefore you can just write

for i in itertools.count(1):
    if (i_is_a_nonresidue_modulo_p):
         break

maybe with an additional check for p > 1.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Fri Apr 25 23:08:33 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 21:08:33 +0000
Subject: [issue2689] Fix indentation in range_item
In-Reply-To: <1209155876.25.0.832408332215.issue2689@psf.upfronthosting.co.za>
Message-ID: <d38f5330804251408m7efb61d1qe7fad3352f2505a@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 25, 2008 at 4:37 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
>  I don't really see what's wrong with the indentation.

Sorry, I thought it would be obvious from the patch. As of revision
62505, Objects/rangeobject.c:216 has the following code:

216    if (i < 0 || i >= len) {
217        if (!PyErr_Occurred())
218            PyErr_SetString(PyExc_IndexError,
219                            "range object index out of range");
220            return NULL;
221        }

Note that the inner if has no { after the condition and therefore
terminates at line 219.  Thus the next line should be aligned with the
inner if and  the } at line 221 should be aligned with the outer if.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2689>
__________________________________

From report at bugs.python.org  Fri Apr 25 23:15:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 21:15:40 +0000
Subject: [issue2689] Fix indentation in range_item
In-Reply-To: <1209155876.25.0.832408332215.issue2689@psf.upfronthosting.co.za>
Message-ID: <1209158140.14.0.221964455381.issue2689@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Ok. I see now. Fixed in r62506.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2689>
__________________________________

From report at bugs.python.org  Fri Apr 25 23:31:04 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 21:31:04 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209159064.22.0.923091710263.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Comments?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Fri Apr 25 23:32:12 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 21:32:12 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209159132.39.0.176925792708.issue2691@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
type:  -> feature request
versions:  -Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________

From report at bugs.python.org  Fri Apr 25 23:57:49 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Fri, 25 Apr 2008 21:57:49 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209160668.96.0.077281338739.issue2603@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

about range_eq7.patch:

- Did you change your mind about range equality?
  range(0,10,2) == range(0,9,2)
seems True now; it was not with range_eq6.patch

- The hash function will fail with big values (and wrongly returns a
value even when an exception is set). I suggest to call PyObject_Hash
instead of PyNumber_AsSsize_t.

- Now that you short-circuit the comparison, it is enough to have only
one boolean variable (is_equal), which may replace all uses of
start_same, stop_same and step_same.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Fri Apr 25 23:59:40 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 21:59:40 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1209159064.22.0.923091710263.issue2603@psf.upfronthosting.co.za>
Message-ID: <d38f5330804251459j18c0241o10068e353026725f@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 25, 2008 at 5:31 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>  Comments?

In the range_hash function, len, start, step locals should be declared
Py_ssize_t, not long. Also, you can use range_length() instead of
PyObject_Size() and you need to clear error if you get len == -1.

See issue2690. With your patch,

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

but

True

You can avoid this problem by using range_length_obj instead of
PyObject_Size in range_richcompare.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 00:04:21 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 22:04:21 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209161061.19.0.638923833019.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

It looks like e-mail processor eats '>>>' examples.  My examples were

>>> range(2**100) == range(2**100+1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: Python int too large to convert to C ssize_t

and

>>> range(2**100) == range(2**100)
True

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 00:12:24 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 22:12:24 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1209160668.96.0.077281338739.issue2603@psf.upfronthosting.co.za>
Message-ID: <d38f5330804251512s3b8861cfs3bdc76b856db8765@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 25, 2008 at 5:57 PM, Amaury Forgeot d'Arc
<report at bugs.python.org> wrote:
..
>  - Did you change your mind about range equality?
>   range(0,10,2) == range(0,9,2)
>  seems True now; it was not with range_eq6.patch
>

This makes me think: what would you say to an idea to normalize ranges
in constructor so that range(5,10,2) returns range(5,11,2).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 00:20:39 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Fri, 25 Apr 2008 22:20:39 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209162039.09.0.549505770041.issue2677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

I consider the difference between builtin and def'ed functions to be
something of an implementation wart -- one that I would like to see
someday removed if sensibly possible.  How is a beginner to know that
the parameter names used in the docs and help() responses are not really
parameter names?

In the meanwhile, I think something like the following in the doc would
help: "(Note: an implementation may provide builtin functions whose
positional parameters do not have names, even if they are 'named' for
the purpose of documentation, and which therefore cannot be supplied by
keyword.)"

Also in the meanwhile, the OP can def-wrap builtins
import builtins
def abs(number): return builtins.abs(number)
# but some like int require more care with its no-default option

----------
nosy: +tjreedy

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Sat Apr 26 00:36:50 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 22:36:50 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209163010.69.0.702141445677.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Thanks for the help.

Yes, after thinking for a while, I decided that range equality should
represent the set of integers and not the values in the constructor.
Normalization would be a good idea, but I think that's another issue
I'll tackle after this.

Now you get an error for hashing a huge range.

Added file: http://bugs.python.org/file10110/range_eq8.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 00:38:40 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Apr 2008 22:38:40 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1209163010.69.0.702141445677.issue2603@psf.upfronthosting.co.za>
Message-ID: <ca471dc20804251538t7bde42at2ddb5d1b653668f2@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Fri, Apr 25, 2008 at 3:36 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>
>  Benjamin Peterson <musiccomposition at gmail.com> added the comment:
>
>  Thanks for the help.
>
>  Yes, after thinking for a while, I decided that range equality should
>  represent the set of integers and not the values in the constructor.
>  Normalization would be a good idea, but I think that's another issue
>  I'll tackle after this.

The two go hand-in-hand; you shouldn't have two range() objects that
compare equal and yet have different stop attribute values.

>  Now you get an error for hashing a huge range.
>
>  Added file: http://bugs.python.org/file10110/range_eq8.patch
>
>
>
>  __________________________________
>  Tracker <report at bugs.python.org>
>  <http://bugs.python.org/issue2603>
>  __________________________________
>

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 00:41:01 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 22:41:01 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <ca471dc20804251538t7bde42at2ddb5d1b653668f2@mail.gmail.com>
Message-ID: <1afaf6160804251540j51b21b58od9091786fa2d0789@mail.gmail.com>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

On Fri, Apr 25, 2008 at 5:38 PM, Guido van Rossum
<report at bugs.python.org> wrote:
>
>  Guido van Rossum <guido at python.org> added the comment:
>  The two go hand-in-hand; you shouldn't have two range() objects that
>  compare equal and yet have different stop attribute values.

If it makes any difference, the attributes aren't even available through Python.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 01:10:38 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Fri, 25 Apr 2008 23:10:38 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1afaf6160804251540j51b21b58od9091786fa2d0789@mail.gmail.com>
Message-ID: <ca471dc20804251610u23925ae3kc641071ce5e66233@mail.gmail.com>


Guido van Rossum <guido at python.org> added the comment:

On Fri, Apr 25, 2008 at 3:41 PM, Benjamin Peterson
<report at bugs.python.org> wrote:
>  If it makes any difference, the attributes aren't even available through Python.

But they are deducible via the str() or repr(). And IMO they *should*
be available.

I think I'd be okay with normalization on creation, so that range(0,
5, 2) returns range(0, 6, 2). Hm, but isn't that odd? Why not the
other way around?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 01:16:44 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Fri, 25 Apr 2008 23:16:44 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209165404.62.0.512734332356.issue2690@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

> Hmm, AFAIKT there is always at least one non-residue between 1 and p
> and therefore you can just write
>
> for i in itertools.count(1):
>     if (i_is_a_nonresidue_modulo_p):
>          break
>
> maybe with an additional check for p > 1.

Sure.  It's just uglier that way. :-)  And I feel it would be mildly 
annoying not to be able to use the obvious tool for the job, for subtle 
reasons.  It's also a potential source of bugs: one might write such code 
using range and only discover later that it fails unexpectedly for large 
inputs.

These really aren't serious objections---just mild preferences.  I'll stop 
being disruptive now :)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Sat Apr 26 01:24:34 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 23:24:34 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209165873.97.0.165451135303.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a normalizing patch. It breaks the repr tests because the numbers
change.

Added file: http://bugs.python.org/file10111/range_eq8_normalize.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 01:35:13 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Fri, 25 Apr 2008 23:35:13 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <ca471dc20804251610u23925ae3kc641071ce5e66233@mail.gmail.com>
Message-ID: <d38f5330804251635t56320317od85718a09a66e48c@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Fri, Apr 25, 2008 at 7:10 PM, Guido van Rossum
<report at bugs.python.org> wrote:
..
>  I think I'd be okay with normalization on creation, so that range(0,
>  5, 2) returns range(0, 6, 2). Hm, but isn't that odd? Why not the
>  other way around?

I find it natural to have start + len*step  = stop invariant rather
than start +(len-1)*step + 1 = stop.  I may be influenced by C++ (STL)
tradition of giving preference to "i != stop" over "i < stop"
condition so that algorithms support iterators that are not ordered.
I also believe some algorithmic simplifications will be possible with
 start + len*step  = stop invariant.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 01:36:27 2008
From: report at bugs.python.org (Greg Couch)
Date: Fri, 25 Apr 2008 23:36:27 +0000
Subject: [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>
Message-ID: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>


New submission from Greg Couch <gregcouch at gmail.com>:

IDLE and Tk 8.5 don't well work together for both Python 2.5 and 2.6a
(SVN version).  The reasons are related but different.

In Python 2.5, you can't select any text in the IDLE window and whenever
a calltip is to appear, you get a backtrace ending with "invalid literal
for int() with base 10: '(72,'".  That comes from an interaction between
WidgetRedirector's dispatch function and _tkinter.  The Text widget's
bbox method returns a tuple of ints, the dispatch function isn't
monitoring bbox, so it returns the tuple as is to _tkinter, where
PythonCmd converts the tuple to a Python string, not a Tcl list, so when
Tkinter sees the string, it can't convert to a tuple.

The Python "2.6a2" SVN version of _tkinter fixes that bug but exposes
others (Ikinter.py, tupleobject.c), so I've attached a simple patch for
Python 2.5.  The SVN version of idle appears to work, so this patch
should only be on the 2.5 branch.

----------
components: IDLE, Tkinter
files: Python-2.5.2-idlelib.patch
keywords: patch
messages: 65828
nosy: gregc
severity: normal
status: open
title: IDLE  doesn't work with Tk 8.5
versions: Python 2.5
Added file: http://bugs.python.org/file10112/Python-2.5.2-idlelib.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
__________________________________

From report at bugs.python.org  Sat Apr 26 01:42:00 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Fri, 25 Apr 2008 23:42:00 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209166920.81.0.0463423616034.issue2603@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file10113/range_eq8_normalize2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 01:52:28 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Fri, 25 Apr 2008 23:52:28 +0000
Subject: [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>
Message-ID: <1209167548.74.0.559673069349.issue2693@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I'm skeptical about this patch; it may break other things. So Python 2.5
just doesn't support Tcl 8.5 - you need to stay with Tcl 8.4.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
__________________________________

From report at bugs.python.org  Sat Apr 26 02:21:34 2008
From: report at bugs.python.org (Collin Winter)
Date: Sat, 26 Apr 2008 00:21:34 +0000
Subject: [issue2412] Check 2to3 for support of print function.
In-Reply-To: <1205883738.38.0.0352891857591.issue2412@psf.upfronthosting.co.za>
Message-ID: <1209169294.46.0.719274355302.issue2412@psf.upfronthosting.co.za>


Collin Winter <collinw at gmail.com> added the comment:

Reviewing...

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2412>
__________________________________

From report at bugs.python.org  Sat Apr 26 02:22:42 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Apr 2008 00:22:42 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209169362.85.0.16672131774.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

With respect to range_eq8_normalize2.patch, it is unusual to have a 
function that consumes a reference to its argument.  I would combine 
normalize_stop with PyNumber_Index and make it similar to validate_step 
with respect to reference counting.

Note that if you choose stop = start + len*step normaization, you will 
not need to create 'one' in normalize_stop.

With your patch I see

>>> range(0,6,2)
range(0, 6, 2)
>>> range(0,5,2)
range(0, 5, 2)

I would expect one of these ranges normalized.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 02:37:13 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sat, 26 Apr 2008 00:37:13 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209170233.07.0.484773673778.issue2603@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

... and your patch produces wrong results:

>>> list(range(5,0,-2)) # expected [5, 3, 1]
[5, 3]

See my patch in issue2690 for a way to compute length correctly in 
range_new.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 04:35:21 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 26 Apr 2008 02:35:21 +0000
Subject: [issue2669] bsddb iterkeys sliently fails when database modified
	during iteration
In-Reply-To: <1208886727.18.0.175464776053.issue2669@psf.upfronthosting.co.za>
Message-ID: <1209177321.43.0.199908594864.issue2669@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2669>
__________________________________

From report at bugs.python.org  Sat Apr 26 04:55:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Apr 2008 02:55:52 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209178552.31.0.716414726452.issue2603@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I merged your range calculating code. After reading that bug report, I
think we need to start a discussion on python-dev about range size
constraints before moving forward any more. (We have people implementing
different things under different assumptions left and right.)

Added file: http://bugs.python.org/file10114/range_eq8_normalize3.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 05:05:27 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 26 Apr 2008 03:05:27 +0000
Subject: [issue2558] Document pickle protocol 3
In-Reply-To: <1207417351.95.0.372966716234.issue2558@psf.upfronthosting.co.za>
Message-ID: <1209179127.28.0.762768417789.issue2558@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2558>
__________________________________

From report at bugs.python.org  Sat Apr 26 05:10:36 2008
From: report at bugs.python.org (=?utf-8?q?Jes=C3=BAs_Cea_Avi=C3=B3n?=)
Date: Sat, 26 Apr 2008 03:10:36 +0000
Subject: [issue2389] Array pickling exposes internal memory representation of
	elements
In-Reply-To: <1205851091.96.0.575523128038.issue2389@psf.upfronthosting.co.za>
Message-ID: <1209179436.08.0.822684042513.issue2389@psf.upfronthosting.co.za>


Changes by Jes?s Cea Avi?n <jcea at jcea.es>:


----------
nosy: +jcea

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2389>
__________________________________

From report at bugs.python.org  Sat Apr 26 06:18:43 2008
From: report at bugs.python.org (Cournapeau David)
Date: Sat, 26 Apr 2008 04:18:43 +0000
Subject: [issue2694] msilib file names check too strict ?
In-Reply-To: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>
Message-ID: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>


New submission from Cournapeau David <david at ar.media.kyoto-u.ac.jp>:

Hi,

I wanted to build a msi using the build_msi distutils command for one of
my package, but at some point, it fails, at the function make_id, at
line 177 in mstlib/__init__.py, for a file named aixc++.py. The regex
indeed refuses any character which is not alphanumeric: is msi itself
really that strict, or could this check be relaxed ?

----------
components: Windows
messages: 65834
nosy: cdavid
severity: normal
status: open
title: msilib file names check too strict ?
type: feature request
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2694>
__________________________________

From report at bugs.python.org  Sat Apr 26 10:16:42 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Sat, 26 Apr 2008 08:16:42 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209197802.78.0.513961719878.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Given that range() produced a list in the 2.x series (hence limited to
available memory), and xrange() uses int internally for its values (and
hence couldn't even cope with short ranges with values greater than
sys.maxint).

So my preference is to mimic the 2.x range's behaviour in this case by
raising an overflow error if the sequence is too long.

(From Python 2.5.1)

>>> range(2**99, 2**100)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: range() result has too many items
>>> range(2**99, 2**99+5)
[633825300114114700748351602688L, 633825300114114700748351602689L,
633825300114114700748351602690L, 633825300114114700748351602691L,
633825300114114700748351602692L]
>>> xrange(2**99, 2**99+5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OverflowError: long int too large to convert to int

----------
nosy: +ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Sat Apr 26 10:47:18 2008
From: report at bugs.python.org (david reid)
Date: Sat, 26 Apr 2008 08:47:18 +0000
Subject: [issue2695] Ignore case when checking algorithm in urllib2
In-Reply-To: <1209199638.72.0.800736981101.issue2695@psf.upfronthosting.co.za>
Message-ID: <1209199638.72.0.800736981101.issue2695@psf.upfronthosting.co.za>


New submission from david reid <mail at david-reid.com>:

Small change to allow get_algorithm_impls to correctly detect when lower
case algorithm strings are passed. I recently ran into a server that
sent 'md5' and so this function failed without this small change.

    def get_algorithm_impls(self, algorithm):
        # lambdas assume digest modules are imported at the top level
        if algorithm.lower() == 'md5':
            H = lambda x: hashlib.md5(x).hexdigest()
        elif algorithm.lower() == 'sha':
            H = lambda x: hashlib.sha1(x).hexdigest()
        ...

----------
components: Library (Lib)
messages: 65836
nosy: zathras
severity: normal
status: open
title: Ignore case when checking algorithm in urllib2
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2695>
__________________________________

From report at bugs.python.org  Sat Apr 26 12:07:34 2008
From: report at bugs.python.org (ThurnerRupert)
Date: Sat, 26 Apr 2008 10:07:34 +0000
Subject: [issue2696] unicode string does not get freed --> memory leak?
In-Reply-To: <1209204453.97.0.209118835087.issue2696@psf.upfronthosting.co.za>
Message-ID: <1209204453.97.0.209118835087.issue2696@psf.upfronthosting.co.za>


New submission from ThurnerRupert <rupert.thurner at credit-suisse.com>:

is it possible that str and unicode str are treated differently, i.e.
unicode str does not give memory back? jonas borgstr?m noticed the
following behaviour:

>>> resident_size()
3780
>>> a = ["%i" % i for i in xrange(2**22)]
>>> resident_size()
239580
>>> del a
>>> resident_size()

4128    <-- Most memory returned to the os
>>> a = [u"%i" % i for i in xrange(2**22)]
>>> resident_size()
434532
>>> del a
>>> resident_size()R

401760  <-- Almost nothing returned to the os 


for details see
http://groups.google.com/group/trac-dev/browse_thread/thread/9de74e1d2f62e2ed.

----------
messages: 65837
nosy: ThurnerRupert
severity: normal
status: open
title: unicode string does not get freed --> memory leak?
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2696>
__________________________________

From report at bugs.python.org  Sat Apr 26 12:08:06 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sat, 26 Apr 2008 10:08:06 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1209204486.67.0.433804064566.issue2636@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I don't know anything about regexp implementation, but if you replace a
switch-case with a function lookup table, it isn't surprising that the
new version ends up slower. A local jump is always faster than a
function call, because of the setup overhead and stack manipulation the
latter involves.

So you might try to do the cleanup while keeping the switch-case
structure, if possible.

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Sat Apr 26 12:35:10 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 26 Apr 2008 10:35:10 +0000
Subject: [issue2696] unicode string does not get freed --> memory leak?
In-Reply-To: <1209204453.97.0.209118835087.issue2696@psf.upfronthosting.co.za>
Message-ID: <1209206110.85.0.738075013861.issue2696@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

This is a duplicate of issue 2321. There was no memory leak whatsoever,
instead, malloc just failed to return the memory returned to it (through
free(3)) to the operating system. Don't trust resident_size() to detect
memory leaks; that approach is fairly flawed.

----------
nosy: +loewis
resolution:  -> duplicate
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2696>
__________________________________

From report at bugs.python.org  Sat Apr 26 12:54:45 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Apr 2008 10:54:45 +0000
Subject: [issue2684] Logging Module still failing for %(filename)s, __init__
In-Reply-To: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>
Message-ID: <1209207285.15.0.272949086321.issue2684@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This is not a logging bug, but rather due to the circumstance that
.pyc/.pyo files do not correctly point to the source files that produced
them. There is another issue about this (#1180193) .

Closing this, as it's not a logging issue.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2684>
__________________________________

From report at bugs.python.org  Sat Apr 26 12:55:44 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Sat, 26 Apr 2008 10:55:44 +0000
Subject: [issue2684] Logging Module still failing for %(filename)s, __init__
In-Reply-To: <1209066689.35.0.514393267186.issue2684@psf.upfronthosting.co.za>
Message-ID: <1209207344.74.0.587200109901.issue2684@psf.upfronthosting.co.za>


Changes by Vinay Sajip <vinay_sajip at yahoo.co.uk>:


----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2684>
__________________________________

From report at bugs.python.org  Sat Apr 26 13:51:15 2008
From: report at bugs.python.org (Jeffrey C. Jacobs)
Date: Sat, 26 Apr 2008 11:51:15 +0000
Subject: [issue2636] Regexp 2.6 (modifications to current re 2.2.2)
In-Reply-To: <1208260672.14.0.711874677361.issue2636@psf.upfronthosting.co.za>
Message-ID: <1209210675.59.0.287735102195.issue2636@psf.upfronthosting.co.za>


Jeffrey C. Jacobs <timehorse at users.sourceforge.net> added the comment:

Thank you and Merci Antoine!

That is a good point.  It is clearly specific to the compiler whether a 
switch-case will be turned into a series of conditional branches or 
simply creating an internal jump table with lookup.  And it is true 
that most compilers, if I understand correctly, use the jump-table 
approach for any switch-case over 2 or 3 entries when the cases are 
tightly grouped and near 0.  That is probably why the original code 
worked so fast.  I'll see if I can combine the best of both 
approaches.  Thanks again!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2636>
__________________________________

From report at bugs.python.org  Sat Apr 26 14:19:36 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 26 Apr 2008 12:19:36 +0000
Subject: [issue2694] msilib file names check too strict ?
In-Reply-To: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>
Message-ID: <1209212376.11.0.845257611116.issue2694@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Indeed, the primary keys in many tables must be Identifiers, see

http://msdn2.microsoft.com/en-us/library/aa369212(VS.85).aspx

make_id tries to synthesize an identifier from a file name, and fails
for your file names.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2694>
__________________________________

From report at bugs.python.org  Sat Apr 26 15:46:38 2008
From: report at bugs.python.org (andrew cooke)
Date: Sat, 26 Apr 2008 13:46:38 +0000
Subject: [issue2697] Logging ancestors ignored after configuration
In-Reply-To: <1209217597.75.0.0893619687269.issue2697@psf.upfronthosting.co.za>
Message-ID: <1209217597.75.0.0893619687269.issue2697@psf.upfronthosting.co.za>


New submission from andrew cooke <andrew at acooke.org>:

I am seeing some odd behaviour with logging which would be explained
if loggers that are not defined explicitly (but which are controlled
via their ancestors) must be created after the logging system is
configured via fileConfig().

That's a bit abstract, so here's the problem itself:  I define my log
within a module by doing

import logging
log = logging.getLogger(__name__)

Now typically __name__ will be something like "acooke.utils.foo".

That happens before the application configures logging, which it does
by calling logging.config.fileConfig() to load a configuration.

If I do that, then I don't see any logging output from
"acooke.utils.foo" (when using "log" from above after "fileConfig" has
been called) unless I explicitly define a logger with that name.
Neither root nor an "acooke" logger, defined in the config file, are
called.

One way to handle this is to make creation of module-level Loggers
lazy, and make sure that logging initialisation occurs before any
other logging is actually used (which is not so hard - just init log
at the start of the application).

Of course, there's a performance hit...

For example:

class Log(object):
    def __init__(self, name):
        super(Log, self).__init__()
        self._name = name
        self._lazy = None
    def __getattr__(self, key):
        if not self._lazy:
            self._lazy = logging.getLogger(self._name)
        return getattr(self._lazy, key)

and then, in some module:

from acooke.util.log import Log
log = Log(__name__)
[...]
class Foo(object):
    def my_method(self):
        log.debug("this works as expected")

----------
components: Library (Lib)
messages: 65843
nosy: acooke
severity: normal
status: open
title: Logging ancestors ignored after configuration
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2697>
__________________________________

From report at bugs.python.org  Sat Apr 26 17:39:23 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Apr 2008 15:39:23 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209224363.6.0.322377051145.issue2603@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file10116/range_eq8_normalize4.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 17:56:07 2008
From: report at bugs.python.org (Cournapeau David)
Date: Sat, 26 Apr 2008 15:56:07 +0000
Subject: [issue2694] msilib file names check too strict ?
In-Reply-To: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>
Message-ID: <1209225367.81.0.156637252847.issue2694@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

Ok, thanks for the information.

It may good to have a bit more informative error, though, such as saying
which characters are allowed when checking against a regex ?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2694>
__________________________________

From report at bugs.python.org  Sat Apr 26 18:02:32 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 26 Apr 2008 16:02:32 +0000
Subject: [issue2694] msilib file names check too strict ?
In-Reply-To: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>
Message-ID: <1209225752.88.0.515462580542.issue2694@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Actually, the algorithm should be fixed to generate a valid identifier
for any input.

Would you like to work on a fix?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2694>
__________________________________

From report at bugs.python.org  Sat Apr 26 18:13:56 2008
From: report at bugs.python.org (Cournapeau David)
Date: Sat, 26 Apr 2008 16:13:56 +0000
Subject: [issue2694] msilib file names check too strict ?
In-Reply-To: <1209183523.66.0.300786856749.issue2694@psf.upfronthosting.co.za>
Message-ID: <1209226436.08.0.88776185048.issue2694@psf.upfronthosting.co.za>


Cournapeau David <david at ar.media.kyoto-u.ac.jp> added the comment:

It's not that I don't want to work on it, but I don't know anything
about msi, except that some windows users of my packages request it  :)
So I would need some indication on what to fix exactly

Do I understand right that dist_msi builds a database of the files, and
that the identifiers could be named differently than the filenames
themselves, as long as they are unique ?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2694>
__________________________________

From report at bugs.python.org  Sat Apr 26 18:23:54 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sat, 26 Apr 2008 16:23:54 +0000
Subject: [issue2694] msilib file names check too strict ?
In-Reply-To: <1209226436.08.0.88776185048.issue2694@psf.upfronthosting.co.za>
Message-ID: <48135713.9000707@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Do I understand right that dist_msi builds a database of the files, and
> that the identifiers could be named differently than the filenames
> themselves, as long as they are unique ?

Correct. As a design objective, I try to use identifiers close to the
file names, to simplify debugging of the MSI file (Microsoft itself
typically uses UUIDs instead).

In short, just make make_id generate valid identifiers. An algorithm
on top of that will make them unique in case of conflicts.

Regards,
Martin

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2694>
__________________________________

From report at bugs.python.org  Sat Apr 26 18:40:48 2008
From: report at bugs.python.org (Mads Kiilerich)
Date: Sat, 26 Apr 2008 16:40:48 +0000
Subject: [issue2622] Import errors in email.message.py
In-Reply-To: <1207978673.41.0.752617892341.issue2622@psf.upfronthosting.co.za>
Message-ID: <1209228048.35.0.319717519456.issue2622@psf.upfronthosting.co.za>


Mads Kiilerich <mads at kiilerich.com> added the comment:

Testing that email.message doesn't use the "wrong" casing
email.Generator isn't enough. That would just test that this patch has
been applied. It must also be tested that no other modules uses the
wrong casing of email.Generator. Or other email packages. Or any other
packages at all.

IMHO the "right" test would be to test that modulefinder can find all
relevant modules in all cases. The problem is that it gives irrelevant
warnings.

I tested with some shell hacking to find all modulefinder failures which
could be found with another casing:

find * -name '*.py'|sed 's,\.py$,,g;s,/,.,g;s,\.__init__$,,g' >
/tmp/all_fs_modules
for a in $(find * -name '*.py'); do echo $a; python -m modulefinder $a;
echo; done > /tmp/all_referenced_modules
for a in $(grep ^? /tmp/all_referenced_modules|sed 's,^\? \(.*\)
imported from .*,\1,g'|sort|uniq); do grep -i "^$a"'$'
/tmp/all_fs_modules; done > /tmp/referenced_existing_ignorecased

email.base64mime
email.charset
email.encoders
email.errors
email.generator
email.header
email.iterators
email.message
email.parser
email.quoprimime
email.utils
ftplib

- where the last hit comes from bogus regexp matching. The test takes
long time to run as it is. That could probably be improved. But still I
think this is to be compared with "lint"-like tools which should be run
reguarly but isn't suitable for unit tests.

I feel ashamed for arguing against introducing a test. I think I do that
because I think that this isn't a "normal" bug and thus isn't suitable
for unit testing. 

The email module itself really is fully backwards compatible. And
modulefinder does a good job doing what it does and can't be blamed for
not figuring the email hackery out. The problem comes when a third
external modules puts things together and they doesn't fit together as
one could expect.

Also, currently both casings works and should work. Using the old casing
isn't a "bug bug", but it has consequences which IMHO is enough to call
it a bug and fix it.

Perhaps Python could have a standard way markup of deprecated functions
so that it could be checked that the standard librarary didn't use them.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2622>
__________________________________

From report at bugs.python.org  Sat Apr 26 17:33:47 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Sat, 26 Apr 2008 15:33:47 +0000
Subject: [issue2487] ldexp(x,n) misbehaves when abs(n) is large
In-Reply-To: <1206487537.98.0.104101200523.issue2487@psf.upfronthosting.co.za>
Message-ID: <1209224027.89.0.865298002036.issue2487@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Here's a patch that should fix ldexp(x, large_int), as follows:

ldexp(x, n) = x if x is a NaN, zero or infinity
ldexp(x, n) = copysign(0., x) for x finite and nonzero, n large and -ve
ldexp(x, n) -> OverflowError for x finite and nonzero, n large and +ve

It would be good if someone else could review this before I check it in;
Fredrik, would you have time for this?

----------
keywords: +patch
Added file: http://bugs.python.org/file10115/ldexp.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2487>
__________________________________

From report at bugs.python.org  Sat Apr 26 19:06:35 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Apr 2008 17:06:35 +0000
Subject: [issue2603] Make range __eq__ work
In-Reply-To: <1207776487.99.0.710555963511.issue2603@psf.upfronthosting.co.za>
Message-ID: <1209229595.02.0.443868504288.issue2603@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file10117/range_eq8_normalize5.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2603>
__________________________________

From report at bugs.python.org  Sat Apr 26 19:20:24 2008
From: report at bugs.python.org (Lenard Lindstrom)
Date: Sat, 26 Apr 2008 17:20:24 +0000
Subject: [issue2698] Extension module build fails for MinGW: missing
	vcvarsall.bat
In-Reply-To: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>
Message-ID: <1209230424.66.0.154562223128.issue2698@psf.upfronthosting.co.za>


New submission from Lenard Lindstrom <len-l at telus.net>:

Python 2.6a2 on Windows XP

Distutils fails to build an extension module for MinGW. Even though 
mingw32 is specified as the compiler distutils.msvc9compiler is still 
loaded and it cannot find vcvarsall.bat. Here is an example:

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

[snip]

C:\pygame\ext>path=%path%;C:\python26;C:\mingw\bin

C:\pygame\ext>set MINGW_ROOT_DIRECTORY=C:\mingw

C:\pygame\ext>python setup.py build --compiler=mingw32
running build
running build_ext
error: None

C:\pygame\ext>python setup.py build_ext --compiler=mingw32
Traceback (most recent call last):
  File "setup.py", line 6, in <module>
    ext_modules=[Extension('simple', ['simple.c',]),],
  File "C:\python26\lib\distutils\core.py", line 137, in setup
    ok = dist.parse_command_line()
  File "C:\python26\lib\distutils\dist.py", line 459, in 
parse_command_line
    args = self._parse_command_opts(parser, args)
  File "C:\python26\lib\distutils\dist.py", line 517, in 
_parse_command_opts
    cmd_class = self.get_command_class(command)
  File "C:\python26\lib\distutils\dist.py", line 836, in 
get_command_class
    __import__ (module_name)
  File "C:\python26\lib\distutils\command\build_ext.py", line 21, in 
<module>
    from distutils.msvccompiler import get_build_version
  File "C:\python26\lib\distutils\msvccompiler.py", line 658, in 
<module>
    from distutils.msvc9compiler import MSVCCompiler
  File "C:\python26\lib\distutils\msvc9compiler.py", line 286, in 
<module>
    VC_ENV = query_vcvarsall(VERSION, ARCH)
  File "C:\python26\lib\distutils\msvc9compiler.py", line 253, in 
query_vcvarsall
    raise IOError("Unable to find vcvarsall.bat")
IOError: Unable to find vcvarsall.bat

C:\pygame\ext>type setup.py
from distutils.core import setup, Extension

setup(name='Simple',
      version='1.0',
      description='Python extension module test',
      ext_modules=[Extension('simple', ['simple.c',]),],
      )


C:\pygame\ext>gcc --version
gcc (GCC) 3.4.5 (mingw special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is 
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR 
PURPOSE.


C:\pygame\ext>python -V
Python 2.6a2

----------
components: Distutils
messages: 65850
nosy: kermode
severity: normal
status: open
title: Extension module build fails for MinGW: missing vcvarsall.bat
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2698>
__________________________________

From report at bugs.python.org  Sat Apr 26 20:34:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 26 Apr 2008 18:34:20 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209234860.5.0.985101268522.issue2677@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I'd love to add to the documentation, but I can't seem to find a proper
location - except the Tutorial?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Sat Apr 26 20:32:22 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 26 Apr 2008 18:32:22 +0000
Subject: [issue2691] Document size_t related long object APIs
In-Reply-To: <1209139390.07.0.282911361275.issue2691@psf.upfronthosting.co.za>
Message-ID: <1209234742.24.0.990102622552.issue2691@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks, committed as r62513.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2691>
__________________________________

From report at bugs.python.org  Sat Apr 26 20:27:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sat, 26 Apr 2008 18:27:57 +0000
Subject: [issue2668] apply() documentation is slightly incorrect
In-Reply-To: <1208882945.04.0.253062304574.issue2668@psf.upfronthosting.co.za>
Message-ID: <1209234477.48.0.391819628265.issue2668@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Fixed in r62511.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2668>
__________________________________

From report at bugs.python.org  Sat Apr 26 23:03:12 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sat, 26 Apr 2008 21:03:12 +0000
Subject: [issue2584] numeric overflow in IDLE
In-Reply-To: <1207667953.02.0.926823971175.issue2584@psf.upfronthosting.co.za>
Message-ID: <1209243792.16.0.31303971223.issue2584@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser <kbk at shore.net>:


----------
assignee:  -> kbk
nosy: +kbk
priority:  -> normal

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2584>
__________________________________

From report at bugs.python.org  Sat Apr 26 23:09:41 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Sat, 26 Apr 2008 21:09:41 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209244179.96.0.401260387503.issue1180@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Both versions of the patch have a problem, in that the Distribution
object is looking for an option directly in sys.argv.  At the very
least, this should be looking at the 'script_args' attribute of the
Distribution instead (if not actually parsing the command line enough to
find the option).

----------
nosy: +pje

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Sun Apr 27 01:17:39 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Apr 2008 23:17:39 +0000
Subject: [issue2699] Exception name improperly indented
In-Reply-To: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>
Message-ID: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The new warnings implementation tweaks how tracebacks are printed. This 
introduced a bug where the exception name is indented when it shouldn't 
be: e.g., ``raise KeyError`` should look like::

  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
  KeyError

not::

  Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
      KeyError

----------
assignee: brett.cannon
components: Interpreter Core
messages: 65855
nosy: brett.cannon
priority: release blocker
severity: normal
status: open
title: Exception name improperly indented
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2699>
__________________________________

From report at bugs.python.org  Sun Apr 27 01:19:07 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sat, 26 Apr 2008 23:19:07 +0000
Subject: [issue2699] Exception name improperly indented
In-Reply-To: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>
Message-ID: <1209251947.57.0.691756531897.issue2699@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Forgot to mention this is probably from Python/traceback.c:tb_displayline().

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2699>
__________________________________

From report at bugs.python.org  Sun Apr 27 01:53:19 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sat, 26 Apr 2008 23:53:19 +0000
Subject: [issue2699] Exception name improperly indented
In-Reply-To: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>
Message-ID: <1209253998.91.0.396170070873.issue2699@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

It looks like you can just remove the offending line like so:


Index: Python/traceback.c
===================================================================
--- Python/traceback.c  (revision 62515)
+++ Python/traceback.c  (working copy)
@@ -222,8 +222,7 @@
        err = PyFile_WriteString(linebuf, f);
        if (err != 0)
                return err;
-
-        err = PyFile_WriteString("    ", f);
+
         return Py_DisplaySourceLine(f, filename, lineno);
 }

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2699>
__________________________________

From report at bugs.python.org  Sun Apr 27 02:09:55 2008
From: report at bugs.python.org (Terry J. Reedy)
Date: Sun, 27 Apr 2008 00:09:55 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209254995.65.0.550433147083.issue2677@psf.upfronthosting.co.za>


Terry J. Reedy <tjreedy at udel.edu> added the comment:

Ludovico quoted from LangReg 5.3.4 of old style doc.  The same paragraph
about keyword args is under Expressions/Primaries/Calls in the 2.6/3.0 docs

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Sun Apr 27 02:31:25 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 00:31:25 +0000
Subject: [issue2337] Backport oct() and hex() to use __index__
In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za>
Message-ID: <1209256285.89.0.152082625029.issue2337@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is what I'd like to do: In builtin oct/hex check if the special
method is declared. If it is, Py3k warn and use it. If not, check if we
can do it the Py3k way (with PyNumber_ToBase). Sound good?

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2337>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:09:02 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 01:09:02 +0000
Subject: [issue2700] document PyNumber_ToBase
In-Reply-To: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>
Message-ID: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

Including a patch.

----------
assignee: georg.brandl
components: Documentation
files: tobase_doc.patch
keywords: patch
messages: 65860
nosy: benjamin.peterson, georg.brandl
severity: normal
status: open
title: document PyNumber_ToBase
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10118/tobase_doc.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2700>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:18:20 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Apr 2008 01:18:20 +0000
Subject: [issue1950] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za>
Message-ID: <1209259100.31.0.255874099747.issue1950@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

So, any comment on the latest patch?

If everything is all right, I would like to commit the patch to py3k.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1950>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:21:16 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Apr 2008 01:21:16 +0000
Subject: [issue1338] pickling bytes?
In-Reply-To: <1193425561.23.0.273747744158.issue1338@psf.upfronthosting.co.za>
Message-ID: <1209259276.13.0.0496809856844.issue1338@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Guido fixed this issue in r61467.

Closing.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1338>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:23:43 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Apr 2008 01:23:43 +0000
Subject: [issue2337] Backport oct() and hex() to use __index__
In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za>
Message-ID: <1209259423.59.0.895062817573.issue2337@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

@Georg:

That is a possibility. Would need to add the proper Py3K warning to the 
current builtins, though.

@Benjamin:

You don't want to warn if it will work for Py3K, so don't warn if 
__index__ is used.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2337>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:24:56 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Apr 2008 01:24:56 +0000
Subject: [issue2699] Exception name improperly indented
In-Reply-To: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>
Message-ID: <1209259496.34.0.554400870107.issue2699@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Yep. I already did that and ran the unit test suite to verify. Now I am 
just trying to figure out how to best test it. It seems it only comes up 
for printing a traceback. That would mean either using subprocess to run 
another interpreter and capture its output or cheat and use ctypes. I 
don't like either solution.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2699>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:26:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 01:26:52 +0000
Subject: [issue2337] Backport oct() and hex() to use __index__
In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za>
Message-ID: <1209259612.09.0.0718123250196.issue2337@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I meant not to. Sorry, that wasn't clear.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2337>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:58:27 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Sun, 27 Apr 2008 01:58:27 +0000
Subject: [issue2671] PyErr_WarnPy3k
In-Reply-To: <1208902039.11.0.586606723559.issue2671@psf.upfronthosting.co.za>
Message-ID: <1209261507.54.0.0555027900467.issue2671@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Looks good. Go ahead. Make sure to block the CL (and any follow-up CLs
that use this) from integration into 3.0.

----------
assignee:  -> benjamin.peterson
nosy: +gvanrossum
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2671>
__________________________________

From report at bugs.python.org  Sun Apr 27 03:58:49 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Apr 2008 01:58:49 +0000
Subject: [issue558238] Pickling bound methods
Message-ID: <1209261528.99.0.854738902818.issue558238@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Personally, I don't see how adding this feature would create a security
hole (or more properly said, grow the giant hole that are the GLOBAL and
 REDUCE opcodes). I don't see either why this should be included in the
standard library.

Unless there is still a need for this feature, I think this bug should
be closed.

----------
nosy: +alexandre.vassalotti

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue558238>
____________________________________

From report at bugs.python.org  Sun Apr 27 04:12:01 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Apr 2008 02:12:01 +0000
Subject: [issue558238] Pickling bound methods
Message-ID: <1209262321.5.0.0516524240927.issue558238@psf.upfronthosting.co.za>


Changes by Alexandre Vassalotti <alexandre at peadrop.com>:


----------
status: open -> pending

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue558238>
____________________________________

From report at bugs.python.org  Sun Apr 27 04:29:24 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Apr 2008 02:29:24 +0000
Subject: [issue1637926] Empty class 'Object'
Message-ID: <1209263364.63.0.902090137677.issue1637926@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

This has almost no-chance to get included in the standard library. Also,
Python 2.6 will include ``namedtuple`` (see
http://docs.python.org/dev/library/collections.html#collections.namedtuple),
which provides similar functionally.

Closing this issue as rejected.

----------
nosy: +alexandre.vassalotti
resolution:  -> rejected
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1637926>
_____________________________________

From report at bugs.python.org  Sun Apr 27 04:31:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 02:31:49 +0000
Subject: [issue2671] PyErr_WarnPy3k
In-Reply-To: <1208902039.11.0.586606723559.issue2671@psf.upfronthosting.co.za>
Message-ID: <1209263509.67.0.793398056618.issue2671@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Committed in r62517.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2671>
__________________________________

From report at bugs.python.org  Sun Apr 27 04:48:22 2008
From: report at bugs.python.org (Alexandre Vassalotti)
Date: Sun, 27 Apr 2008 02:48:22 +0000
Subject: [issue2480] pickling of large recursive structures fails
In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
Message-ID: <1209264502.45.0.804924968705.issue2480@psf.upfronthosting.co.za>


Alexandre Vassalotti <alexandre at peadrop.com> added the comment:

Bob Kline wrote:
> I just ran into this behavior with an attempt to pickle a dom tree
> for an XML document whose nesting level never got deeper than nine
> child nodes, and indeed it crashed the interpreter.

Pickling recursive data-structure should not crash the interpreter.
Please open a new issue and don't forget to provide an example case.

> the documentation for the pickle module [1] which claims (summarizing)
> that serializing recursive objects using marshal will fail but
> pickling recursive objects will not fail.

The section of documentation, you are referring to, uses the term
"recursive object" to means an object which contains a reference to
itself. Anyway, the documentation [1] states clearly:

  Trying to pickle a highly recursive data structure may exceed the
  maximum recursion depth, a RuntimeError will be raised in this
  case. You can carefully raise this limit with sys.setrecursionlimit().

[1]: http://docs.python.org/lib/node317.html

----------
nosy: +alexandre.vassalotti
type: crash -> feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2480>
__________________________________

From report at bugs.python.org  Sun Apr 27 04:59:51 2008
From: report at bugs.python.org (Roy Smith)
Date: Sun, 27 Apr 2008 02:59:51 +0000
Subject: [issue2701] csv.reader accepts string instead of file object (duck
	typing gone bad)
In-Reply-To: <1209265191.29.0.100156108517.issue2701@psf.upfronthosting.co.za>
Message-ID: <1209265191.29.0.100156108517.issue2701@psf.upfronthosting.co.za>


New submission from Roy Smith <roy at panix.com>:

If you pass csv.reader() a filename as its first argument:

  csv.reader('filename')

instead of a file object like you're supposed to, you don't get an error.  
You instead get a reader object which returns the characters which make up 
the filename.

Technically, this is not a bug, since the documentation says, "csvfile can 
be any object which supports the iterator protocol and returns a string 
each time its next method is called", and a string meets that definition.  
Still, this is unexpected behavior, and is almost certainly not what the 
user intended.  It would be useful if a way could be devised to catch this 
kind of mistake.

----------
components: Library (Lib)
messages: 65871
nosy: roysmith
severity: normal
status: open
title: csv.reader accepts string instead of file object (duck typing gone bad)
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2701>
__________________________________

From report at bugs.python.org  Sun Apr 27 06:27:59 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Sun, 27 Apr 2008 04:27:59 +0000
Subject: [issue1950] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za>
Message-ID: <1209270478.12.0.651844387256.issue1950@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

The patch looks good.  Just a question: I thought the strings returned by PyUnicode_AsStringAndSize are 0-terminated, while your patch at several 
places attempts to explicitly 0-terminate a copy of such string.  Are you 
sure this is necessary?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1950>
__________________________________

From report at bugs.python.org  Sun Apr 27 07:48:21 2008
From: report at bugs.python.org (Greg Couch)
Date: Sun, 27 Apr 2008 05:48:21 +0000
Subject: [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>
Message-ID: <1209275300.82.0.229312652575.issue2693@psf.upfronthosting.co.za>


Greg Couch <gregcouch at gmail.com> added the comment:

I wish I could be as cavalier about Tk 8.5.  The last version of Tk 8.4
just came out and it really shows its age, especially on Mac OS X, and
those are ~25% of our application's downloads.  Since Python 2.6a2 is
"not suitable for production use", that leaves us with patching 2.5. 
Backporting, the _tkinter and Tkinter changes, was not hard, but then we
get "SystemError: Objects/tupleobject.c:89: bad argument to internal
function" errors with both the 2.5 and the 2.6a2 idlelibs.  Looking at
the SVN log, it is not clear which patch to tupleobject.c fixed that
problem (does anyone know?).

So fixing WidgetRedirector.py to not screw up the string representation
of tuples is the easiest solution to get idle to work with Tk 8.5. and
Python 2.5 (you still would want the Tkinter.py changes for other
reasons).  A slightly more robust solution would be to use Tcl quoting:

    r = '{%s}' % '} {'.join(map(str, r))

But that has not been important in practice.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
__________________________________

From report at bugs.python.org  Sun Apr 27 09:09:56 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 27 Apr 2008 07:09:56 +0000
Subject: [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209275300.82.0.229312652575.issue2693@psf.upfronthosting.co.za>
Message-ID: <481426BE.9050801@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> I wish I could be as cavalier about Tk 8.5.  The last version of Tk 8.4
> just came out and it really shows its age, especially on Mac OS X, and
> those are ~25% of our application's downloads.

Still, why is that a problem to use it for IDLE?

> Since Python 2.6a2 is
> "not suitable for production use", that leaves us with patching 2.5. 

If you need to patch Python 2.5, just go ahead and do it. You don't need
your patch accepted for that. Python 2.5.3 will likely be released
*after* Python 2.6, at which point the "not suitable for production use"
argument will be invalid.

> Backporting, the _tkinter and Tkinter changes, was not hard, but then we
> get "SystemError: Objects/tupleobject.c:89: bad argument to internal
> function" errors with both the 2.5 and the 2.6a2 idlelibs.  Looking at
> the SVN log, it is not clear which patch to tupleobject.c fixed that
> problem (does anyone know?).

I don't think there was any such change to tupleobject.c. If you got
the internal error after changing something, you probably changed it
incorrectly.

> So fixing WidgetRedirector.py to not screw up the string representation
> of tuples is the easiest solution to get idle to work with Tk 8.5. and
> Python 2.5 (you still would want the Tkinter.py changes for other
> reasons).  A slightly more robust solution would be to use Tcl quoting:
> 
>     r = '{%s}' % '} {'.join(map(str, r))
> 
> But that has not been important in practice.

This is what I'm concerned about. I cannot accept a patch whose
correctness was just established through testing. In fact, I don't
understand what the proposed change actually does: what are the
values of the variables at the point, what is the expected result,
what is the actual result, and how does the patch change that?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
__________________________________

From report at bugs.python.org  Sun Apr 27 09:21:21 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Apr 2008 07:21:21 +0000
Subject: [issue2700] document PyNumber_ToBase
In-Reply-To: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>
Message-ID: <1209280881.42.0.804739009582.issue2700@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You should mention that if base is none of 2, 8, 10, or 16, the output
looks like "12#555" where 12 is the base.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2700>
__________________________________

From report at bugs.python.org  Sun Apr 27 09:53:09 2008
From: report at bugs.python.org (Daniel Darabos)
Date: Sun, 27 Apr 2008 07:53:09 +0000
Subject: [issue2702] pickling of large recursive structures crashes cPickle
In-Reply-To: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>
Message-ID: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>


New submission from Daniel Darabos <darabos.daniel at gmail.com>:

The documentation[1] says:

  Trying to pickle a highly recursive data structure may exceed the
  maximum recursion depth, a RuntimeError will be raised in this
  case. You can carefully raise this limit with sys.setrecursionlimit().

The lightweight pickle module handles this problem correctly (in that it
raises a RuntimeError), but cPickle sometimes raises KeyError instead,
or just silently terminates the interpreter (=crashes). (I have not been
able to pinpoint what it depends on. In the attached example I get
silent termination, but if instead of lists I use sets to describe the
connections, I get the RuntimeError.)

This was mentioned in issue 2480, but that has now been changed to a
feature request to eliminate recursion altogether. That may have a lower
priority, but this crash can be hard to diagnose in a complex
application, and I am not sure if sys.setrecursionlimit() affects
cPickle behavior (I guess not).

[1]: http://docs.python.org/lib/node317.html

----------
components: Library (Lib)
files: bugdemo.py
messages: 65876
nosy: alexandre.vassalotti, bkline, cyhawk, jcea, schmir
severity: normal
status: open
title: pickling of large recursive structures crashes cPickle
type: crash
versions: Python 2.5
Added file: http://bugs.python.org/file10119/bugdemo.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2702>
__________________________________

From report at bugs.python.org  Sun Apr 27 09:55:12 2008
From: report at bugs.python.org (Daniel Darabos)
Date: Sun, 27 Apr 2008 07:55:12 +0000
Subject: [issue2480] eliminate recursion in pickling
In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
Message-ID: <1209282912.27.0.524090333496.issue2480@psf.upfronthosting.co.za>


Daniel Darabos <darabos.daniel at gmail.com> added the comment:

I have also described the crash, but it makes sense to handle it
separately. So I have created issue 2702, and changed the title of this
issue.

----------
title: pickling of large recursive structures fails -> eliminate recursion in pickling

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2480>
__________________________________

From report at bugs.python.org  Sun Apr 27 10:23:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Sun, 27 Apr 2008 08:23:31 +0000
Subject: [issue2702] pickling of large recursive structures crashes cPickle
In-Reply-To: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>
Message-ID: <1209284611.44.0.75048702248.issue2702@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

What operating system and compiler are you using?

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2702>
__________________________________

From report at bugs.python.org  Sun Apr 27 10:45:17 2008
From: report at bugs.python.org (Daniel Darabos)
Date: Sun, 27 Apr 2008 08:45:17 +0000
Subject: [issue2702] pickling of large recursive structures crashes cPickle
In-Reply-To: <1209282789.34.0.562999954252.issue2702@psf.upfronthosting.co.za>
Message-ID: <1209285917.29.0.443961167223.issue2702@psf.upfronthosting.co.za>


Daniel Darabos <darabos.daniel at gmail.com> added the comment:

Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit
(Intel)] on win32

(Windows XP Professional 32 bits)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2702>
__________________________________

From report at bugs.python.org  Sun Apr 27 11:34:12 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Apr 2008 09:34:12 +0000
Subject: [issue2699] Exception name improperly indented
In-Reply-To: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>
Message-ID: <1209288852.36.0.918795392932.issue2699@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

You could add a function to the _testcapi module to invoke PyErr_Display.

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2699>
__________________________________

From report at bugs.python.org  Sun Apr 27 11:36:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Apr 2008 09:36:29 +0000
Subject: [issue2337] Backport oct() and hex() to use __index__
In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za>
Message-ID: <1209288988.86.0.886579162458.issue2337@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

I don't assume there are too many people using oct() and hex() with
custom types anyway :)

Since PyNumber_ToBase and the new oct() format octal numbers with "0o"
instead of "0", I still think it's better if you need to import the new
oct() from future_builtins. For hex(), I have no preference.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2337>
__________________________________

From report at bugs.python.org  Sun Apr 27 11:40:15 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Apr 2008 09:40:15 +0000
Subject: [issue2677] Argument rules for callables do not apply when function
	implementation uses PyArg_ParseTuple
In-Reply-To: <1209031286.77.0.288825613693.issue2677@psf.upfronthosting.co.za>
Message-ID: <1209289215.38.0.272090040674.issue2677@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Ah sorry, I should really read the OP next time.

Added a note in r62521.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2677>
__________________________________

From report at bugs.python.org  Sun Apr 27 11:56:36 2008
From: report at bugs.python.org (Matthias Klose)
Date: Sun, 27 Apr 2008 09:56:36 +0000
Subject: [issue2703] SimpleXMLRPCDispatcher.__init__ is not
	python2.4-backward-compatible
In-Reply-To: <1209290195.97.0.404790617339.issue2703@psf.upfronthosting.co.za>
Message-ID: <1209290195.97.0.404790617339.issue2703@psf.upfronthosting.co.za>


New submission from Matthias Klose <doko at debian.org>:

[forwarded from http://bugs.debian.org/470645]

"SimpleXMLRPCDispatcher.__init__ used to take a single argument
(self) in python2.4 and now it takes three. The two new arguments
need to get default values or else this breaks backwards
compatibility badly."

while SimpleXMLRPCDispatcher is not described as part of the interface,
it is mentioned in the docs. The fix seems to be easy. Ok for trunk and
the branch?

----------
components: Library (Lib)
files: dispatcher.diff
keywords: patch, patch
messages: 65883
nosy: doko
severity: normal
status: open
title: SimpleXMLRPCDispatcher.__init__ is not python2.4-backward-compatible
type: behavior
versions: Python 2.5, Python 2.6
Added file: http://bugs.python.org/file10120/dispatcher.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2703>
__________________________________

From report at bugs.python.org  Sun Apr 27 13:42:08 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Sun, 27 Apr 2008 11:42:08 +0000
Subject: [issue2701] csv.reader accepts string instead of file object (duck
	typing gone bad)
In-Reply-To: <1209265191.29.0.100156108517.issue2701@psf.upfronthosting.co.za>
Message-ID: <1209296528.11.0.829547542922.issue2701@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

It's not a mistake.  In fact, the csv unit tests make use of being able
to iterate over strings.  I don't think this feature is going away.

----------
nosy: +skip.montanaro

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2701>
__________________________________

From report at bugs.python.org  Sun Apr 27 16:06:07 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 27 Apr 2008 14:06:07 +0000
Subject: [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>
Message-ID: <1209305167.54.0.51591052491.issue2693@psf.upfronthosting.co.za>


Changes by Kurt B. Kaiser <kbk at shore.net>:


----------
nosy: +kbk

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
__________________________________

From report at bugs.python.org  Sun Apr 27 17:00:45 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 27 Apr 2008 15:00:45 +0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1209308445.31.0.821217873981.issue2053@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

Please provide a single patch file.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Sun Apr 27 19:15:34 2008
From: report at bugs.python.org (Paul Winkler)
Date: Sun, 27 Apr 2008 17:15:34 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209316534.52.0.85013204995.issue1180@psf.upfronthosting.co.za>


Changes by Paul Winkler <pw_lists at slinkp.com>:


Removed file: http://bugs.python.org/file10105/python_distutils_1180_2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Sun Apr 27 19:54:27 2008
From: report at bugs.python.org (Paul Winkler)
Date: Sun, 27 Apr 2008 17:54:27 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209318867.4.0.324710733943.issue1180@psf.upfronthosting.co.za>


Paul Winkler <pw_lists at slinkp.com> added the comment:

Phillip, thanks, I missed that script_args is always passed by
core.setup(). I'm replacing the patches with two new versions that check
self.script_args instead of sys.argv (and assumes false if for some
reason script_args isn't passed).

We can't check for it in Distribution.parse_command_line() because that
doesn't get called until after loading the config files.

Added file: http://bugs.python.org/file10121/python_distutils_1180.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Sun Apr 27 19:54:42 2008
From: report at bugs.python.org (Paul Winkler)
Date: Sun, 27 Apr 2008 17:54:42 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209318882.64.0.863328556306.issue1180@psf.upfronthosting.co.za>


Changes by Paul Winkler <pw_lists at slinkp.com>:


Removed file: http://bugs.python.org/file9763/python_distutils_1180.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Sun Apr 27 19:55:36 2008
From: report at bugs.python.org (Paul Winkler)
Date: Sun, 27 Apr 2008 17:55:36 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209318936.24.0.379320215499.issue1180@psf.upfronthosting.co.za>


Paul Winkler <pw_lists at slinkp.com> added the comment:

and here's the revised version of the dependency-injection approach.

Added file: http://bugs.python.org/file10122/python_distutils_1180_2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Sun Apr 27 19:58:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 17:58:46 +0000
Subject: [issue2700] document PyNumber_ToBase
In-Reply-To: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>
Message-ID: <1209319126.44.0.533258518733.issue2700@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
versions: +Python 3.0
Added file: http://bugs.python.org/file10123/tobase_doc2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2700>
__________________________________

From report at bugs.python.org  Sun Apr 27 20:02:40 2008
From: report at bugs.python.org (Roger Serwy)
Date: Sun, 27 Apr 2008 18:02:40 +0000
Subject: [issue2704] IDLE: Patch to make PyShell behave more like a Terminal
	interface
In-Reply-To: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>
Message-ID: <1209319360.66.0.583090952017.issue2704@psf.upfronthosting.co.za>


New submission from Roger Serwy <roger.serwy at gmail.com>:

See attached diff file. Patching PyShell.py Version 1.2.1

PyShell ignores letter/number key presses when the cursor is not on the
command line. Instead it should redirect any letter/number key presses
to the command line. (Changed ModifiedUndoDelegator)

Also, up/down arrow presses should scroll through history when the
cursor is on the command line. But when the cursor is not on the command
line, the arrow keys should move around the PyShell window. (Added new
bindings with conditional logic)

----------
components: IDLE
files: patch_PyShell.py
messages: 65888
nosy: serwy
severity: normal
status: open
title: IDLE: Patch to make PyShell behave more like a Terminal interface
type: behavior
versions: Python 2.5
Added file: http://bugs.python.org/file10124/patch_PyShell.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2704>
__________________________________

From report at bugs.python.org  Sun Apr 27 20:04:38 2008
From: report at bugs.python.org (Georg Brandl)
Date: Sun, 27 Apr 2008 18:04:38 +0000
Subject: [issue2700] document PyNumber_ToBase
In-Reply-To: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>
Message-ID: <1209319478.04.0.676167912701.issue2700@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Okay, go ahead and commit.

----------
assignee: georg.brandl -> benjamin.peterson
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2700>
__________________________________

From report at bugs.python.org  Sun Apr 27 20:16:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 18:16:14 +0000
Subject: [issue2700] document PyNumber_ToBase
In-Reply-To: <1209258542.19.0.639526136527.issue2700@psf.upfronthosting.co.za>
Message-ID: <1209320174.83.0.932599154797.issue2700@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Commited in r62535.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2700>
__________________________________

From report at bugs.python.org  Sun Apr 27 20:25:44 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Sun, 27 Apr 2008 18:25:44 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209320744.21.0.483451135088.issue1180@psf.upfronthosting.co.za>


Phillip J. Eby <pje at telecommunity.com> added the comment:

I much prefer the simpler of the two patches - better to monkeypatch in
the tests than adding complications to the already over-complicated
distutils.dist.  I don't find monkeypatching in tests to be horrible at
all, but if it really bothers you, just create a temporary directory for
HOME to point to, and test a Distribution subclass with an overridden
check_environ. 

By the way, the patch could be simpler if you just made the "if 'HOME'
in os.environ" read "if not self.no_user_cfg and 'HOME' in os.environ",
rather than reworking the entire code region.  On the other hand, if
you'd rather have ultra-clean unit tests, you could split the
functionality of find_config_files() into two methods: one that creates
the candidate list and the other that filters it by existence.

Personally, my vote is to keep the monkeypatching in the tests and make
the barest minimal changes to the Distribution class though.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Sun Apr 27 21:04:46 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 19:04:46 +0000
Subject: [issue2337] Backport oct() and hex() to use __index__
In-Reply-To: <1205776266.64.0.297851457778.issue2337@psf.upfronthosting.co.za>
Message-ID: <1209323086.59.0.775030063031.issue2337@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Here's a patch for that. It warns for hex() when __hex__ is used,
otherwise it uses __index__. (This doesn't work for old style classes
because ob_tp->tp_as_number->tp_hex is filled.) Use of oct() just gets a
warning. The __hex__ and __oct__ methods of builtin number objects
should probably be removed.

----------
keywords: +patch
Added file: http://bugs.python.org/file10125/oct_and_hex_py3k.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2337>
__________________________________

From report at bugs.python.org  Sun Apr 27 21:08:37 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 19:08:37 +0000
Subject: [issue2352] Use of __oct__/__hex__ should raise a Py3K warning
In-Reply-To: <1205782034.73.0.229035988217.issue2352@psf.upfronthosting.co.za>
Message-ID: <1209323317.46.0.309390155746.issue2352@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

This is being taken care of as #2337.

----------
nosy: +benjamin.peterson
resolution:  -> duplicate
status: open -> closed
superseder:  -> Backport oct() and hex() to use __index__

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2352>
__________________________________

From report at bugs.python.org  Sun Apr 27 21:08:54 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 27 Apr 2008 19:08:54 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

In Python 2.5 and earlier, the `showwarning? function in the `warnings?
module has this signature:

  def showwarning(message, category, filename, lineno, file=None):

In trunk (and presumably what will become Python 2.6), this has become:

  def showwarning(message, category, filename, lineno, file=None,
line=None):

`showwarning? is documented as a hook which libraries or applications
may override in order to control how warnings are reported.  The
addition of a new parameter to the function and the change to related
code to call it with an argument for that new parameter means that
libraries and applications which replaced it will not work without
modification on Python 2.6.  Instead, a `TypeError? will be raised when
a warning is emitted.

I suggest restoring the previous signature for `showwarning? and adding
a new (perhaps preferred) API for showing a warning with the extra
information available.  It may also make sense to emit a deprecation
warning when an overridden old-style `showwarning? is found.

----------
components: Library (Lib)
messages: 65894
nosy: exarkun
severity: normal
status: open
title: incompatible change to warnings.showwarning
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 21:25:33 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Apr 2008 19:25:33 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209324333.07.0.811159642105.issue2705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Well, all you have to do is to change the hook's signature to the new
one and, since the last parameter is optional, it should not cause any
backwards compatibility problems. That is, the new hook should work fine
on Python < 2.6 as well. Am I missing something?

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 21:31:49 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Sun, 27 Apr 2008 19:31:49 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209324708.95.0.333534083864.issue2705@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

We should have an entry under "Porting to 2.6" in whatsnew.

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 22:04:25 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Apr 2008 20:04:25 +0000
Subject: [issue2699] Exception name improperly indented
In-Reply-To: <1209288852.36.0.918795392932.issue2699@psf.upfronthosting.co.za>
Message-ID: <bbaeab100804271304w3bfa2159w94278e63883caafd@mail.gmail.com>


Brett Cannon <brett at python.org> added the comment:

On Sun, Apr 27, 2008 at 2:34 AM, Georg Brandl <report at bugs.python.org> wrote:
>
>  Georg Brandl <georg at python.org> added the comment:
>
>  You could add a function to the _testcapi module to invoke PyErr_Display.
>

That's true and probably the only sane idea.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2699>
__________________________________

From report at bugs.python.org  Sun Apr 27 22:25:31 2008
From: report at bugs.python.org (Glyph Lefkowitz)
Date: Sun, 27 Apr 2008 20:25:31 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209327931.25.0.277542300057.issue2705@psf.upfronthosting.co.za>


Glyph Lefkowitz <glyph at divmod.com> added the comment:

pitrou: You're missing a few steps.  If you are maintaining project X,
which depends on library Y, that adds a showwarning hook for some
reason, you need to:

 * check out a development version of library Y, which you do not
normally maintain
 * change the hook's signature to the new one
 * submit a patch to library Y
 * make a local fork of library Y so that you can verify the rest of
your code under 2.6
 * send out an email to your mailing list explaining that they cannot
run with python 2.6 without this patch (linking to the patch in library Y)
 * write a FAQ entry because 200 people show up asking why it does not
work on python 2.6
 * if library Y's development is slow, do a new release of project X
which includes monkeypatching to allow running project X on 2.6

These steps may be unavoidable if library Y has been unmaintained for a
long enough time, but it would be nice to be able to avoid this with a
single new Python release.

----------
nosy: +glyph

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 22:38:21 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Sun, 27 Apr 2008 20:38:21 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209328701.52.0.155239055258.issue2705@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Is it a theoretical case or are you thinking about a specific library Y? 

Also, seeing some things break when a new Python version is released is
not new as you certainly know : see
http://twistedmatrix.com/trac/ticket/1867

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 22:41:46 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Apr 2008 20:41:46 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209328905.99.0.400478687764.issue2705@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

I have emailed python-dev to try to decide how to handle this.

----------
assignee:  -> brett.cannon
nosy: +brett.cannon
priority:  -> critical

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 22:41:55 2008
From: report at bugs.python.org (Brett Cannon)
Date: Sun, 27 Apr 2008 20:41:55 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209328915.22.0.501711196982.issue2705@psf.upfronthosting.co.za>


Changes by Brett Cannon <brett at python.org>:


----------
priority: critical -> release blocker

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 22:51:28 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Sun, 27 Apr 2008 20:51:28 +0000
Subject: [issue2705] incompatible change to warnings.showwarning
In-Reply-To: <1209323334.77.0.104236998001.issue2705@psf.upfronthosting.co.za>
Message-ID: <1209329488.88.0.864328203796.issue2705@psf.upfronthosting.co.za>


Jean-Paul Calderone <exarkun at divmod.com> added the comment:

By the way, I just noticed that Lib/idlelib/PyShell.py includes an
override of `showwarning? which is defined with the old signature.

I ran idle from trunk and verified that is indeed breaks warning reporting.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2705>
__________________________________

From report at bugs.python.org  Sun Apr 27 23:04:07 2008
From: report at bugs.python.org (webograph)
Date: Sun, 27 Apr 2008 21:04:07 +0000
Subject: [issue2706] datetime: define division timedelta/timedelta
In-Reply-To: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>
Message-ID: <1209330247.56.0.71148380164.issue2706@psf.upfronthosting.co.za>


New submission from webograph <webograph at eml.cc>:

i suggest that division be defined for timedelta1/timedelta2, in that
sense that it gives how many times timedelta2 fits in timedelta1 (ie the
usual meaning of division), using integer arithmetics for floor division
(//) and returning float for truediv (/ after `from __future__ import
division`)

use case
--------

aside from the obvious how-many-times-does-a-fit-into-b, this solves the
issue of having individual methods for conversion to a number of
seconds, hours, days or nanocenturies (as described in #1673409).
example:

from datetime import timedelta
duration = timedelta(hours=1.5, seconds=20)
print "Until the time is up, you can listen to 'We will rock you' %d
times."%(duration//timedelta(minutes=5, seconds=3))
import time
time.sleep(duration/timedelta(seconds=1))


history
-------

this issue follows a discussion on python-list, re-initiated by [1].

there have previously been similar feature requests on datetime, most of
which have been rejected due to ambiguities (e.g. [2]), conflicts with
time_t or issues with time zones.

the only issue i've seen that can be relevant here is the
integer-vs-float discussion, which is here handled by floordiv (//) and
truediv.

patch
-----

i've written a patch against svn trunk revision 62520.

it uses function pointers to reduce code duplication; in case this
inappropriate here, i also have a pointerless version.

i familiar with c but not experienced, especially with the python ways
of writing c. most of the code is just adapted from other functions in
the same files, so it is probably, but should nevertheless checked with
special care.

i've also added test, but am not sure what has to be tested and what not.


compatibility
-------------

only cases in which division would fail without the patch are changed.
this will be a problem if (and only if) someone divides unknown objects
and waits for TypeError to be raised.
such behavior is probably rare.


[1] <mid:4813CD56.40800 at eml.cc>,
http://mail.python.org/pipermail/python-list/2008-April/488406.html
[2] http://mail.python.org/pipermail/python-dev/2002-March/020604.html

----------
components: Library (Lib)
files: datetime_datetime_division.patch
keywords: patch
messages: 65902
nosy: webograph
severity: normal
status: open
title: datetime: define division timedelta/timedelta
type: feature request
Added file: http://bugs.python.org/file10126/datetime_datetime_division.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2706>
__________________________________

From report at bugs.python.org  Sun Apr 27 23:08:19 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 27 Apr 2008 21:08:19 +0000
Subject: [issue1196903] smarter behaviour for home key in IDLE
Message-ID: <1209330499.35.0.482963147961.issue1196903@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

The toggling is useful when ending a def. If other IDEs
have this binding, I can't see a problem.  I've been running the
patch for awhile now, and notice that Ctrl-A also has this
new action now. It seems useful, let's give it a try.

r62546

----------
resolution:  -> accepted
status: open -> closed

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1196903>
_____________________________________

From report at bugs.python.org  Sun Apr 27 23:38:35 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 27 Apr 2008 21:38:35 +0000
Subject: [issue2062] IDLE - autocompletion logic optimization
In-Reply-To: <1202686613.86.0.38587079031.issue2062@psf.upfronthosting.co.za>
Message-ID: <1209332315.52.0.738001165088.issue2062@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

r62548

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2062>
__________________________________

From report at bugs.python.org  Sun Apr 27 23:52:45 2008
From: report at bugs.python.org (Kurt B. Kaiser)
Date: Sun, 27 Apr 2008 21:52:45 +0000
Subject: [issue2061] IDLE - autocompletion to support alternate path separators
In-Reply-To: <1202683566.14.0.229280339125.issue2061@psf.upfronthosting.co.za>
Message-ID: <1209333165.65.0.377989257986.issue2061@psf.upfronthosting.co.za>


Kurt B. Kaiser <kbk at shore.net> added the comment:

r62549

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2061>
__________________________________

From report at bugs.python.org  Mon Apr 28 01:00:06 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 27 Apr 2008 23:00:06 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209337206.63.0.34482158385.issue2663@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

Agreed, rmtree should have it as well. I'll add that in the patch as well,

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 01:16:53 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 27 Apr 2008 23:16:53 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209338213.6.0.15018011091.issue2663@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

while working on the patch to add the same feature in rmtree, I realized
this is a non sense since the root folder itself is removed at the end
of the function when all its content is removed.

So, unless we change this behavior, which I doubt it is a good idea, it
won't be possible.

Maybe another API could be added in shutil, in order to do any kind of
treatment in a tree, like removing files, or whatever, and without
copying it like copytree does.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 01:32:36 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Sun, 27 Apr 2008 23:32:36 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209339155.59.0.307501176085.issue2663@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

I have thaught of various ways to write this new API for the deletion
use case, but I think nothing makes it easier and shorter than a simple
os.walk call.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 02:17:17 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Apr 2008 00:17:17 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209341837.12.0.0641280327948.issue2663@psf.upfronthosting.co.za>


Tarek Ziad? <ziade.tarek at gmail.com> added the comment:

This patch includes the documentation for shutils.rst as well. (I
removed the older patches)

Added file: http://bugs.python.org/file10127/shutil.copytree.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 02:17:31 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Apr 2008 00:17:31 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209341851.39.0.966792106501.issue2663@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file10066/shutil.copytree.filtering.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 02:17:36 2008
From: report at bugs.python.org (=?utf-8?q?Tarek_Ziad=C3=A9?=)
Date: Mon, 28 Apr 2008 00:17:36 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209341856.89.0.579699483105.issue2663@psf.upfronthosting.co.za>


Changes by Tarek Ziad? <ziade.tarek at gmail.com>:


Removed file: http://bugs.python.org/file10073/shutil.copytree.filtering.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 05:24:21 2008
From: report at bugs.python.org (Brett Cannon)
Date: Mon, 28 Apr 2008 03:24:21 +0000
Subject: [issue2699] Exception name improperly indented
In-Reply-To: <1209251858.91.0.847250684585.issue2699@psf.upfronthosting.co.za>
Message-ID: <1209353060.2.0.903545744038.issue2699@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Fix in revision 62555.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2699>
__________________________________

From report at bugs.python.org  Mon Apr 28 08:43:14 2008
From: report at bugs.python.org (Yinon Ehrlich)
Date: Mon, 28 Apr 2008 06:43:14 +0000
Subject: [issue2707] Tiny fix for os.walk docstring
In-Reply-To: <1209364994.21.0.532528115565.issue2707@psf.upfronthosting.co.za>
Message-ID: <1209364994.21.0.532528115565.issue2707@psf.upfronthosting.co.za>


New submission from Yinon Ehrlich <yinoneh at users.sourceforge.net>:

os.walk.__doc__ has the following example-line (os.py, line 271):
  for root, dirs, files in walk('python/Lib/email'):

it should be os.walk

----------
components: Library (Lib)
messages: 65911
nosy: Yinon
severity: normal
status: open
title: Tiny fix for os.walk docstring
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2707>
__________________________________

From report at bugs.python.org  Mon Apr 28 11:07:20 2008
From: report at bugs.python.org (Ralf Schmitt)
Date: Mon, 28 Apr 2008 09:07:20 +0000
Subject: [issue2703] SimpleXMLRPCDispatcher.__init__ is not
	python2.4-backward-compatible
In-Reply-To: <1209290195.97.0.404790617339.issue2703@psf.upfronthosting.co.za>
Message-ID: <1209373640.88.0.289964285905.issue2703@psf.upfronthosting.co.za>


Changes by Ralf Schmitt <schmir at gmail.com>:


----------
nosy: +schmir

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2703>
__________________________________

From report at bugs.python.org  Mon Apr 28 14:01:09 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Apr 2008 12:01:09 +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: <1209384064.93.0.301352098413.issue1222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

I've had the opportunity to test on a Windows box and there are various
failures in the TestStringMethods test case. If someone with more
knowledge of the Windows world could take a lookm it would be nice.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
__________________________________

From report at bugs.python.org  Mon Apr 28 14:12:20 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Apr 2008 12:12:20 +0000
Subject: [issue2703] SimpleXMLRPCDispatcher.__init__ is not
	python2.4-backward-compatible
In-Reply-To: <1209290195.97.0.404790617339.issue2703@psf.upfronthosting.co.za>
Message-ID: <1209384740.34.0.573091772343.issue2703@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

The patch is OK, but I'm still -0.

The doc string says: "There should never be any reason to instantiate
this class directly." I don't see how this could "break backwards
compatibility badly".

----------
nosy: +amaury.forgeotdarc

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2703>
__________________________________

From report at bugs.python.org  Mon Apr 28 14:30:37 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Apr 2008 12:30:37 +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: <1209385837.2.0.513429000598.issue1222@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Ok, here is an updated patch for Windows compatibility of the test suite.

Added file: http://bugs.python.org/file10128/bug1222.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1222>
__________________________________

From report at bugs.python.org  Mon Apr 28 14:49:46 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Mon, 28 Apr 2008 12:49:46 +0000
Subject: [issue2262] Helping the compiler avoid memory references in
	PyEval_EvalFrameEx
In-Reply-To: <1205084332.03.0.568369699233.issue2262@psf.upfronthosting.co.za>
Message-ID: <1209386986.02.0.663691228978.issue2262@psf.upfronthosting.co.za>


Changes by Antoine Pitrou <pitrou at free.fr>:


----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2262>
__________________________________

From report at bugs.python.org  Mon Apr 28 15:16:02 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Mon, 28 Apr 2008 13:16:02 +0000
Subject: [issue2697] Logging ancestors ignored after configuration
In-Reply-To: <1209217597.75.0.0893619687269.issue2697@psf.upfronthosting.co.za>
Message-ID: <1209388558.72.0.342896993115.issue2697@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

This is not a bug - it's by design, as I explained in my reply to your
posting on comp.lang.python. In my reply, I suggested how you could
avoid problems.

----------
assignee:  -> vsajip
nosy: +vsajip
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2697>
__________________________________

From report at bugs.python.org  Mon Apr 28 15:34:39 2008
From: report at bugs.python.org (Humberto Diogenes)
Date: Mon, 28 Apr 2008 13:34:39 +0000
Subject: [issue1883] Adapt pydoc to new doc system
In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
Message-ID: <1209389677.75.0.658641990079.issue1883@psf.upfronthosting.co.za>


Humberto Diogenes <humberto at digi.com.br> added the comment:

According to Georg, the "adaptation" referred by this issue is just about 
changing the URLs in the documentation to point appropriately to the URLs 
generated by the new doc system.

Anyway, the doc-cleanup.patch is still pending... ;)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1883>
__________________________________

From report at bugs.python.org  Mon Apr 28 15:37:08 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Mon, 28 Apr 2008 13:37:08 +0000
Subject: [issue1883] Adapt pydoc to new doc system
In-Reply-To: <1200935648.41.0.205281442116.issue1883@psf.upfronthosting.co.za>
Message-ID: <1209389828.05.0.668488351029.issue1883@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

> Anyway, the doc-cleanup.patch is still pending... ;)
No, I already removed the duplicated code in r62505.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1883>
__________________________________

From report at bugs.python.org  Mon Apr 28 16:10:42 2008
From: report at bugs.python.org (Kristian Lauridsen)
Date: Mon, 28 Apr 2008 14:10:42 +0000
Subject: [issue2708] IDLE subprocess error
In-Reply-To: <1209391841.34.0.293801648559.issue2708@psf.upfronthosting.co.za>
Message-ID: <1209391841.34.0.293801648559.issue2708@psf.upfronthosting.co.za>


New submission from Kristian Lauridsen <diablos_pitbull at hotmail.com>:

Hi all.
I'w been looking for an answer to this. 
If I use IDLE for som "just fore fun" programming and then exit, I have 
to "kill" IDLE, dispite theres nothin "running" persay, then when i 
start IDLE again I get too error messages popping up:

1: Socket Error: Connection refused
2: IDLE's subprocess didn't make connection. Either IDLE can't start a 
subprocess or personal firewall is blocking the connection.

The code written in IDLE that triggers the problem can be something 
simple like:
>>> a = 'hello world'
>>> print a

I have to reboot to get past the error.
I'm only getting the error when running vista and xp theres no problom 
in any of the other systems i'v tried (mainly linux)
I should mention that the error dosn't come every time I "kill" IDLE, I 
would say about every 3rd run, or there about.
I'v tried removeing/killing windows owen firewall and then running IDLE 
but with the same result.
Like I said, i been look around fore a "fix" fore this but havent found 
any...
If I have made a "double post" please let me know and remove this 
post....

----------
components: IDLE
messages: 65918
nosy: Kris
severity: normal
status: open
title: IDLE subprocess error
type: crash
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2708>
__________________________________

From report at bugs.python.org  Mon Apr 28 16:12:05 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 28 Apr 2008 14:12:05 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209391925.44.0.667399603754.issue2663@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

My update with email failed so I am just copying my response here:

>  while working on the patch to add the same feature in rmtree, I realized
>  this is a non sense since the root folder itself is removed at the end
>  of the function when all its content is removed.

Indeed. Sorry about that.

>  So, unless we change this behavior, which I doubt it is a good idea, it
>  won't be possible.

I agree. But in general, it would be nice to separate file list
generation and the actual operation. Something similar to shell where
it resolves the pattern while the actual command itself cares only
about the files passed to it. This is not necessarily a comment on
this patch which I am hoping I can check it out soon.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 16:33:34 2008
From: report at bugs.python.org (Paul Winkler)
Date: Mon, 28 Apr 2008 14:33:34 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209393214.31.0.391872479652.issue1180@psf.upfronthosting.co.za>


Paul Winkler <pw_lists at slinkp.com> added the comment:

Phillip, here's another revision of the monkeypatch-in-setUp() approach,
simplified per your suggestions.

Added file: http://bugs.python.org/file10129/python_distutils_1180_3.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Mon Apr 28 17:49:51 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Mon, 28 Apr 2008 15:49:51 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1209393214.31.0.391872479652.issue1180@psf.upfronthosting. co.za>
Message-ID: <20080428154911.071363A4070@sparrow.telecommunity.com>


Phillip J. Eby <pje at telecommunity.com> added the comment:

It looks like you can drop the change to distutils.core, too, since 
it's just a change in the comment, and the changed comment is 
inaccurate, AFAICT.  Apart from that, it looks good.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Mon Apr 28 18:33:17 2008
From: report at bugs.python.org (Guilherme Polo)
Date: Mon, 28 Apr 2008 16:33:17 +0000
Subject: [issue2709] tk.rst possibly wrong ?
In-Reply-To: <1209400395.54.0.768474211008.issue2709@psf.upfronthosting.co.za>
Message-ID: <1209400395.54.0.768474211008.issue2709@psf.upfronthosting.co.za>


New submission from Guilherme Polo <ggpolo at gmail.com>:

tk.rst tells, among other things:

"`Tkinter`'s chief virtues are that it is fast, and that it usually comes
bundled with Python. Although it has been used to create some very good
applications,  including IDLE, it has weak documentation ..."

Why does it say Tkinter has weak documentation ? There is a printed book
("Python and Tkinter Programming"), several online tutorials and
references, there is a wiki too, the mail list and possibly something
else I've missed.

----------
assignee: georg.brandl
components: Documentation
messages: 65922
nosy: georg.brandl, gpolo
severity: normal
status: open
title: tk.rst possibly wrong ?
versions: Python 2.6, Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2709>
__________________________________

From report at bugs.python.org  Mon Apr 28 19:24:28 2008
From: report at bugs.python.org (Lorenz Quack)
Date: Mon, 28 Apr 2008 17:24:28 +0000
Subject: [issue2650] re.escape should not escape underscore
In-Reply-To: <1208441650.53.0.945063086485.issue2650@psf.upfronthosting.co.za>
Message-ID: <1209403468.57.0.396282837541.issue2650@psf.upfronthosting.co.za>


Lorenz Quack <don at amberfisharts.com> added the comment:

>> The loop in escape should really use enumerate 
>> instead of "for i in range(len(pattern))".
>
>It needs i to edit s[i].

enumerate(iterable) returns a tuple for each element in iterable
containing the index and the element itself.

I attached a patch using enumerate. The patch also uses a frozenset
rather than a dict for the special characters.

----------
nosy: +donlorenzo
Added file: http://bugs.python.org/file10130/re.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2650>
__________________________________

From report at bugs.python.org  Mon Apr 28 19:49:20 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 28 Apr 2008 17:49:20 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209404960.51.0.79024309492.issue2663@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

The patch looks good to me.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 19:53:30 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 28 Apr 2008 17:53:30 +0000
Subject: [issue2663] shutil.copytree glob-style filtering [patch]
In-Reply-To: <1208726903.81.0.936252523277.issue2663@psf.upfronthosting.co.za>
Message-ID: <1209405210.71.0.193355635564.issue2663@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

I forgot to add that the example provided in rst doc is incorrect. The
copytree() in that example should be given destination path as well. In
addition, the docstring for copytree mentions "which is a directory
list". "directory list" is a bit vague and should ideally be replaced by
something like "list of elements" (which is what appears in the doc) or
"list of entries".

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2663>
__________________________________

From report at bugs.python.org  Mon Apr 28 21:04:48 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Apr 2008 19:04:48 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209409487.38.0.0504693695933.issue2690@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I've implemented range slicing and x in range(..) in range-sequence.diff 
and registered range with the Sequence ABC.

Added file: http://bugs.python.org/file10131/range-sequence.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Mon Apr 28 21:08:43 2008
From: report at bugs.python.org (Bob Kline)
Date: Mon, 28 Apr 2008 19:08:43 +0000
Subject: [issue2480] eliminate recursion in pickling
In-Reply-To: <1206452686.51.0.217993005172.issue2480@psf.upfronthosting.co.za>
Message-ID: <1209409723.28.0.753145930062.issue2480@psf.upfronthosting.co.za>


Bob Kline <bkline at users.sourceforge.net> added the comment:

> Please open a new issue and don't forget to provide an example case.

Looks like Daniel beat me to the punch.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2480>
__________________________________

From report at bugs.python.org  Mon Apr 28 21:44:20 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Apr 2008 19:44:20 +0000
Subject: [issue841728] urllib and cookie module improvements
Message-ID: <1209411860.3.0.395333922732.issue841728@psf.upfronthosting.co.za>


Changes by Georg Brandl <georg at python.org>:


----------
status: open -> closed

____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue841728>
____________________________________

From report at bugs.python.org  Mon Apr 28 21:57:38 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Apr 2008 19:57:38 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1209412657.12.0.206767984856.issue2541@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Please apply the patch, but rename "Unicode escapes" to "\u and \U
escapes" first.

----------
assignee: georg.brandl -> benjamin.peterson
resolution: rejected -> fixed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2541>
__________________________________

From report at bugs.python.org  Mon Apr 28 21:59:19 2008
From: report at bugs.python.org (Raghuram Devarakonda)
Date: Mon, 28 Apr 2008 19:59:19 +0000
Subject: [issue2711] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411892.21.0.718182356449.issue2711@psf.upfronthosting.co.za>
Message-ID: <1209412759.67.0.357341366544.issue2711@psf.upfronthosting.co.za>


Raghuram Devarakonda <draghuram at gmail.com> added the comment:

Duplicate of #2710.

----------
nosy: +draghuram
resolution:  -> duplicate
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2711>
__________________________________

From report at bugs.python.org  Mon Apr 28 21:44:53 2008
From: report at bugs.python.org (Don Hanlen)
Date: Mon, 28 Apr 2008 19:44:53 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>


New submission from Don Hanlen <dhanlen at owt.com>:

IDLE internal error in runcode()
Traceback (most recent call last):
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 235, in asyncqueue
    self.putmessage((seq, request))
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 332, in putmessage
    n = self.sock.send(s[:BUFSIZE])
error: (10035, 'The socket operation could not complete without blocking')

Does this look familiar to anyone?  I can't figure out what to do about
it.  Python 2.5, windoze.  I get it when I execute a Tkinter op that
works elsewhere.

changing this (works):

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    width = self.checkerSize)

to

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    font=("Times", str(self.checkerSize/2), "bold"),
    width = self.checkerSize)

for example.  The same code works fine elsewhere.  I thought I'd ask
here before I try (no clue) increasing BUFSIZE in rpc.py?  I'm not crazy
about tinkering with code I have no clue about..

It has been suggested that the problem is competition with IDLE for
tkinter resources.

-- 

don

----------
files: tkinterwork.py
messages: 65928
nosy: dhanlen
severity: normal
status: open
title: error: (10035, 'The socket operation could not complete without blocking')
versions: Python 2.5
Added file: http://bugs.python.org/file10133/tkinterwork.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
__________________________________

From report at bugs.python.org  Mon Apr 28 21:44:53 2008
From: report at bugs.python.org (Don Hanlen)
Date: Mon, 28 Apr 2008 19:44:53 +0000
Subject: [issue2711] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411892.21.0.718182356449.issue2711@psf.upfronthosting.co.za>
Message-ID: <1209411892.21.0.718182356449.issue2711@psf.upfronthosting.co.za>


New submission from Don Hanlen <dhanlen at owt.com>:

IDLE internal error in runcode()
Traceback (most recent call last):
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 235, in asyncqueue
    self.putmessage((seq, request))
  File "C:\PYTHON25\lib\idlelib\rpc.py", line 332, in putmessage
    n = self.sock.send(s[:BUFSIZE])
error: (10035, 'The socket operation could not complete without blocking')

Does this look familiar to anyone?  I can't figure out what to do about
it.  Python 2.5, windoze.  I get it when I execute a Tkinter op that
works elsewhere.

changing this (works):

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    width = self.checkerSize)

to

t = self.b.create_text(
    (point.baseX + 1)*self.checkerSize/2 + fudge,
    y + fudge,
    text = str(point.occupied),
    font=("Times", str(self.checkerSize/2), "bold"),
    width = self.checkerSize)

for example.  The same code works fine elsewhere.  I thought I'd ask
here before I try (no clue) increasing BUFSIZE in rpc.py?  I'm not crazy
about tinkering with code I have no clue about..

It has been suggested that the problem is competition with IDLE for
tkinter resources.

-- 

don

----------
files: tkinterwork.py
messages: 65929
nosy: dhanlen
severity: normal
status: open
title: error: (10035, 'The socket operation could not complete without blocking')
versions: Python 2.5
Added file: http://bugs.python.org/file10132/tkinterwork.py

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2711>
__________________________________

From report at bugs.python.org  Mon Apr 28 22:05:36 2008
From: report at bugs.python.org (Georg Brandl)
Date: Mon, 28 Apr 2008 20:05:36 +0000
Subject: [issue1542407] httplib reads one byte per system call
Message-ID: <1209413132.85.0.626687311511.issue1542407@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Dupe of #2576.

----------
nosy: +georg.brandl
resolution:  -> duplicate
status: open -> closed
superseder:  -> httplib read() very slow due to lack of socket buffer

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1542407>
_____________________________________

From report at bugs.python.org  Mon Apr 28 23:01:21 2008
From: report at bugs.python.org (ndbecker)
Date: Mon, 28 Apr 2008 21:01:21 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>
Message-ID: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>


New submission from ndbecker <ndbecker2 at gmail.com>:

IIUC, current ioctl is not capable of handling arbitrary argument 
types.
This code will allow any arg type (such as structures with pointers to
embedded structures).

The code for _IOC is taken from linux and might not be portable.import 

-----
from ctypes import *

libc = CDLL ('/lib/libc.so.6')
#print libc.ioctl

def set_ioctl_argtype (arg_type):
    libc.ioctl.argtypes = (c_int, c_int, arg_type)

IOC_WRITE = 0x1

_IOC_NRBITS=	8
_IOC_TYPEBITS=	8
_IOC_SIZEBITS=	14
_IOC_DIRBITS=	2

_IOC_NRSHIFT=	0
_IOC_TYPESHIFT=	(_IOC_NRSHIFT+_IOC_NRBITS)
_IOC_SIZESHIFT=	(_IOC_TYPESHIFT+_IOC_TYPEBITS)
_IOC_DIRSHIFT=	(_IOC_SIZESHIFT+_IOC_SIZEBITS)


def IOC (dir, type, nr, size):
    return (((dir)  << _IOC_DIRSHIFT) | \
	 ((type) << _IOC_TYPESHIFT) | \
	 ((nr)   << _IOC_NRSHIFT) | \
	 ((size) << _IOC_SIZESHIFT))

def ioctl (fd, request, args):
    return libc.ioctl (fd, request, args)
----

Example (not complete):
class eos_dl_args_t (Structure):
    _fields_ = [("length", c_ulong),
                ("data", c_void_p)]

args = eos_dl_args_t()
args.length = len (c)
args.data = cast (pointer (c), c_void_p)

from eioctl import *

set_ioctl_argtype (POINTER (eos_dl_args_t))

EOS_IOC_MAGIC = 0xF4
request = IOC(IOC_WRITE, EOS_IOC_MAGIC, 0x00, 0) # ignore size

err = ioctl (fd, request, args)

----------
components: Extension Modules
messages: 65933
nosy: ndbecker
severity: normal
status: open
title: enhanced ioctl
type: feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Mon Apr 28 23:05:56 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Apr 2008 21:05:56 +0000
Subject: [issue2541] Unicode escape sequences not parsed in raw strings.
In-Reply-To: <1207196346.81.0.74505060161.issue2541@psf.upfronthosting.co.za>
Message-ID: <1209416756.44.0.223454223807.issue2541@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Fixed in r62568.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2541>
__________________________________

From report at bugs.python.org  Mon Apr 28 23:32:30 2008
From: report at bugs.python.org (Christophe Kalt)
Date: Mon, 28 Apr 2008 21:32:30 +0000
Subject: [issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError"
Message-ID: <1209418349.37.0.199774297021.issue1734346@psf.upfronthosting.co.za>


Christophe Kalt <python at ote.taranis.org> added the comment:

Any chance of this making it in sometime?
The current behaviour is rather limiting/annoying.

----------
nosy: +kalt

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1734346>
_____________________________________

From report at bugs.python.org  Mon Apr 28 23:42:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Apr 2008 21:42:55 +0000
Subject: [issue2713] Py3k warn on unicode escapes in raw strings
In-Reply-To: <1209418975.28.0.733174226817.issue2713@psf.upfronthosting.co.za>
Message-ID: <1209418975.28.0.733174226817.issue2713@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch gives a Py3k warning when a unicode escape occurs in a raw
unicode string.

----------
components: Unicode
files: unicode_escape_warn.patch
keywords: patch
messages: 65936
nosy: benjamin.peterson
severity: normal
status: open
title: Py3k warn on unicode escapes in raw strings
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10134/unicode_escape_warn.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2713>
__________________________________

From report at bugs.python.org  Mon Apr 28 23:47:59 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Mon, 28 Apr 2008 21:47:59 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209419279.53.0.360841699102.issue2690@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

Reviewing my own patch (range-sequence.diff), I've realized that it is 
being a bit too clever in handling x in range(..) where x is not an 
integer.  It seems that upon a failed PyLong_Check, range_contains should 
just do a linear search.  This is easy to implement, but I will wait for 
more feedback before posting further changes.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Tue Apr 29 00:11:43 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 28 Apr 2008 22:11:43 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>
Message-ID: <48164B99.3080406@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> IIUC, current ioctl is not capable of handling arbitrary argument 
> types.

Can you please be a bit more explicit? What limitation do you see in
fcntl.ioctl, and how does this fragment overcome the limitation?
AFAICT, they do exactly the same thing.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Tue Apr 29 00:13:53 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 28 Apr 2008 22:13:53 +0000
Subject: [issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError"
In-Reply-To: <1209418349.37.0.199774297021.issue1734346@psf.upfronthosting.co.za>
Message-ID: <48164C1E.1000904@v.loewis.de>


Martin v. L?wis <martin at v.loewis.de> added the comment:

> Any chance of this making it in sometime?

I'll see what I can do for 2.6, but perhaps it gets delayed until
2.7/3.1.

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1734346>
_____________________________________

From report at bugs.python.org  Tue Apr 29 00:14:31 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 28 Apr 2008 22:14:31 +0000
Subject: [issue1734346] patch for bug 1170311 "zipfile UnicodeDecodeError"
Message-ID: <1209420871.07.0.734841658059.issue1734346@psf.upfronthosting.co.za>


Changes by Martin v. L?wis <martin at v.loewis.de>:


----------
priority: normal -> high

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1734346>
_____________________________________

From report at bugs.python.org  Tue Apr 29 00:35:37 2008
From: report at bugs.python.org (ndbecker)
Date: Mon, 28 Apr 2008 22:35:37 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <48164B99.3080406@v.loewis.de>
Message-ID: <200804281835.26548.ndbecker2@gmail.com>


ndbecker <ndbecker2 at gmail.com> added the comment:

On Monday 28 April 2008, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
> > IIUC, current ioctl is not capable of handling arbitrary argument
> > types.
>
> Can you please be a bit more explicit? What limitation do you see in
> fcntl.ioctl, and how does this fragment overcome the limitation?
> AFAICT, they do exactly the same thing.
>

In the example I gave, the ioctl passes a structure:

class eos_dl_args_t (Structure):
    _fields_ = [("length", c_ulong),
                ("data", c_void_p)]

AFAIK, there is no way to do that with fcntl.ioctl, is there?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Tue Apr 29 00:55:45 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 28 Apr 2008 22:55:45 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>
Message-ID: <1209423344.83.0.2327186015.issue2712@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Passing structures is certainly possible. I'd try

args = struct.pack("iP", len(c), cast (pointer (c), c_void_p).value)
fcntl.ioctl(fd, request, args)

Alternatively,

args = eos_dl_args_t()
...
args_p = cast(pointer(args), c_void_ptr).value
fcntl.ioctl(fd, request, args_p)

should also work, IIUC.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Tue Apr 29 00:56:16 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Mon, 28 Apr 2008 22:56:16 +0000
Subject: [issue2713] Py3k warn on unicode escapes in raw strings
In-Reply-To: <1209418975.28.0.733174226817.issue2713@psf.upfronthosting.co.za>
Message-ID: <1209423376.1.0.635957601623.issue2713@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


Added file: http://bugs.python.org/file10135/unicode_escape_warn2.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2713>
__________________________________

From report at bugs.python.org  Tue Apr 29 01:21:55 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 28 Apr 2008 23:21:55 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209424915.53.0.757014027783.issue2690@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

My 2 cents: for me is more useful to have a unbound range() than to be
able to do a len() on it.

For me, range() should mimic a number generator: no limit, no length.

----------
nosy: +facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Tue Apr 29 01:23:00 2008
From: report at bugs.python.org (Gregory Dai)
Date: Mon, 28 Apr 2008 23:23:00 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>
Message-ID: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>


New submission from Gregory Dai <gregory.dai at gmail.com>:

Installed 2.5.2 Intel msi on
Windows Server 2003 Standard x64 Edition w/ SP2
on
Intel Xeon CPU 3.2GHz, 8GB of RAM

Selected IDLE from its startup menu item, but it refused to started.
Tried several times w/ the same outcome.

----------
components: IDLE
messages: 65943
nosy: qgd000
severity: normal
status: open
title: Unable to start IDLE on Windows Server 2003 x64 Edition w/ SP2
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________

From report at bugs.python.org  Tue Apr 29 01:25:50 2008
From: report at bugs.python.org (Facundo Batista)
Date: Mon, 28 Apr 2008 23:25:50 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>
Message-ID: <1209425150.9.0.633093364175.issue2714@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Disable all Operating System firewalls and try again (remember to enable
the firewalls again after the test).

This was a common problem in WinXP

----------
nosy: +facundobatista

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________

From report at bugs.python.org  Tue Apr 29 01:30:13 2008
From: report at bugs.python.org (Don Hanlen)
Date: Mon, 28 Apr 2008 23:30:13 +0000
Subject: [issue2710] error: (10035,
	'The socket operation could not complete without blocking')
In-Reply-To: <1209411891.51.0.595506842897.issue2710@psf.upfronthosting.co.za>
Message-ID: <1209425413.19.0.606906268702.issue2710@psf.upfronthosting.co.za>


Don Hanlen <dhanlen at owt.com> added the comment:

ah, lines 284-289 (the lines in question) need indenting 4 levels.  I
just DL'd 2.5.2, ran the code once, no problem, 2nd time, got the usual
error message.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2710>
__________________________________

From report at bugs.python.org  Tue Apr 29 01:42:44 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Mon, 28 Apr 2008 23:42:44 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>
Message-ID: <1209426164.0.0.733533633066.issue2714@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Can you please run IDLE in a console window, and report the exceptions
that you get? Invoke Lib\idlelib\idle.py to do so.

----------
nosy: +loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________

From report at bugs.python.org  Tue Apr 29 02:08:09 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Apr 2008 00:08:09 +0000
Subject: [issue2715] Remove carbon-specific code from binhex
In-Reply-To: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>
Message-ID: <1209427687.82.0.257836139376.issue2715@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

There is carbon-specific code in binhex. It really should go so that the 
module is completely platform-independent. This is especially pertinent 
for 3.0 as all Mac-specific modules are slated to go.

----------
components: Library (Lib)
messages: 65947
nosy: brett.cannon
priority: high
severity: normal
status: open
title: Remove carbon-specific code from binhex
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2715>
__________________________________

From report at bugs.python.org  Tue Apr 29 02:22:50 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Apr 2008 00:22:50 +0000
Subject: [issue2716] Reimplement audioop because of copyright issues
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>


New submission from Brett Cannon <brett at python.org>:

The audioop module contains a comment that is somewhat troubling from an 
IP standpoint:

  /* Code shamelessly stolen from sox, 12.17.7, g711.c
   ** (c) Craig Reese, Joe Campbell and Jeff Poskanzer 1989 */

Because of this it would be best to remove the current module and re-
implement it from scratch (or remove it entirely).

----------
components: Library (Lib)
messages: 65948
nosy: brett.cannon
priority: high
severity: normal
status: open
title: Reimplement audioop because of copyright issues
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2716>
__________________________________

From report at bugs.python.org  Tue Apr 29 03:23:36 2008
From: report at bugs.python.org (ndbecker)
Date: Tue, 29 Apr 2008 01:23:36 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <1209423344.83.0.2327186015.issue2712@psf.upfronthosting.co.za>
Message-ID: <200804282123.27023.ndbecker2@gmail.com>


ndbecker <ndbecker2 at gmail.com> added the comment:

On Monday 28 April 2008, Martin v. L?wis wrote:
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Passing structures is certainly possible. I'd try
>
> args = struct.pack("iP", len(c), cast (pointer (c), c_void_p).value)
> fcntl.ioctl(fd, request, args)
>
> Alternatively,
>
> args = eos_dl_args_t()
> ...
> args_p = cast(pointer(args), c_void_ptr).value
> fcntl.ioctl(fd, request, args_p)
>
> should also work, IIUC.
>

You are correct, both of the above work (at least on x86)

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Tue Apr 29 04:11:14 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Apr 2008 02:11:14 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>
Message-ID: <1209435073.95.0.897142629133.issue2712@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

So, should we close this?

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Tue Apr 29 04:11:28 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 29 Apr 2008 02:11:28 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>


New submission from Skip Montanaro <skip at pobox.com>:

On python-dev Guido lamented the fact that tempfile.mkstemp()
returns a file descriptor instead of a file object.  This
patch adds tempfile.mkstempf to remedy that.

----------
components: Library (Lib)
files: mkstempf.diff
keywords: easy, patch, patch
messages: 65951
nosy: skip.montanaro
priority: normal
severity: normal
status: open
title: tempfile.mkstempf
versions: Python 2.6
Added file: http://bugs.python.org/file10136/mkstempf.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Tue Apr 29 04:18:00 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Apr 2008 02:18:00 +0000
Subject: [issue2349] Py3K warn against assigning to True/False
In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za>
Message-ID: <1209435480.3.0.34719727259.issue2349@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

If Raymond says it's fine, then it's also fine by me.

----------
assignee: brett.cannon -> benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2349>
__________________________________

From report at bugs.python.org  Tue Apr 29 04:18:48 2008
From: report at bugs.python.org (Brett Cannon)
Date: Tue, 29 Apr 2008 02:18:48 +0000
Subject: [issue2343] Raise a Py3K warning when using a float where an int is
	expected
In-Reply-To: <1205777778.13.0.206701956987.issue2343@psf.upfronthosting.co.za>
Message-ID: <1209435528.67.0.172012867462.issue2343@psf.upfronthosting.co.za>


Brett Cannon <brett at python.org> added the comment:

Closing as out of date since it seems to have already been handled.

----------
resolution:  -> out of date
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2343>
__________________________________

From report at bugs.python.org  Tue Apr 29 04:17:05 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Apr 2008 02:17:05 +0000
Subject: [issue2716] Reimplement audioop because of copyright issues
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1209435425.03.0.914975548454.issue2716@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

I would support removing this in Py3k. It seems like a specialty module
not worth having in the standard library. Also, is this even being
maintained?

----------
nosy: +benjamin.peterson
versions: +Python 3.0

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2716>
__________________________________

From report at bugs.python.org  Tue Apr 29 06:06:14 2008
From: report at bugs.python.org (Paul Winkler)
Date: Tue, 29 Apr 2008 04:06:14 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1190232008.41.0.541816468426.issue1180@psf.upfronthosting.co.za>
Message-ID: <1209441974.19.0.777346227158.issue1180@psf.upfronthosting.co.za>


Paul Winkler <pw_lists at slinkp.com> added the comment:

In what way is the comment in core.py inaccurate? I only added the
phrase "and override config files", which is an important side effect of
parse_command_line().

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Tue Apr 29 06:38:29 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Tue, 29 Apr 2008 04:38:29 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209443907.54.0.0762069660923.issue2690@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

> For me, range() should mimic a number generator: no limit, no length.

That's itertools.count()

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Tue Apr 29 07:48:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 29 Apr 2008 05:48:40 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <1209416481.27.0.651888949056.issue2712@psf.upfronthosting.co.za>
Message-ID: <1209448120.12.0.322576546146.issue2712@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

I think we should close it.

----------
resolution:  -> works for me
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Tue Apr 29 08:31:18 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Apr 2008 06:31:18 +0000
Subject: [issue2713] Py3k warn on unicode escapes in raw strings
In-Reply-To: <1209418975.28.0.733174226817.issue2713@psf.upfronthosting.co.za>
Message-ID: <1209450678.35.0.65293556865.issue2713@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

This patch changes the raw-unicode-escape code to warn. Marc-Andre, is
this OK?

----------
assignee:  -> lemburg
nosy: +georg.brandl, lemburg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2713>
__________________________________

From report at bugs.python.org  Tue Apr 29 12:27:37 2008
From: report at bugs.python.org (ndbecker)
Date: Tue, 29 Apr 2008 10:27:37 +0000
Subject: [issue2712] enhanced ioctl
In-Reply-To: <1209435073.95.0.897142629133.issue2712@psf.upfronthosting.co.za>
Message-ID: <200804290627.18129.ndbecker2@gmail.com>


ndbecker <ndbecker2 at gmail.com> added the comment:

OK.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2712>
__________________________________

From report at bugs.python.org  Tue Apr 29 13:07:50 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Apr 2008 11:07:50 +0000
Subject: [issue1950] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za>
Message-ID: <1209467270.09.0.301845633996.issue1950@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

@@ -2195,7 +2200,7 @@
 				}
 				return Py_None;
 			}
-			len = lastdot - start;
+			len = (size_t)(lastdot - start);
 			if (len >= MAXPATHLEN) {
 				PyErr_SetString(PyExc_ValueError,
 						"Module name too long");

The above cast needs to be (Py_ssize_t). size_t is an unsigned length type.

----------
nosy: +lemburg

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1950>
__________________________________

From report at bugs.python.org  Tue Apr 29 13:25:39 2008
From: report at bugs.python.org (=?utf-8?q?Andr=C3=A9_Malo?=)
Date: Tue, 29 Apr 2008 11:25:39 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209468338.4.0.0608180857338.issue2717@psf.upfronthosting.co.za>


Andr? Malo <nd at perlig.de> added the comment:

It should catch OSError on fdopen, close fd and reraise, I think.

----------
nosy: +ndparker

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Tue Apr 29 13:31:54 2008
From: report at bugs.python.org (Marc-Andre Lemburg)
Date: Tue, 29 Apr 2008 11:31:54 +0000
Subject: [issue1950] Potential overflows due to incorrect usage of
	PyUnicode_AsString.
In-Reply-To: <1201473895.18.0.771876708371.issue1950@psf.upfronthosting.co.za>
Message-ID: <1209468714.78.0.57491491596.issue1950@psf.upfronthosting.co.za>


Marc-Andre Lemburg <mal at egenix.com> added the comment:

BTW: The API PyUnicode_AsString() is pretty useless by itself - there's
no way to access the size information of the returned string without
again going to the Unicode object.

I'd suggest to remove the API altogether and not only deprecating it.

Furthermore, the API PyUnicode_AsStringAndSize() does not follow the API
signature of PyString_AsStringAndSize() in that it passes back the
pointer to the string as output parameter. That should be changed as
well. Note that PyString_AsStringAndSize() already does this for both
8-bit strings and Unicode, so the special Unicode API is not really
needed at all or you may want to rename PyString_AsStringAndSize() to
PyUnicode_AsStringAndSize().

Finally, since there are many cases where the string buffer contents are
copied to a new buffer, it's probably worthwhile to add a new API which
does the copying straight away and also deals with the overflow cases in
a central place. I'd suggest PyUnicode_AsChar() (with an API like
PyUnicode_AsWideChar()).

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1950>
__________________________________

From report at bugs.python.org  Tue Apr 29 13:40:20 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 Apr 2008 11:40:20 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209469220.6.0.0637064645457.issue2690@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

It also isn't what range() and xrange() are used for now in 2.x. range()
returns an actual list, hence is limited to sequences that fit in a
reasonable amount of memory, and xrange() doesn't support values greater
than sys.maxint at all (as it uses C ints for its internal storage of
the start, stop and step values).

With itertools.count() available for the unbounded iterator case, I
think making range() mimic its 2.x counterpart as closely as possible
(without the memory inefficiency) will be quite valuable.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Tue Apr 29 13:50:40 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 29 Apr 2008 11:50:40 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209469840.53.0.416578189372.issue2717@psf.upfronthosting.co.za>


Skip Montanaro <skip at pobox.com> added the comment:

Thanks.  New patch attached.

Added file: http://bugs.python.org/file10137/mkstempf.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Tue Apr 29 13:51:26 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 29 Apr 2008 11:51:26 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209469886.97.0.787636651194.issue2717@psf.upfronthosting.co.za>


Changes by Skip Montanaro <skip at pobox.com>:


Removed file: http://bugs.python.org/file10136/mkstempf.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Tue Apr 29 14:25:14 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 Apr 2008 12:25:14 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209471912.32.0.488846169388.issue2717@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

What does this offer over using NamedTemporaryFile(delete=False)?

----------
nosy: +ncoghlan

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Tue Apr 29 15:55:24 2008
From: report at bugs.python.org (Skip Montanaro)
Date: Tue, 29 Apr 2008 13:55:24 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209471912.32.0.488846169388.issue2717@psf.upfronthosting.co.za>
Message-ID: <18455.10378.447139.657350@montanaro-dyndns-org.local>


Skip Montanaro <skip at pobox.com> added the comment:

Nick> What does this offer over using NamedTemporaryFile(delete=False)?

Nothing I suppose.  I wasn't aware of the similarity of the two (I always
use mkstemp()) or the delete arg to NamedTemporaryFile, and assumed Guido's
complaint about mkstemp's shortcoming indicated that the functionality he
desired didn't exist.

Skip

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Tue Apr 29 15:58:15 2008
From: report at bugs.python.org (Phillip J. Eby)
Date: Tue, 29 Apr 2008 13:58:15 +0000
Subject: [issue1180] Option to ignore or substitute ~/.pydistutils.cfg
In-Reply-To: <1209441974.19.0.777346227158.issue1180@psf.upfronthosting. co.za>
Message-ID: <20080429135810.4FA193A4109@sparrow.telecommunity.com>


Phillip J. Eby <pje at telecommunity.com> added the comment:

Oh, I thought you meant that it overrides *which* config files -- 
i.e., implied that it was handling --no-user-config.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1180>
__________________________________

From report at bugs.python.org  Tue Apr 29 16:53:36 2008
From: report at bugs.python.org (Colin Watson)
Date: Tue, 29 Apr 2008 14:53:36 +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: <1209480816.53.0.344901369067.issue1652@psf.upfronthosting.co.za>


Colin Watson <cjwatson at users.sourceforge.net> added the comment:

2.6 is fine if that's what the release process dictates; I don't want it
to be lost, that's all.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
__________________________________

From report at bugs.python.org  Tue Apr 29 17:08:36 2008
From: report at bugs.python.org (Jeroen van der Ham)
Date: Tue, 29 Apr 2008 15:08:36 +0000
Subject: [issue2718] Logging.basicConfig ignores level=0
In-Reply-To: <1209481716.33.0.891360600754.issue2718@psf.upfronthosting.co.za>
Message-ID: <1209481716.33.0.891360600754.issue2718@psf.upfronthosting.co.za>


New submission from Jeroen van der Ham <vdham at uva.nl>:

logging.basicConfig seems to ignore level=0:

>>> import logging
>>> logging.basicConfig(level=0)
>>> logging.getLogger().getEffectiveLevel()
30


>>> import logging
>>> logging.basicConfig(level=10)
>>> logging.getLogger().getEffectiveLevel()
10

----------
components: Library (Lib)
messages: 65969
nosy: vdham
severity: normal
status: open
title: Logging.basicConfig ignores level=0
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2718>
__________________________________

From report at bugs.python.org  Tue Apr 29 17:15:05 2008
From: report at bugs.python.org (Vinay Sajip)
Date: Tue, 29 Apr 2008 15:15:05 +0000
Subject: [issue2718] Logging.basicConfig ignores level=0
In-Reply-To: <1209481716.33.0.891360600754.issue2718@psf.upfronthosting.co.za>
Message-ID: <1209482103.98.0.334279713129.issue2718@psf.upfronthosting.co.za>


Vinay Sajip <vinay_sajip at yahoo.co.uk> added the comment:

Already fixed in SVN.

Change was: "if level:" -> "if level is not None:" in basicConfig().

----------
nosy: +vsajip
resolution:  -> duplicate
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2718>
__________________________________

From report at bugs.python.org  Tue Apr 29 17:40:37 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Tue, 29 Apr 2008 15:40:37 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209483637.15.0.380862097163.issue2717@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

The delete flag on NamedTemporaryFile is new for 2.6, so it isn't
surprising people aren't familiar with it. The other advantage of using
NamedTemporaryFile is that its name attribute is set correctly, which
isn't the case when using mkstemp directly.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Tue Apr 29 19:24:51 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Apr 2008 17:24:51 +0000
Subject: [issue2685] Add -mieee to compile flags, when available
In-Reply-To: <1209071512.37.0.789314022887.issue2685@psf.upfronthosting.co.za>
Message-ID: <1209489891.62.0.524790741993.issue2685@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Done in r62499

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2685>
__________________________________

From report at bugs.python.org  Tue Apr 29 19:34:07 2008
From: report at bugs.python.org (Mark Dickinson)
Date: Tue, 29 Apr 2008 17:34:07 +0000
Subject: [issue1496032] test_float segfaults with SIGFPE on FreeBSD 6.0 / Alpha
Message-ID: <1209490447.75.0.830638680162.issue1496032@psf.upfronthosting.co.za>


Mark Dickinson <dickinsm at gmail.com> added the comment:

Adding -mieee didn't fix the math and cmath problems.  Should I revert 
the change in r62499, or leave it in?  It seems to me that having -mieee 
is a good thing on the whole.  The main reason to not want IEEE 754 
conformance would be speed.

It looks like the math and cmath failures are due to libm behaviour;  
either (1) libm is making no attempt to be IEEE compliant, or (2) it's 
setting errno in places that it shouldn't, or (3) it's trying to be IEEE 
compliant but is buggy.  I'm not sure how to proceed.  Would it be okay 
to check in some temporary autoconf tests to help identify the source of 
the failures, and remove them later?

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1496032>
_____________________________________

From report at bugs.python.org  Tue Apr 29 19:35:51 2008
From: report at bugs.python.org (Gregory Dai)
Date: Tue, 29 Apr 2008 17:35:51 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209426164.0.0.733533633066.issue2714@psf.upfronthosting.co.za>
Message-ID: <ce347e580804291035t3b649e5dlf570ee0518f08775@mail.gmail.com>


Gregory Dai <gregory.dai at gmail.com> added the comment:

After removing my Ruby installation, I got the following:

"
C:\lang\Python25>Lib\idlelib\idle.py
Traceback (most recent call last):
  File "C:\lang\Python25\Lib\idlelib\idle.py", line 21, in <module>
    idlelib.PyShell.main()
  File "C:\lang\Python25\lib\idlelib\PyShell.py", line 1390, in main
    root = Tk(className="Idle")
  File "C:\lang\Python25\lib\lib-tk\Tkinter.py", line 1636, in __init__
    self.tk = _tkinter.create(screenName, baseName, className, interactive,
wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable init.tcl in the following
directories:
    {c:\ruby\tcl\lib\tcl8.3} {c:\ruby\tcl\lib\tcl8.3} c:/ruby/tcl/lib/tcl8.4
C:/lang/Python25/lib/tcl8.4 C:/lang/lib/tcl8.4 C:/lib/tcl8.4 C:/lang/library
C:/library C:/tcl8.4.12/library

This probably means that Tcl wasn't installed properly.
"

The tcl was installed as part of the distribution in the .msi file, how
could it not be installed properly?

On Mon, Apr 28, 2008 at 4:42 PM, Martin v. L?wis <report at bugs.python.org>
wrote:

>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Can you please run IDLE in a console window, and report the exceptions
> that you get? Invoke Lib\idlelib\idle.py to do so.
>
> ----------
> nosy: +loewis
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2714>
> __________________________________
>

Added file: http://bugs.python.org/file10138/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080429/13822337/attachment.txt>

From report at bugs.python.org  Tue Apr 29 19:37:47 2008
From: report at bugs.python.org (Gregory Dai)
Date: Tue, 29 Apr 2008 17:37:47 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209425150.9.0.633093364175.issue2714@psf.upfronthosting.co.za>
Message-ID: <ce347e580804291037w324f7a6dp7497eb49fd8bdf32@mail.gmail.com>


Gregory Dai <gregory.dai at gmail.com> added the comment:

Martin Loewis had me start IDLE from a DOS prompt. The backtrace pointed to
an improper installation of tcl.

On Mon, Apr 28, 2008 at 4:25 PM, Facundo Batista <report at bugs.python.org>
wrote:

>
> Facundo Batista <facundo at taniquetil.com.ar> added the comment:
>
> Disable all Operating System firewalls and try again (remember to enable
> the firewalls again after the test).
>
> This was a common problem in WinXP
>
> ----------
> nosy: +facundobatista
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2714>
> __________________________________
>

Added file: http://bugs.python.org/file10139/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080429/76bd19d5/attachment-0001.txt>

From report at bugs.python.org  Tue Apr 29 20:23:17 2008
From: report at bugs.python.org (Tal Einat)
Date: Tue, 29 Apr 2008 18:23:17 +0000
Subject: [issue2053] IDLE - standardize dialogs
In-Reply-To: <1202515821.86.0.159216664847.issue2053@psf.upfronthosting.co.za>
Message-ID: <1209493396.94.0.275092230665.issue2053@psf.upfronthosting.co.za>


Tal Einat <taleinat at users.sourceforge.net> added the comment:

uploaded a single comprehensive patch file

Added file: http://bugs.python.org/file10140/IDLE_standardize_dialogs.080429.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2053>
__________________________________

From report at bugs.python.org  Tue Apr 29 21:44:15 2008
From: report at bugs.python.org (Greg Couch)
Date: Tue, 29 Apr 2008 19:44:15 +0000
Subject: [issue2693] IDLE  doesn't work with Tk 8.5
In-Reply-To: <1209166587.6.0.537428901937.issue2693@psf.upfronthosting.co.za>
Message-ID: <1209498254.96.0.781952927448.issue2693@psf.upfronthosting.co.za>


Greg Couch <gregcouch at gmail.com> added the comment:

Starting over:

The goal of this patch is to get Tk 8.5 to work with Python 2.5's Idle.
 It currently fails with a ValueError, "invalid literal for int() with
base 10: '(72,'" (the 72 changes depending on what was typed in).

The root cause of bug is due to an interaction between Tk 8.5 returning
more results as Tcl lists, instances of Idle's WidgetRedirector class
that wrap widget Tcl commands with the WidgetRedirector's dispatch
method, and _tkinter's internal PythonCmd function that stringifies
anything its gets from Python.  What happens is that when a Python
method is called on a redirected widget, the corresponding Tcl method is
called using the WidgetRedirector's imposter widget command, which calls
the WidgetRedirector's dispatch method from Tcl, which then invokes the
original widget Tcl command, and if that command returns a Tcl list,
_tkinter converts it to a Python tuple, the dispatch method returns the
tuple into _tkinter, _tkinter stringifies it so it looks like a Python
tuple representation instead of a Tcl list representation, returns it to
Tkinter which tries to parse it like a Tcl list representation, and
causes the ValueError.

The correct fix is already in Python 2.6a2, which is changing Text
class' index method in Tkinter.py to return a string, and changing
_tkinter's PythonCmd to convert Python objects to equivalent Tcl
objects.  Unfortunately backporting those simple changes to Python 2.5
cause a "SystemError: Objects/tupleobject.c:89: bad argument to internal
function".  While that is worth further investigation, Python 2.6a2
doesn't have that problem and a simple alternative fix is available for
Python 2.5, so that is for someone else to do.

The alternative fix that works in Python 2.5 is to make sure that the
Tcl list string representation is used for Python tuples that are
returned to _tkinter's PythonCmd.  Those changes are confined to the
WidgetRedirector's dispatch method.  Line 126 of WidgetRedirector.py:

    return self.tk.call((self.orig, operation) + args)

is replaced with:

    result = self.tk.call((self.orig, operation) + args)
    if isinstance(result, tuple):
        # convert to string ourselves so we get a Tcl list
        # that can be converted back into a tuple by Tkinter
        result = '{%s}' % '} {'.join(map(str, result))
    return result

For Tk 8.4, the if clause is never invoked because Idle does not use any
of the Tk 8.4 methods that return Tcl lists (luckily).  In Tk 8.5, the
additional quoting is only needed for the Tk text widget's tag names and
tag ranges commands when spaces are used for tag names (explicitly not
recommended), all other uses are lists of numbers.  Since none of Idle's
Text tags have spaces in them, that line can safely be replaced with:

        result = ' '.join(map(str, result))

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2693>
__________________________________

From report at bugs.python.org  Tue Apr 29 21:44:33 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Apr 2008 19:44:33 +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: <1209498273.51.0.693332027899.issue1652@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Martin, what do you think?

----------
assignee:  -> loewis

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1652>
__________________________________

From report at bugs.python.org  Tue Apr 29 23:02:29 2008
From: report at bugs.python.org (Georg Brandl)
Date: Tue, 29 Apr 2008 21:02:29 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>


New submission from Georg Brandl <georg at python.org>:

Backporting 3.0's next() builtin.

There's no change w.r.t. __next__/next, that is tracked in #2336.

----------
assignee: gvanrossum
components: Interpreter Core
files: nextbackport.diff
keywords: 26backport, patch
messages: 65980
nosy: georg.brandl, gvanrossum
priority: critical
severity: normal
status: open
title: Backport next()
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file10141/nextbackport.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Tue Apr 29 23:06:06 2008
From: report at bugs.python.org (Facundo Batista)
Date: Tue, 29 Apr 2008 21:06:06 +0000
Subject: [issue2690] Precompute range length
In-Reply-To: <1209137521.96.0.492875701205.issue2690@psf.upfronthosting.co.za>
Message-ID: <1209503166.52.0.150443415346.issue2690@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Fair enough, specially if in the documentation of range() we put "if you
want a unbound, no limit, number generator, use itertools.count()" (or
something well written in english ;) ).

Thanks!

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2690>
__________________________________

From report at bugs.python.org  Tue Apr 29 23:09:52 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Apr 2008 21:09:52 +0000
Subject: [issue2409] regrtest should not just skip imports that fail
In-Reply-To: <1205875348.54.0.487257679211.issue2409@psf.upfronthosting.co.za>
Message-ID: <1209503392.86.0.550319709555.issue2409@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
type:  -> behavior

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2409>
__________________________________

From report at bugs.python.org  Tue Apr 29 23:42:06 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Apr 2008 21:42:06 +0000
Subject: [issue2720] make compiling struct be passed around to all ast helpers
In-Reply-To: <1209505325.8.0.542617617713.issue2720@psf.upfronthosting.co.za>
Message-ID: <1209505325.8.0.542617617713.issue2720@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

This patch causes struct *compiling to be passed around to all of the
ast helper functions. Since most functions already take it, this makes
it more consistent as a whole. Also, the filename (from
compiling->c_filename) is needed to issue warnings with PyErr_WarnExplicit.

----------
components: Interpreter Core
files: ast_compiling_struct.patch
keywords: patch
messages: 65982
nosy: benjamin.peterson
severity: normal
status: open
title: make compiling struct be passed around to all ast helpers
type: feature request
versions: Python 2.6
Added file: http://bugs.python.org/file10142/ast_compiling_struct.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2720>
__________________________________

From report at bugs.python.org  Tue Apr 29 23:44:21 2008
From: report at bugs.python.org (Christian Heimes)
Date: Tue, 29 Apr 2008 21:44:21 +0000
Subject: [issue2720] make compiling struct be passed around to all ast helpers
In-Reply-To: <1209505325.8.0.542617617713.issue2720@psf.upfronthosting.co.za>
Message-ID: <1209505461.13.0.921093199907.issue2720@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

+1 for the feature

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2720>
__________________________________

From report at bugs.python.org  Tue Apr 29 23:47:40 2008
From: report at bugs.python.org (=?utf-8?q?Martin_v._L=C3=B6wis?=)
Date: Tue, 29 Apr 2008 21:47:40 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>
Message-ID: <1209505660.73.0.126910957644.issue2714@psf.upfronthosting.co.za>


Martin v. L?wis <martin at v.loewis.de> added the comment:

Check whether the TCL_DIR or TK_DIR environment variables are set. If
so, unset them.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________

From report at bugs.python.org  Tue Apr 29 23:48:55 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Apr 2008 21:48:55 +0000
Subject: [issue2349] Py3K warn against assigning to True/False
In-Reply-To: <1205781558.49.0.8223061173.issue2349@psf.upfronthosting.co.za>
Message-ID: <1209505735.57.0.398495919241.issue2349@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

As I looked over the code again, I realized that it doesn't help to just
do a normal warning while compiling because the line number isn't
supplied. You have to use PyWarn_Explicit for that (see the warning
about backquotes). Since the filename (in the compiling struct) isn't
passed around to all ast helpers, you can't warn in every function.
Therefore, I have #2720.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2349>
__________________________________

From report at bugs.python.org  Wed Apr 30 00:26:31 2008
From: report at bugs.python.org (Paul Winkler)
Date: Tue, 29 Apr 2008 22:26:31 +0000
Subject: [issue2721] unittest.makeSuite undocumented and "obsolete" - but what
	to use instead?
In-Reply-To: <1209507990.95.0.785874849779.issue2721@psf.upfronthosting.co.za>
Message-ID: <1209507990.95.0.785874849779.issue2721@psf.upfronthosting.co.za>


New submission from Paul Winkler <pw_lists at slinkp.com>:

A comment in unittest.py says "these functions should be considered
obsolete". But I've seen a lot of code in the wild still using
unittest.makeSuite(MyTestCase)... in fact it's used frequently in the
python standard library tests.

And I don't see a replacement for this use case: given a subclass of
TestCase, conveniently turn all its test* methods into a suite. How are
we supposed to do that now?

Either makeSuite should be documented, or a suitable replacement should
be provided and documented.

----------
assignee: georg.brandl
components: Documentation
messages: 65986
nosy: georg.brandl, slinkp
severity: normal
status: open
title: unittest.makeSuite undocumented and "obsolete" - but what to use instead?
versions: Python 2.4, Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2721>
__________________________________

From report at bugs.python.org  Wed Apr 30 00:41:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Tue, 29 Apr 2008 22:41:40 +0000
Subject: [issue2721] unittest.makeSuite undocumented and "obsolete" - but what
	to use instead?
In-Reply-To: <1209507990.95.0.785874849779.issue2721@psf.upfronthosting.co.za>
Message-ID: <1209508900.1.0.712935397813.issue2721@psf.upfronthosting.co.za>


Changes by Benjamin Peterson <musiccomposition at gmail.com>:


----------
nosy: +purcell

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2721>
__________________________________

From report at bugs.python.org  Wed Apr 30 01:52:23 2008
From: report at bugs.python.org (Lars Immisch)
Date: Tue, 29 Apr 2008 23:52:23 +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: <1209513143.8.0.669546063232.issue1856@psf.upfronthosting.co.za>


Changes by Lars Immisch <lars at ibp.de>:


----------
nosy: +larsimmisch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1856>
__________________________________

From report at bugs.python.org  Wed Apr 30 02:01:55 2008
From: report at bugs.python.org (Jean-Paul Calderone)
Date: Wed, 30 Apr 2008 00:01:55 +0000
Subject: [issue2722] os.getcwd fails for long path names on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>


New submission from Jean-Paul Calderone <exarkun at divmod.com>:

$ python -c "print len('`pwd`'); import os; print os.getcwd()"
1174
Traceback (most recent call last):
  File "<string>", line 1, in ?
OSError: [Errno 34] Numerical result out of range
$

The getcwd man page documents the ERANGE failure and suggests that the
calling application allocate a larger buffer and try again.

----------
components: Library (Lib)
messages: 65987
nosy: exarkun
severity: normal
status: open
title: os.getcwd fails for long path names on linux
versions: Python 2.4

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2722>
__________________________________

From report at bugs.python.org  Wed Apr 30 03:10:20 2008
From: report at bugs.python.org (Eric Smith)
Date: Wed, 30 Apr 2008 01:10:20 +0000
Subject: [issue2526] str.format() :n format does not appear to work for int
	and float
In-Reply-To: <1207049726.03.0.00767179543802.issue2526@psf.upfronthosting.co.za>
Message-ID: <1209517820.34.0.988543863481.issue2526@psf.upfronthosting.co.za>


Eric Smith <eric at trueblade.com> added the comment:

Committed fix in r62586.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2526>
__________________________________

From report at bugs.python.org  Wed Apr 30 06:36:36 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 04:36:36 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

On Tue, Apr 29, 2008 at 10:36 PM, Guido van Rossum <guido at python.org> 
wrote:
..
>  Let's also fix __len__() so that it returns sys.{maxint,maxsize} when
>  the result doesn't fit in a Py_ssize_t.

http://mail.python.org/pipermail/python-3000/2008-April/013343.html

With attached patch given

class x:
    def __len__(self):
        return 2**100

len(x()) and len(range(2**100)) will return sys.maxsize.

----------
components: Interpreter Core
files: len.diff
keywords: patch
messages: 65989
nosy: belopolsky
severity: normal
status: open
title: Truncate __len__() at sys.maxsize
versions: Python 3.0
Added file: http://bugs.python.org/file10143/len.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
__________________________________

From report at bugs.python.org  Wed Apr 30 06:39:26 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 04:39:26 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1209530366.89.0.522035834261.issue2723@psf.upfronthosting.co.za>


Changes by Alexander Belopolsky <belopolsky at users.sourceforge.net>:


----------
type:  -> feature request

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
__________________________________

From report at bugs.python.org  Wed Apr 30 07:56:02 2008
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 30 Apr 2008 05:56:02 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1209534961.68.0.89801580523.issue2601@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

For those trying to follow along at home: best I can tell we have 3
other issues on this: #1092502 and #1389051 are dupes of an initial bug,
but the fix for those bugs caused regressions reported in this bug and
in #2632.  To try and reduce confusion I'm closing this as a dupe of
#2632 which has a patch for review.

----------
nosy: +mhammond
superseder:  -> performance problem in socket._fileobject.read

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Wed Apr 30 07:56:14 2008
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 30 Apr 2008 05:56:14 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1209534974.82.0.984058033631.issue2601@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Wed Apr 30 07:59:01 2008
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 30 Apr 2008 05:59:01 +0000
Subject: [issue2601] [regression] reading from a urllib2 file descriptor
	happens byte-at-a-time
In-Reply-To: <1207689330.25.0.805272484455.issue2601@psf.upfronthosting.co.za>
Message-ID: <1209535141.27.0.521451370837.issue2601@psf.upfronthosting.co.za>


Changes by Mark Hammond <mhammond at users.sourceforge.net>:


----------
resolution:  -> duplicate

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2601>
__________________________________

From report at bugs.python.org  Wed Apr 30 07:59:21 2008
From: report at bugs.python.org (Mark Hammond)
Date: Wed, 30 Apr 2008 05:59:21 +0000
Subject: [issue1092502] Memory leak in socket.py on Mac OS X
Message-ID: <1209535161.04.0.877981190412.issue1092502@psf.upfronthosting.co.za>


Mark Hammond <mhammond at users.sourceforge.net> added the comment:

FYI, #2632 is tracking a regression caused by this change.

----------
nosy: +mhammond

_____________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1092502>
_____________________________________

From report at bugs.python.org  Wed Apr 30 08:04:32 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Apr 2008 06:04:32 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209535472.82.0.582683298988.issue2719@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

ISTM, the only value added by next(g) is that it replaces g.next() with 
a more conventional spelling, g.__next__().  Since 2.6 still has g.next
(),I don't see how this backport adds value.  It does however create a 
second way to do it that will be confusing to some remaining in the 2.x 
world.  I think we should avoid double spellings in 2.6 except in cases 
where the 2-to-3 converter would need help.

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 08:29:59 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 06:29:59 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209536998.92.0.675374895697.issue2719@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

IMO having next() in 2.6 helps since if you use it consistently you
don't have to care about calling .next() or .__next__().

Also, I don't see how this is different from having e.g. reduce() and
functools.reduce() in 2.6.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 08:32:12 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Apr 2008 06:32:12 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1209537132.33.0.867916991223.issue2723@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

Wouldn't it be better to raise OverflowError or somesuch?

----------
nosy: +rhettinger

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
__________________________________

From report at bugs.python.org  Wed Apr 30 08:37:24 2008
From: report at bugs.python.org (Raymond Hettinger)
Date: Wed, 30 Apr 2008 06:37:24 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209537444.6.0.00305789678274.issue2719@psf.upfronthosting.co.za>


Raymond Hettinger <rhettinger at users.sourceforge.net> added the comment:

The problem is with the "if you use it consistently" premise.  That 
will not hold in an environment with legacy code, multiple programmers, 
lots of code in ASPN recipes and published materials, and third-party 
modules.  A patch like this dooms Py2.6 programmers to seeing both of 
these forms intermixed throughout the code base.  This is *not* a win.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 10:47:55 2008
From: report at bugs.python.org (Sandeep Sabnani)
Date: Wed, 30 Apr 2008 08:47:55 +0000
Subject: [issue2724] Error in Python tutorial
	(http://docs.python.org/tut/node6.html)
In-Reply-To: <1209545263.37.0.933925653998.issue2724@psf.upfronthosting.co.za>
Message-ID: <1209545263.37.0.933925653998.issue2724@psf.upfronthosting.co.za>


New submission from Sandeep Sabnani <sandeepsabnani at gmail.com>:

Section 4.4 on page http://docs.python.org/tut/node6.html has a for loop
which uses the range function. However, the displayed output of that
loop is not correct. I ran the same code and got the output as follows:

3 is a prime number
4 = 2 * 2
5 is a prime number
5 is a prime number
5 is a prime number
6 = 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 = 2 * 4
9 is a prime number
9 = 3 * 3

Can this be corrected in the tutorial as it can be confusing for a
python newbie!

Thanks!

----------
assignee: georg.brandl
components: Documentation
messages: 65996
nosy: georg.brandl, sandeepsabnani
severity: normal
status: open
title: Error in Python tutorial (http://docs.python.org/tut/node6.html)
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2724>
__________________________________

From report at bugs.python.org  Wed Apr 30 10:56:38 2008
From: report at bugs.python.org (Matthias Klose)
Date: Wed, 30 Apr 2008 08:56:38 +0000
Subject: [issue2632] performance problem in socket._fileobject.read
In-Reply-To: <1208197816.87.0.564994342754.issue2632@psf.upfronthosting.co.za>
Message-ID: <1209545798.11.0.994149840551.issue2632@psf.upfronthosting.co.za>


Changes by Matthias Klose <doko at debian.org>:


----------
nosy: +doko

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2632>
__________________________________

From report at bugs.python.org  Wed Apr 30 11:02:26 2008
From: report at bugs.python.org (Amaury Forgeot d'Arc)
Date: Wed, 30 Apr 2008 09:02:26 +0000
Subject: [issue2724] Error in Python tutorial
	(http://docs.python.org/tut/node6.html)
In-Reply-To: <1209545263.37.0.933925653998.issue2724@psf.upfronthosting.co.za>
Message-ID: <1209546146.03.0.35702440053.issue2724@psf.upfronthosting.co.za>


Amaury Forgeot d'Arc <amauryfa at gmail.com> added the comment:

No, the example is correct, and gives the expected output.

>From the output you show, I suppose that you indented the "else:" clause
incorrectly: it should align with the "for" loop, not the "if" statement.

The "for...else.." construct is precisely the point of this paragraph.

----------
nosy: +amaury.forgeotdarc
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2724>
__________________________________

From report at bugs.python.org  Wed Apr 30 11:54:12 2008
From: report at bugs.python.org (Sandeep Sabnani)
Date: Wed, 30 Apr 2008 09:54:12 +0000
Subject: [issue2724] Error in Python tutorial
	(http://docs.python.org/tut/node6.html)
In-Reply-To: <1209545263.37.0.933925653998.issue2724@psf.upfronthosting.co.za>
Message-ID: <1209549251.19.0.49829454909.issue2724@psf.upfronthosting.co.za>


Sandeep Sabnani <sandeepsabnani at gmail.com> added the comment:

Oh yes! Thanks for clearing my doubt and apologies for the silly error.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2724>
__________________________________

From report at bugs.python.org  Wed Apr 30 15:12:00 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Apr 2008 13:12:00 +0000
Subject: [issue2722] os.getcwd fails for long path names on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1209561120.47.0.603074576827.issue2722@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2722>
__________________________________

From report at bugs.python.org  Wed Apr 30 15:12:32 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Apr 2008 13:12:32 +0000
Subject: [issue2721] unittest.makeSuite undocumented and "obsolete" - but what
	to use instead?
In-Reply-To: <1209507990.95.0.785874849779.issue2721@psf.upfronthosting.co.za>
Message-ID: <1209561152.78.0.0285873020015.issue2721@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2721>
__________________________________

From report at bugs.python.org  Wed Apr 30 15:14:00 2008
From: report at bugs.python.org (Giampaolo Rodola')
Date: Wed, 30 Apr 2008 13:14:00 +0000
Subject: [issue2717] tempfile.mkstempf
In-Reply-To: <1209435088.71.0.390956063195.issue2717@psf.upfronthosting.co.za>
Message-ID: <1209561240.07.0.349666515479.issue2717@psf.upfronthosting.co.za>


Changes by Giampaolo Rodola' <billiejoex at users.sourceforge.net>:


----------
nosy: +giampaolo.rodola

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2717>
__________________________________

From report at bugs.python.org  Wed Apr 30 14:08:09 2008
From: report at bugs.python.org (Thomas Lee)
Date: Wed, 30 Apr 2008 12:08:09 +0000
Subject: [issue2725] Handle ASDLSyntaxErrors gracefully
In-Reply-To: <1209557288.23.0.65253319009.issue2725@psf.upfronthosting.co.za>
Message-ID: <1209557288.23.0.65253319009.issue2725@psf.upfronthosting.co.za>


New submission from Thomas Lee <tom at vector-seven.com>:

The current code in Parser/asdl.py doesn't handle syntax errors very
well. A minor problem to be sure, since the net result is the same (i.e.
build fails), but the error message being displayed is entirely
unhelpful to the developer.

The attached patch will display the error message as was seemingly intended.

This probably affects earlier versions (including python-trunk), but I
haven't tested.

----------
components: Build
files: fix-asdl-errors.patch
keywords: patch
messages: 65999
nosy: thomas.lee
severity: normal
status: open
title: Handle ASDLSyntaxErrors gracefully
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file10144/fix-asdl-errors.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2725>
__________________________________

From report at bugs.python.org  Wed Apr 30 15:39:42 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Apr 2008 13:39:42 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209562779.39.0.523036226162.issue2719@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

I think it's important to make this available in 2.6; it will let people
writing 3.0-oriented code in 2.6 (as several developers are planning to
do) do the right thing for this syntax.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 15:42:19 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 13:42:19 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209537132.33.0.867916991223.issue2723@psf.upfronthosting.co.za>
Message-ID: <d38f5330804300641l45c77e8awf3bc392645b072e3@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 30, 2008 at 2:32 AM, Raymond Hettinger
<report at bugs.python.org> wrote:

>  Wouldn't it be better to raise OverflowError or somesuch?

Thats what the current code does.  I don't know what Guido's full
rationale is, but I guess the idea is that len(..) is not supposed to
raise an exception on sizeable objects.

Here is a quote from another message:

"""
__len__ will always be problematic when there are more values than can
be counted in a signed C long; maybe we should do what the Java
collections package does: for once, Java chooses practicality over
purity, and simply states that if the length doesn't fit, the largest
number that does fit is returned (i.e. for us that would be
sys.maxsize in 3.0, sys.maxint in 2.x).
"""
-- Guido van Rossum, 2008-04-30
http://mail.python.org/pipermail/python-3000/2008-April/013340.html

I suspect, however, that part of Java's motivation for this behavior
is that exceptions need to be declared and declaring the length method
as throwing OverflowError would make many programmers very unhappy.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
__________________________________

From report at bugs.python.org  Wed Apr 30 16:04:16 2008
From: report at bugs.python.org (Abhik Shah)
Date: Wed, 30 Apr 2008 14:04:16 +0000
Subject: [issue2726] Autodoc's autoclass directive should include constructor
	docstring
In-Reply-To: <1209564254.38.0.0869277765.issue2726@psf.upfronthosting.co.za>
Message-ID: <1209564254.38.0.0869277765.issue2726@psf.upfronthosting.co.za>


New submission from Abhik Shah <abhikshah at gmail.com>:

The autoclass directive adds the class constructor's argspec to the header and shows the class docstring 
below it but doesn't add the constructor's docstring.  I usually use the class docstring to describe the 
class and the constructor's docstring to describe the constructor arguments so if the constructor argspec 
is being shown, I would expect the description of it to be included below.

Result of svn diff sphinx/ext/autodoc.py:

Index: sphinx/ext/autodoc.py
===================================================================
--- sphinx/ext/autodoc.py	(revision 62582)
+++ sphinx/ext/autodoc.py	(working copy)
@@ -154,6 +154,13 @@
     result.append(indent + '.. %s:: %s%s' % (what, qualname, args), '<autodoc>')
     result.append('', '<autodoc>')
 
+    # added by abhik (4/29/08)
+    if what == 'class':
+        initdoc = inspect.getdoc(getattr(todoc, '__init__'))
+        if initdoc:
+            docstring = docstring if docstring else ''
+            docstring += "\n" + indent + initdoc
+
     # the module directive doesn't like content
     if what != 'module':
         indent += '   '


I don't know how other people would expect autodoc to work so maybe this behavior could be controlled by 
a config param?

----------
assignee: georg.brandl
components: Documentation tools (Sphinx)
messages: 66002
nosy: abhik, georg.brandl
severity: normal
status: open
title: Autodoc's autoclass directive should include constructor docstring
type: behavior
versions: Python 2.5

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2726>
__________________________________

From report at bugs.python.org  Wed Apr 30 16:24:14 2008
From: report at bugs.python.org (Nick Coghlan)
Date: Wed, 30 Apr 2008 14:24:14 +0000
Subject: [issue2258] Update command line docs for issue 1739468
In-Reply-To: <1205060118.8.0.321135862814.issue2258@psf.upfronthosting.co.za>
Message-ID: <1209565454.57.0.153708092077.issue2258@psf.upfronthosting.co.za>


Nick Coghlan <ncoghlan at gmail.com> added the comment:

Updated in rev 62593.

----------
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2258>
__________________________________

From report at bugs.python.org  Wed Apr 30 17:01:32 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 15:01:32 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209567687.96.0.826946830375.issue2719@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

I thought new code is supposed to use Py_TYPE macro instead of ->ob_type:

+			"%.200s object is not an iterator", it->ob_type-
>tp_name);
..
+	res = (*it->ob_type->tp_iternext)(it);

Py3k branch has the same issue.

----------
nosy: +belopolsky

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 17:20:59 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 15:20:59 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209568859.59.0.676259705178.issue2719@psf.upfronthosting.co.za>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

One more question: What is the rationale for

+	res = (*it->ob_type->tp_iternext)(it);
+	if (res == NULL) {
..
+			PyErr_SetNone(PyExc_StopIteration);
+			return NULL;

?

I would think tp_iternext failing to set an exception should not be 
translated into stop iteration.  Instead, builtin_next() should return 
NULL without an exception set and thus trigger a SystemError.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 18:41:02 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Apr 2008 16:41:02 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209573662.22.0.896193915336.issue2719@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

> I would think tp_iternext failing to set an exception should not be 
> translated into stop iteration.  Instead, builtin_next() should return 
> NULL without an exception set and thus trigger a SystemError.

Wrong; the iternext slot is designed to return NULL without setting an
exception.  See e.g. listiter_next().

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 18:48:51 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Apr 2008 16:48:51 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209574131.28.0.208117494257.issue2719@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

+1 on this. I have a few nits about the code:

Line 1083: "%.200s object is not an iterator", it->ob_type->tp_name);
Line is too long.

Line 1088: if (res == NULL) {
How about

  if (res != NULL)
    return res;

?

Line 1089: if (def) {
if (def != NULL) {

Line 1093: PyErr_Clear();
I would only call this if PyErr_Occurred() returns true.

----------
resolution:  -> accepted

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 18:54:02 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 16:54:02 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209573662.22.0.896193915336.issue2719@psf.upfronthosting.co.za>
Message-ID: <d38f5330804300953u59caf647gd9e564e112d9681d@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum
<report at bugs.python.org> wrote:
>
>  Guido van Rossum <guido at python.org> added the comment:
>
>  > ..  builtin_next() should return
>  > NULL without an exception set and thus trigger a SystemError.
>
>  Wrong; the iternext slot is designed to return NULL without setting an
>  exception.  See e.g. listiter_next().

I did not know that.  Thanks for the explanation.  In this case,
wouldn't it be cleaner to call PyIter_Next which is documented to
return NULL with no exception?

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 19:13:50 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 17:13:50 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209573662.22.0.896193915336.issue2719@psf.upfronthosting.co.za>
Message-ID: <d38f5330804301013j7f85a6c3kdec8292c83516ddd@mail.gmail.com>


Alexander Belopolsky <belopolsky at users.sourceforge.net> added the comment:

On Wed, Apr 30, 2008 at 12:41 PM, Guido van Rossum
<report at bugs.python.org> wrote:
> the iternext slot is designed to return NULL without setting an
>  exception.

This is not what the documentation says:

"""
iternextfunc PyTypeObject.tp_iternext
An optional pointer to a function that returns the next item in an
iterator, or raises StopIteration when the iterator is exhausted.
""" <http://docs.python.org/dev/c-api/typeobj.html#tp_iternext>

It looks like documentation needs to be updated, but wouldn't it be
odd to specify that setting StopIteration exception is optional?  It's
probably more logical to intercept StopIteration in slot_tp_iternext
rather than at every place where tp_iternext is called.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 19:22:36 2008
From: report at bugs.python.org (Guido van Rossum)
Date: Wed, 30 Apr 2008 17:22:36 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209576156.31.0.09939840154.issue2719@psf.upfronthosting.co.za>


Guido van Rossum <guido at python.org> added the comment:

Feel free to submit a patch to fix the docs.

Changing the API is not an option -- it's been like this since the
tp_iternext slot was added, and it's been designed like this for a
reason: so that in the common case of iterating over a built-in sequence
type no exception objects have to be created.  In particular the
for-loop code would just discard the StopIteration instance again.

The requirement that the exception is *optional* is so that if you're
calling a Python iterator that *does* create the exception, the
exception object (with whatever data the creator might have attached to
it) doesn't get lost (or worse, have to be recreated).

Calling PyIter_Next() here instead of inlining it would not be
advantageous; it would just slow things down since we'd have to make a
redundant call to PyErr_Occurred() to distinguish the StopIteration case
from other errors.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 19:35:49 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 30 Apr 2008 17:35:49 +0000
Subject: [issue1971] ctypes exposing the pep 3118 buffer interface
In-Reply-To: <1201680953.7.0.68287385548.issue1971@psf.upfronthosting.co.za>
Message-ID: <1209576949.79.0.139081292434.issue1971@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Instead of waiting for review I've committed this as rev 62597.

----------
assignee:  -> theller
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1971>
__________________________________

From report at bugs.python.org  Wed Apr 30 19:39:04 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 30 Apr 2008 17:39:04 +0000
Subject: [issue2692] bytes object wrongly exposes writeable buffer interface
In-Reply-To: <1209143688.91.0.550204497514.issue2692@psf.upfronthosting.co.za>
Message-ID: <1209577144.8.0.988183317993.issue2692@psf.upfronthosting.co.za>


Thomas Heller <theller at ctypes.org> added the comment:

Duplicate of issue #2538.

----------
resolution:  -> duplicate
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2692>
__________________________________

From report at bugs.python.org  Wed Apr 30 19:40:36 2008
From: report at bugs.python.org (Thomas Heller)
Date: Wed, 30 Apr 2008 17:40:36 +0000
Subject: [issue2538] memoryview of bytes is not readonly
In-Reply-To: <1207182382.72.0.866250850169.issue2538@psf.upfronthosting.co.za>
Message-ID: <1209577236.08.0.797540029879.issue2538@psf.upfronthosting.co.za>


Changes by Thomas Heller <theller at ctypes.org>:


----------
nosy: +theller

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2538>
__________________________________

From report at bugs.python.org  Wed Apr 30 20:31:36 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Apr 2008 18:31:36 +0000
Subject: [issue2723] Truncate __len__() at sys.maxsize
In-Reply-To: <1209530191.73.0.609196846233.issue2723@psf.upfronthosting.co.za>
Message-ID: <1209580295.6.0.305404249472.issue2723@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Gasp, having len() return something else than the true container size
sounds horrible. At least raising OverflowError makes it clear that
something wrong is going on...

----------
nosy: +pitrou

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2723>
__________________________________

From report at bugs.python.org  Wed Apr 30 21:00:15 2008
From: report at bugs.python.org (Gregory Dai)
Date: Wed, 30 Apr 2008 19:00:15 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209505660.73.0.126910957644.issue2714@psf.upfronthosting.co.za>
Message-ID: <ce347e580804301159j6f47550bp72cabd78a79a4a09@mail.gmail.com>


Gregory Dai <gregory.dai at gmail.com> added the comment:

All I needed was starting a new shell/DOS prompt. In the old one, there were
residual environment variables having to do with TCL set up by Ruby
installation.

You can close the ticket now.

Thanks,

Greg

On Tue, Apr 29, 2008 at 2:47 PM, Martin v. L?wis <report at bugs.python.org>
wrote:

>
> Martin v. L?wis <martin at v.loewis.de> added the comment:
>
> Check whether the TCL_DIR or TK_DIR environment variables are set. If
> so, unset them.
>
> __________________________________
> Tracker <report at bugs.python.org>
> <http://bugs.python.org/issue2714>
> __________________________________
>

Added file: http://bugs.python.org/file10145/unnamed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: unnamed
URL: <http://mail.python.org/pipermail/python-bugs-list/attachments/20080430/e6b9d634/attachment-0001.txt>

From report at bugs.python.org  Wed Apr 30 21:07:31 2008
From: report at bugs.python.org (Facundo Batista)
Date: Wed, 30 Apr 2008 19:07:31 +0000
Subject: [issue2714] Unable to start IDLE on Windows Server 2003 x64 Edition
	w/ SP2
In-Reply-To: <1209424980.5.0.656104455604.issue2714@psf.upfronthosting.co.za>
Message-ID: <1209582451.61.0.50938981731.issue2714@psf.upfronthosting.co.za>


Facundo Batista <facundo at taniquetil.com.ar> added the comment:

Closed as by OP indication.

----------
resolution:  -> invalid
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2714>
__________________________________

From report at bugs.python.org  Wed Apr 30 21:30:19 2008
From: report at bugs.python.org (Alexander Belopolsky)
Date: Wed, 30 Apr 2008 19:30:19 +0000
Subject: [issue2727] clarify tp_nextiter behavior in the C API  documentation
In-Reply-To: <1209583819.19.0.371095659675.issue2727@psf.upfronthosting.co.za>
Message-ID: <1209583819.19.0.371095659675.issue2727@psf.upfronthosting.co.za>


New submission from Alexander Belopolsky <belopolsky at users.sourceforge.net>:

See discussion in issue2719 for details.

----------
assignee: georg.brandl
components: Documentation
files: doc-typeobj.diff
keywords: patch
messages: 66016
nosy: belopolsky, georg.brandl
severity: normal
status: open
title: clarify tp_nextiter behavior in the C API  documentation
type: feature request
versions: Python 2.6, Python 3.0
Added file: http://bugs.python.org/file10146/doc-typeobj.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2727>
__________________________________

From report at bugs.python.org  Wed Apr 30 21:47:40 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 19:47:40 +0000
Subject: [issue2719] Backport next()
In-Reply-To: <1209502948.11.0.815761639378.issue2719@psf.upfronthosting.co.za>
Message-ID: <1209584860.72.0.206525196626.issue2719@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Updated and committed as r62599. Also fixed your nits in the original 3k
version in r62598.

----------
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2719>
__________________________________

From report at bugs.python.org  Wed Apr 30 22:05:28 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 20:05:28 +0000
Subject: [issue2727] clarify tp_nextiter behavior in the C API  documentation
In-Reply-To: <1209583819.19.0.371095659675.issue2727@psf.upfronthosting.co.za>
Message-ID: <1209585923.61.0.961894779538.issue2727@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Changed a bit and committed in r62602.

----------
resolution:  -> accepted
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2727>
__________________________________

From report at bugs.python.org  Wed Apr 30 22:13:56 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 20:13:56 +0000
Subject: [issue2258] Update command line docs for issue 1739468
In-Reply-To: <1205060118.8.0.321135862814.issue2258@psf.upfronthosting.co.za>
Message-ID: <1209586436.0.0.16416014965.issue2258@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Thanks Nick!

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2258>
__________________________________

From report at bugs.python.org  Wed Apr 30 22:16:19 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 20:16:19 +0000
Subject: [issue2725] Handle ASDLSyntaxErrors gracefully
In-Reply-To: <1209557288.23.0.65253319009.issue2725@psf.upfronthosting.co.za>
Message-ID: <1209586579.87.0.378968360951.issue2725@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Some comments:
- Since you check for a false mod before calling check(), the check in
check() will not be reached.
- The error print seems to be already in trunk.

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2725>
__________________________________

From report at bugs.python.org  Wed Apr 30 22:17:58 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 20:17:58 +0000
Subject: [issue2722] os.getcwd fails for long path names on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1209586678.15.0.183537507567.issue2722@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Why isn't the buffer length MAX_PATH anyway?

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2722>
__________________________________

From report at bugs.python.org  Wed Apr 30 22:19:52 2008
From: report at bugs.python.org (Christian Heimes)
Date: Wed, 30 Apr 2008 20:19:52 +0000
Subject: [issue2722] os.getcwd fails for long path names on linux
In-Reply-To: <1209513713.72.0.856883129402.issue2722@psf.upfronthosting.co.za>
Message-ID: <1209586792.32.0.794666076997.issue2722@psf.upfronthosting.co.za>


Christian Heimes <lists at cheimes.de> added the comment:

It should be MAX_PATH. All path related functions should use MAX_PATH as
buffer size, maybe even MAX_PATH+1

----------
nosy: +tiran

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2722>
__________________________________

From report at bugs.python.org  Wed Apr 30 22:20:02 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 20:20:02 +0000
Subject: [issue2716] Reimplement audioop because of copyright issues
In-Reply-To: <1209428570.75.0.48368829493.issue2716@psf.upfronthosting.co.za>
Message-ID: <1209586802.74.0.261921101594.issue2716@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

It is, as most "old" standard modules, not actively maintained, but
there is always the chance that somebody will fix bugs as they are
reported :)

Anyway, the algorithms in it won't change, and if you want its removal I
predict there will be many people crying out.

----------
nosy: +georg.brandl

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2716>
__________________________________

From report at bugs.python.org  Wed Apr 30 23:00:40 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Apr 2008 21:00:40 +0000
Subject: [issue1748] contextlib.contextmanager does not use functools.wraps
In-Reply-To: <1199660346.11.0.927717674711.issue1748@psf.upfronthosting.co.za>
Message-ID: <1209589240.15.0.26455575787.issue1748@psf.upfronthosting.co.za>


Benjamin Peterson <musiccomposition at gmail.com> added the comment:

Can this be fixed?

----------
nosy: +benjamin.peterson

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1748>
__________________________________

From report at bugs.python.org  Wed Apr 30 23:08:57 2008
From: report at bugs.python.org (Georg Brandl)
Date: Wed, 30 Apr 2008 21:08:57 +0000
Subject: [issue1748] contextlib.contextmanager does not use functools.wraps
In-Reply-To: <1199660346.11.0.927717674711.issue1748@psf.upfronthosting.co.za>
Message-ID: <1209589737.34.0.867827121434.issue1748@psf.upfronthosting.co.za>


Georg Brandl <georg at python.org> added the comment:

Done in r62605.

----------
nosy: +georg.brandl
resolution:  -> fixed
status: open -> closed

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1748>
__________________________________

From report at bugs.python.org  Wed Apr 30 23:28:44 2008
From: report at bugs.python.org (Benjamin Peterson)
Date: Wed, 30 Apr 2008 21:28:44 +0000
Subject: [issue2728] Failing decimal doctest
In-Reply-To: <1209590924.27.0.894325194913.issue2728@psf.upfronthosting.co.za>
Message-ID: <1209590924.27.0.894325194913.issue2728@psf.upfronthosting.co.za>


New submission from Benjamin Peterson <musiccomposition at gmail.com>:

I was removing from __future__ import with_statment in the stdlib when I
came across this disabled doctest in decimal.py:

    # The string below can't be included in the docstring until Python 2.6
    # as the doctest module doesn't understand __future__ statements
    """
    >>> from __future__ import with_statement
    >>> print getcontext().prec
    28
    >>> with localcontext():
    ...     ctx = getcontext()
    ...     ctx.prec += 2
    ...     print ctx.prec
    ...
    30
    >>> with localcontext(ExtendedContext):
    ...     print getcontext().prec
    ...
    9
    >>> print getcontext().prec
    28
    """

When it was enabled, it failed.

----------
components: Library (Lib)
messages: 66026
nosy: benjamin.peterson
severity: normal
status: open
title: Failing decimal doctest
type: behavior
versions: Python 2.6

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2728>
__________________________________

From report at bugs.python.org  Wed Apr 30 23:46:32 2008
From: report at bugs.python.org (Antoine Pitrou)
Date: Wed, 30 Apr 2008 21:46:32 +0000
Subject: [issue2459] speedup for / while / if with better bytecode
In-Reply-To: <1206224909.42.0.227263347483.issue2459@psf.upfronthosting.co.za>
Message-ID: <1209591992.34.0.871494414841.issue2459@psf.upfronthosting.co.za>


Antoine Pitrou <pitrou at free.fr> added the comment:

Finally I had to slightly change the lnotab format to have the right
tracing semantics: the change is that line number increments are now
signed bytes rather than unsigned.

Still, there is a small change in tracing behaviour (see test_trace.py):
the for statement is traced twice in the first loop iteration, that's
because the iterator object is retrieved (GET_ITER) at the beginning of
the loop while the next iterator value is fetched (FOR_ITER) at the end
of the loop. I don't believe this is very painful.

All in all, the whole test suite now passes fine. The performance
numbers are the same as before.

----------
title: speedup loops with better bytecode -> speedup for / while / if with better bytecode
Added file: http://bugs.python.org/file10147/loops8.patch

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2459>
__________________________________

From report at bugs.python.org  Wed Apr 30 23:57:04 2008
From: report at bugs.python.org (Manuel Kaufmann)
Date: Wed, 30 Apr 2008 21:57:04 +0000
Subject: [issue2729] Link error in What's New in Python 2.6
In-Reply-To: <1209592624.39.0.481461750945.issue2729@psf.upfronthosting.co.za>
Message-ID: <1209592624.39.0.481461750945.issue2729@psf.upfronthosting.co.za>


New submission from Manuel Kaufmann <humitos at gmail.com>:

I found a link error in section "What's New in Python 2.6" to Trac 
project.

I attach the patch file

----------
assignee: georg.brandl
components: Documentation
files: patch.diff
keywords: patch
messages: 66028
nosy: georg.brandl, humitos
severity: normal
status: open
title: Link error in What's New in Python 2.6
versions: Python 2.6
Added file: http://bugs.python.org/file10148/patch.diff

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue2729>
__________________________________