From noreply at sourceforge.net  Mon Mar  1 01:12:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 01:13:01 2004
Subject: [ python-Bugs-774188 ] XP manifest files should be installed
Message-ID: <E1Axgfe-0001wv-00@sc8-sf-web1.sourceforge.net>

Bugs item #774188, was opened at 2003-07-19 15:49
Message generated for change (Comment added) made by limi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=774188&group_id=5470

Category: Windows
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Henk Punt (h_punt)
Assigned to: Mark Hammond (mhammond)
Summary: XP manifest files should be installed

Initial Comment:
In order for python based windows programs to use 
the right widget (e.g. common control) versions on
XP, a manifest file must be present for both executables 
(python.exe and pythonw.exe).
I believe Python2.2 installs these per default.

If these are not present, weird graphical artifacts may 
show up on windows XP in tree and list controls when 
high-color icons are used.
A sample of a manifest file (&#039;pythonw.exe.manifest&#039;):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?
>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" 
manifestVersion="1.0">
<assemblyIdentity
    version="0.64.1.0"
    processorArchitecture="x86"
    name="Controls"
    type="win32"
/>
<description>Python Interpreter</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="X86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>




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

Comment By: Alexander Limi (limi)
Date: 2004-03-01 07:12

Message:
Logged In: YES 
user_id=403979

I can confirm that this works fine with the cross-platform 
Python controller we are shipping with Plone 2.0, if that is of 
any use. We use Python 2.3.3 and wxPython 2.4.2.4. 
Stumbled over this issue when I was searching for information 
on Python and Manifest-files, and thought I'd add my 0.02 
euros.

Screenshots on http://download.limi.net/xcontroller/ if you're 
curious about how it looks. :)


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

Comment By: Tim Peters (tim_one)
Date: 2003-07-21 00:38

Message:
Logged In: YES 
user_id=31435

I'm closing this, for lack of a sane way to proceed at this 
time.  The

http://www.python.org/cgi-bin/moinmoin/PythonQuestions

link has a claim that adding a manifest file caused Tkinter to 
crash ... until it's clear what to do, I'm not touching this.

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

Comment By: Henk Punt (h_punt)
Date: 2003-07-20 10:36

Message:
Logged In: YES 
user_id=729698

I've googled around a bit more,
http://www.python.org/cgi-bin/moinmoin/PythonQuestions
section '4 Windows XP look-and-feel'
advises against it, apparently somebody ran into problems 
with this.
Mark is right, we don't know what the right control library is 
for any program run with the python.exe interpreter.
sigh, I guess for microsoft a program is only a program when 
it is an .exe :-(.
As far as I am concerned this is also not very critical.


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

Comment By: Mark Hammond (mhammond)
Date: 2003-07-20 06:40

Message:
Logged In: YES 
user_id=14198

Welcome to .NET <wink>.  I can believe this would help some
GUI programs, but am hard pressed to call it critical enough
to bang in 2.3 at this late stage.

A concern is that how do we know the assertion about what
control library we want to use is true for *all* programs
hosted by our executables?

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

Comment By: Henk Punt (h_punt)
Date: 2003-07-20 00:25

Message:
Logged In: YES 
user_id=729698

I may have put them there myself, It is a known problem 
though, lookup section
'2.4.2.1 Windows XP and Python 2.2.2'
of the wxpython Wiki at: 
http://wiki.wxpython.org/index.cgi/Frequently_20Asked_20Que
stions
It would not hurt to have these installed by default for the 
Windows platform

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

Comment By: Tim Peters (tim_one)
Date: 2003-07-19 22:15

Message:
Logged In: YES 
user_id=31435

Mark, does this mean anything to you?  We've (PLabs) 
certainly never installed anything like this before.

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

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

From noreply at sourceforge.net  Mon Mar  1 06:00:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 06:00:59 2004
Subject: [ python-Bugs-907457 ] Docs for os,
	popen2 omit list argument to popen2() et al
Message-ID: <E1AxlAK-0001M0-00@sc8-sf-web3.sourceforge.net>

Bugs item #907457, was opened at 2004-03-01 11:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=907457&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hoffman (hoffmanm)
Assigned to: Nobody/Anonymous (nobody)
Summary: Docs for os, popen2 omit list argument to popen2() et al

Initial Comment:
http://www.python.org/doc/current/lib/os-newstreams.html
and
http://www.python.org/doc/current/lib/module-popen2.html
do not give any indication that you can use a list for
cmd instead of a string and os.execvp() will be used
instead of setting up a subshell.

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

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

From noreply at sourceforge.net  Mon Mar  1 06:12:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 06:12:44 2004
Subject: [ python-Bugs-789262 ] __getattr__ and metaclasses
Message-ID: <E1AxlLi-0007Ec-00@sc8-sf-web1.sourceforge.net>

Bugs item #789262, was opened at 2003-08-15 15:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789262&group_id=5470

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Gon?alo Rodrigues (grodr)
Assigned to: Nobody/Anonymous (nobody)
Summary: __getattr__ and metaclasses

Initial Comment:
This came out from a thread in comp.lang.python: Here?s 
the reference:

http://groups.google.pt/groups?hl=pt-PT&lr=&ie=UTF-
8&threadm=md94jvccu02b9dv5890k34629rkot79roj%
404ax.com&rnum=6&prev=/groups%3Fq%3Dgon%25C3%
25A7alo%2Brodrigues%2Bgroup:comp.lang.python.*%
26hl%3Dpt-PT%26lr%3D%26ie%3DUTF-8%26group%
3Dcomp.lang.python.*%26selm%
3Dmd94jvccu02b9dv5890k34629rkot79roj%
25404ax.com%26rnum%3D6


Consider the following example (provided by M. 
Simionato)

>>> class M(type):
... 	def __getattr__(self, name):
... 		if name == &#039;__iter__&#039;:
... 			return lambda self: iter([])
...
>>> class C(object):
... 	__metaclass__ = M
... 	
>>> C.__iter__
<function <lambda> at 0x0110E8F0>
>>> c = C()
>>> iter(c)
Traceback (most recent call last):
  File "<interactive input>", line 1, in ?
TypeError: iteration over non-sequence
>>>

This means that the iterator machinery does not check 
__getattr__ (or __getattribute__ for that matter ? I 
have made the test). The Language Reference says:

?A class can implement certain operations that are 
invoked by special syntax (such as arithmetic operations 
or subscripting and slicing) by defining methods with 
special names.?

Which does not throw much light on the matter at hand. 
So there are two ways we can view the above:

(A) It?s a bug.

This is the one I favour ;-). Arguing by contradiction, 
not being considered a bug means that there is a very 
special distinction being made when it comes to 
attribute lookup of special names. 

I tend to follow the Gang of Four?s main 
injunction ?Prefer composition to inheritance?. 
Composition is great in Python precisely because of the 
__getattr__ hook. Not being able to use __getattr__ in 
metaclasses to trap special names surely hampers that 
role somewhat.

(B) It?s not a bug.

Then at least I think that the documentation should be 
worded more accurately. Quoting A. Martelli on the same 
thread

?__getattr__ is not a BINDING of the special method, 
though it may be considered a DEFINITION of it, which is 
why the current phrase in the Language Reference is not 
100% correct and complete -- only 99.44%, and I agree 
that the remaining 0.56% _is_ a delicate defect in the 
documentation.?

With my best regards,
G. Rodrigues


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

>Comment By: Michael Hudson (mwh)
Date: 2004-03-01 11:12

Message:
Logged In: YES 
user_id=6656

> Metaclasses are not guilty here!

It's more complicated than that.

iter(o) does (roughly)

o->ob_type->tp_iter(o)

At class definition time, if the class defines __iter__, a
wrapper for it is stuffed into the type's tp_iter slot.  If
it doesn't, NULL is placed there instead.

What *could* be done is, if the *meta*class defines
__getattr__ or __getattribute__, all the tp_ slots could be
filled with a special wrapper that calls the generic
attribute getter.  But that would be quite a coding effort,
and these classes would have pretty atrocious performance.

And making this work when you assign to __getattribute__ on
the metaclass would be a truly crazy piece of code.

Or the docs could note this limitation.

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

Comment By: Michele Simionato (michele_s)
Date: 2003-08-21 11:16

Message:
Logged In: YES 
user_id=583457

Two comments:

1. The credit for discovering this "issue" goes to Bjorn
Pettersen, not to me.

2. The issue is NOT with metaclasses, the title should
be "special methods and __getattr__"

The metaclass works perfectly fine and

X.__iter__(x)

works. The problem is with the "iter" builtin, since

iter(x) DOES NOT call X.__iter__(x).

Same with str, len, etc.

Metaclasses are not guilty here!


  Michele

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

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

From noreply at sourceforge.net  Mon Mar  1 07:10:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 07:10:24 2004
Subject: [ python-Bugs-835353 ] logging.StreamHandler encodes log message in
	UTF-8
Message-ID: <E1AxmFW-0003c8-00@sc8-sf-web2.sourceforge.net>

Bugs item #835353, was opened at 2003-11-03 22:45
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835353&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Vaclav Dvorak (vdvo)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.StreamHandler encodes log message in UTF-8

Initial Comment:
For some reason that I do not see,
logging.StreamHandler in Python 2.3 insists on writing
plain non-Unicode strings to the stream, and the
encoding is hard-coded as UTF-8:

            if not hasattr(types, "UnicodeType"): #if
no unicode support...
                self.stream.write("%s\n" % msg)
            else:
                try:
                    self.stream.write("%s\n" % msg)
                except UnicodeError:
                    self.stream.write("%s\n" %
msg.encode("UTF-8"))

This behaviour is neither documented nor reasonable.
Files can be perfectly able to write Unicode strings
(e.g., through the use of codecs.EncodedFile or with a
default encoding of sys.stdout), and even if they are
not, UTF-8 is hardly the only choice for an encoding. I
propose to simply replace the above code with:

self.stream.write(msg)
self.stream.write("\n")


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

>Comment By: Vinay Sajip (vsajip)
Date: 2004-03-01 12:10

Message:
Logged In: YES 
user_id=308438

Notice that UTF-8 is only used if a UnicodeError is detected. 
By default, "%s\n" % msg is written to the stream using the 
stream's write(). If the stream can handle this without raising 
a UnicodeError, then UTF-8 will not be used. Is there a 
specific use case/test script which demonstrates a problem?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-05 20:30

Message:
Logged In: YES 
user_id=21627

That would be an incompatible change, of course, as you then
may get encoding errors where you currently get none.

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

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

From noreply at sourceforge.net  Mon Mar  1 08:48:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 08:48:51 2004
Subject: [ python-Bugs-899109 ] 1==float('nan')
Message-ID: <E1Axnmg-00014k-00@sc8-sf-web2.sourceforge.net>

Bugs item #899109, was opened at 2004-02-17 21:47
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=899109&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 3
Submitted By: Arman Bostani (arman0)
Assigned to: Michael Hudson (mwh)
Summary: 1==float('nan')

Initial Comment:
In python 2.3.1 on Linux/x86, X==float(&#039;nan&#039;) evaluates
to True given any number value for X.  I admit to not
knowing much about IEEE arithmetic.  But, is this Kosher?

-arman
 

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

>Comment By: Michael Hudson (mwh)
Date: 2004-03-01 13:48

Message:
Logged In: YES 
user_id=6656

If I'm reading the pybench tea leaves correctly, you don't
have anything to worry about here.  CompareFloatsIntegers is
significantly faster (~30%), everything else is in the noise.

Removing float_compare speeds up CompareFloatsIntegers even
more (~40%, now) and has little impact on anything else.

I don't believe PyObject_Compare() is a performance hotspot
when the types involved implement rich comparisons.

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

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-02-26 13:09

Message:
Logged In: YES 
user_id=38388

Michael,

please be more careful about these changes: we certainly do
not want to lose a significant number of cycles just to
remedy this rather uncommon error situation.

The cleanest solution seems to be to just raise an exception
in the compare logic (which is perfectly OK). Removing the
tp_compare slot will result in PyObject_Compare() to take a
different path and is likely going to cause a performance hit.

Whatever you chose to do about this, please make sure that
we don't lose performance in float compares. pybench has a
special test for float comparisons which you could use as
basis for this.

Thanks.

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-26 12:51

Message:
Logged In: YES 
user_id=6656

Hmm.

I agree the situation wrt. float_compare as in CVS is a
problem.  Not sure I have the courage to have float_compare
starting to set exceptions, though.  Just removing
float_compare seems to be a conservative change (yes, it can
give silly answers, but this is nothing new).

I certainly don't have the courage to change
PyObject_Compare unless someone like Tim or Guido says I
should :-)

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-20 21:10

Message:
Logged In: YES 
user_id=17848

Sorry, I didn't intend a rant, and I apologize if any
offense was given.  I'll try to use a milder tone
henceforth.

To answer Michael's question: yes, now that your patch is
installed, float_compare is incompatible with rich
comparison; for example cmp(NaN,1.0) returns 0 even though
NaN==1.0 returns False.

Another problem: cmp() initially uses pointer comparison to
compare objects, so if x is a NaN then cmp(x,x) returns 0.

I don't think that removing float_compare will fix the
problem, as it would simply cause cmp to return an incorrect
value when given a NaN.

If you prefer IEEE semantics to sorting NaNs before numbers,
another possibility is for cmp to raise an exception when
given a NaN, since in that case cmp can't return any value
that is compatible with IEEE floating point.

Here's a patch to implement this proposal.  It does not rely
on isnan or a substitute, so I hope this answers Tim's
objection.  Note that PyObject_Compare needs a minor change,
too; since user-defined types may have the same problem that
Float does, it's simplest just to omit the optimization
there.

===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.2
retrieving revision 2.3.3.3
diff -pu -r2.3.3.2 -r2.3.3.3
--- Objects/floatobject.c	2004/02/20 19:45:01	2.3.3.2
+++ Objects/floatobject.c	2004/02/20 21:04:20	2.3.3.3
@@ -367,7 +367,15 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	if (i < j)
+		return -1;
+	if (i > j)
+		return 1;
+	if (i == j)
+		return 0;
+	PyErr_SetString(PyExc_FloatingPointError,
+			"cannot compare NaNs using cmp");
+	return -2;
 }
 
 static PyObject*
===================================================================
RCS file: Objects/object.c,v
retrieving revision 2.3.3.0
retrieving revision 2.3.3.1
diff -pu -r2.3.3.0 -r2.3.3.1
--- Objects/object.c	2003/04/18 00:45:58	2.3.3.0
+++ Objects/object.c	2004/02/20 21:04:20	2.3.3.1
@@ -877,8 +877,6 @@ PyObject_Compare(PyObject *v, PyObject *
 		PyErr_BadInternalCall();
 		return -1;
 	}
-	if (v == w)
-		return 0;
 	vtp = v->ob_type;
 	compare_nesting++;
 	if (compare_nesting > NESTING_LIMIT &&


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-20 11:09

Message:
Logged In: YES 
user_id=6656

Paul, I appreciate your attention to detail, but your last
comment is essentially a rant that puts words into Tim's and
my mouth.

My patch (which is what got checked in) *is* attached to
this report, or you can see it on the python-checkins list.
 There was some ancillary discussion on python-dev (under
the admittedly inscrutable title of "Weekly Python Bug/Patch
Summary") about this, where it was uncovered that MSVC 7.1
(which is what Python 2.4 will be compiled with) adheres to
the C99 rules for comparisons involving NaNs.  So with my
patch, on all major platforms, float comparisons are likely
to follow C99 rules in Python 2.4.  We're still not going to
promise anything, though.

I admit to not doing much research on whether I should/could
remove float_compare.  It seems that perhaps I should.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 20:22

Message:
Logged In: YES 
user_id=31435

I specifically said C89.  Python doesn't require C99 support, 
and can't yet, because the majority of compilers used to 
compile Python aren't yet C99 compilers.  Even in C99, that x!
=x is 1 for NaN is optional behavior, depending on whether the 
implementation chooses to define __STDC_IEC_559__.

The point of my example was solely the result of x==x.  It 
doesn't matter how a NaN got put into x, MSVC 6 generates 
code that returns true regardless.  It wasn't constructed to 
confuse anything -- to the contrary, it shows about the most 
straightforward way to *get* a NaN under MSVC 6, short of 
playing tricks with bit representation.

Michael's patch is a more efficient approach regardless.  If 
Python is to grow an isnan macro (which his patch doesn't 
need), then it shoiuld grow an isnan() macro that works on all 
platforms with 754 HW (else it appears to promise thing it 
can't deliver).

Going on to call NaN "less than" everything else goes beyond 
anything C99 says, and is a debate of its own.

No, he didn't remove float_compare().  He could, but only cmp
() will invoke it now.

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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 19:55

Message:
Logged In: YES 
user_id=17848

C99 does say what happens when NaNs are
compared.  See, for example, section 7.12.14,
which says that NaNs are unordered with respect
to other floating point values, and section
7.12.14.1, which says that x>y is equivalent to
isgreater(x,y) and therefore returns false if
either x or y is a NaN (unless the "invalid"
floating-point exception occurs, which isn't
happening here and even if it did happen the
original code would be broken anyway).

Your argument is that any code that uses NaNs
returns garbage and so we should give up.  But
then you have no logical reason to either favor
or oppose this patch, as it doesn't alter
Python's behavior on non-NaN arguments.

It's clear the the patch does fix the comparison
problem on most existing platforms.  It actually
works on Solaris sparc, and I'm sure that it
will work on a wide variety of other important
platforms.

The fact that you've found an incompatibility
between MSVC 6 and C99 on one example does not
mean that the proposed patch won't work: it
merely means that MSVC 6 won't work on your
example (which is deliberately constructed to
confuse pre-C99 compilers).  The proposed patch
doesn't contain confusing code like that, so it
should work even on pre-C99 compilers.

I'm not speaking just from theory here.  Similar
code has been in GNU sort since 1999, and it
works fine in practice.

Since the patch fixes the bug on many (perhaps
all) real platforms, and it can't introduce a
bug on any platform, the patch is a win.

Michael Hudson said "Consider the attached."
but nothing was attached.  I gather from his
comments that he added rich comparisons for
floats.  This will work if the code never
invokes the 2.3.3 float_compare -- so can I take
it that he removed float_compare?


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:39

Message:
Logged In: YES 
user_id=6656

Tim said yes.

Objects/floatobject.c revision 2.127
Misc/NEWS revision 1.936

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-19 19:01

Message:
Logged In: YES 
user_id=6656

Consider the attached.  It implements rich comparisons for
floats, which makes the behaviour on linux at least very
much less silly.  All tests except for the
considered-hopeless-on-this box audio tests and the new
test_tcl pass.  Even test_bsddb passed! Twice!  (I'm not
sure I can claim credit for this :-)

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-19 17:34

Message:
Logged In: YES 
user_id=31435

Sorry, the patch can't work:  C89 says nothing about what 
happens when NaNs are compared, and it's in fact not the 
case across platforms that "x != x" returns 1 when x is a NaN.

The most important counter-example for Python is that the 
following prints

1.#INF
-1.#IND
1

under MSVC 6.

#include <stdio.h>

void main()
{
    double x = 1e300 * 1e300;
    printf("%g\n", x);
    x -= x;
    printf("%g\n", x);
    printf("%d\n", x == x);
}


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

Comment By: Paul Eggert (eggert)
Date: 2004-02-19 06:39

Message:
Logged In: YES 
user_id=17848

There's an easy fix.  Python has long mishandled IEEE
special values
(see bugs 445484 and 737648, and see PEP 42 "Non-accidental
IEEE-754
support" as well as PEP 754), and solving the problem in
general will
be some work.  However, solving the NaN-comparison problem
is easy:
simply sort NaNs consistently before all numbers.  This is
the same
algorithm that GNU "sort -g" has used for quite some time.

===================================================================
RCS file: Include/pyport.h,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Include/pyport.h
--- Include/pyport.h	2003/09/30 14:56:50	2.3.3.0
+++ Include/pyport.h	2004/02/19 06:06:10
@@ -221,6 +221,13 @@ extern "C" {
 #define Py_SAFE_DOWNCAST(VALUE, WIDE, NARROW) (NARROW)(VALUE)
 #endif
 
+/* Py_IS_NAN(X)
+ * Return 1 if float or double arg is not a number (NaN),
else 0.
+ * Caution:
+ *    X is evaluated more than once.
+ */
+#define Py_IS_NAN(X) ((X) != (X))
+
 /* Py_IS_INFINITY(X)
  * Return 1 if float or double arg is an infinity, else 0.
  * Caution:
===================================================================
RCS file: Objects/floatobject.c,v
retrieving revision 2.3.3.0
diff -pu -r2.3.3.0 Objects/floatobject.c
--- Objects/floatobject.c	2003/06/28 20:04:24	2.3.3.0
+++ Objects/floatobject.c	2004/02/19 06:03:37
@@ -367,7 +367,21 @@ float_compare(PyFloatObject *v, PyFloatO
 {
 	double i = v->ob_fval;
 	double j = w->ob_fval;
-	return (i < j) ? -1 : (i > j) ? 1 : 0;
+	int c;
+	/* Because of NaNs IEEE arithmetic is not a total order.
+	 * Python works better with total orders, so use the same
+	 * total order that GNU sort does: NaNs sort before numbers,
+	 * and NaNs are sorted by internal bit-pattern.
+	 */
+	return ((i < j) ? -1
+		: (i > j) ? 1
+		: (i == j) ? 0
+		: !Py_IS_NAN(j) ? -1 /* i is NaN, j is not */
+		: !Py_IS_NAN(i) ? 1  /* j is NAN, i is not */
+		: /* i and j are both NaNs; compare them bitwise */
+		  ((c = memcmp(&v->ob_fval, &w->ob_fval, sizeof(v->ob_fval)))
+		   < 0) ? -1
+		: (c > 0));
 }
 
 static long


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

Comment By: Michael Hudson (mwh)
Date: 2004-02-18 17:46

Message:
Logged In: YES 
user_id=6656

Man, that's strange (I see the same behaviour on my redhat 9
box with 2.3.3).

I don't have time to dig right now, but if you want to,
playing with equivalent C programs would be a very good start.

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

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

From noreply at sourceforge.net  Mon Mar  1 09:22:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 09:22:56 2004
Subject: [ python-Bugs-907575 ] "\textttNone" in Index
Message-ID: <E1AxoJp-00024p-00@sc8-sf-web4.sourceforge.net>

Bugs item #907575, was opened at 2004-03-01 14:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=907575&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: "\textttNone" in Index

Initial Comment:
In the index of the Python 2.3.3 documentation (as 
started from IDLE on Windows XP), the references to

None
None object
NotImplemented
NotImplemented object

are shown as

\textttNone
\textttNone object
\textttNotImplemented
\textttNotImplemented object

and are therefore at the wrong place.

This is probably due to a typo.


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

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

From noreply at sourceforge.net  Mon Mar  1 23:49:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 23:49:21 2004
Subject: [ python-Bugs-897625 ] time.strftime crashes python
Message-ID: <E1Ay1q8-0006ad-00@sc8-sf-web2.sourceforge.net>

Bugs item #897625, was opened at 2004-02-15 13:33
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897625&group_id=5470

Category: Python Library
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Tom Lynn (tlynn)
Assigned to: Brett Cannon (bcannon)
Summary: time.strftime crashes python

Initial Comment:
On Win2k:

Python 2.3 (#46, Jul 29 2003, 18:54:32) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))

Python dumps core.  Is that (ever) expected behaviour?

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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-01 20:49

Message:
Logged In: YES 
user_id=357491

OK, fixed in Python 2.4 with rev. #2.140 for Modules/timemodule.c 
(along with changes to Doc/lib/libtime.tex as rev. 1.63, 
datetimemodule.c as rev. 1.70, Lib/test/test_time.py as rev. 1.16, and 
Lib/test/test_strftime.py as rev. 1.28).

This will break some code that does not use 1 or higher for fields in the 
time tuple that are supposed to be set to that (month, day, and day of 
year), but it was felt it was better to do a complete check on all values 
then on only certain values so as to make it consistent.

Since it breaks code it will not be backported.

And yes, ashtong, more data points are always helpful.

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

Comment By: Graham Ashton (ashtong)
Date: 2004-02-28 08:57

Message:
Logged In: YES 
user_id=263764

Not sure if it's helpful, but here's another data point. I
get the buggy behaviour on 2.3.3 on Gentoo Linux:

ratchet% python
Python 2.3.3 (#1, Jan  6 2004, 09:44:50)
[GCC 3.3.2 20031022 (Gentoo Linux 3.3.2-r2, propolice)] on
linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
Segmentation fault


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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-21 12:01

Message:
Logged In: YES 
user_id=357491

OK, have a solution coded up, just waiting to hear from Tim on whether a 
change to datetime is okay with him.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:59

Message:
Logged In: YES 
user_id=357491

Should be able to deal with this cleanly by modifying gettmarg() to do 
some sanity checks on the values before returning and letting 
time_strftime() at the struct tm that gettmarg() created.

First have to check the ISO C standard, though, to make sure I don't 
overstep my bounds on the sanity checks (or I could just follow our own 
specs, but that would be too easy  =).

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:36

Message:
Logged In: YES 
user_id=304464

On WinXP Home does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\xfcI\xc1w\xf8I\xc1w\xf4I\xc1w\xf0I\xc1w\xecI\xc1w\xe8I\xc1w\xe4I\xc1w\xdcI\xc1w\xd4I\xc1w\xccI\xc1w\xc0I\xc1w\xb4I\xc1w\xacI\xc1w\xa0I\xc1w\x9cI\xc1w\x98I\xc1w\x94I\xc1w\x90I\xc1w\x8cI\xc1w\x88I\xc1w\x84I\xc1w\x80I\xc1w|I\xc1wxI\xc1wtI\xc1wpI\xc1whI\xc1w\I\xc1wTI\xc1wLI\xc1w\x8cI\xc1wDI\xc1w<I\xc1w4I\xc1w(I\xc1wI\xc1w\x14I\xc1w\x08I\xc1w\x04I\xc1w'

ActivePython 2.3.2 Build 232 (ActiveState Corp.) based on
Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC v.1200 32 bit
(Intel)] on win32


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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:34

Message:
Logged In: YES 
user_id=304464

On my linux system does:
>>> import time
>>> time.strftime("%a",(1900,1,1, 13,0,0, -3,0,-1))
'\x0e'

Python 2.3.3c1 (#2, Dec  6 2003, 16:44:56)
[GCC 3.3.3 20031203 (prerelease) (Debian)] on linux2

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 12:32

Message:
Logged In: YES 
user_id=304464

Also, please have a look at:
https://sourceforge.net/tracker/index.php?func=detail&aid=898253&group_id=5470&atid=105470

at the same time.

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-15 17:23

Message:
Logged In: YES 
user_id=31435

I assume this is specific to Python on Windows using 
Microsoft's C, since this workalike plain C program also dies 
with a memory error while in the bowels of MS's strftime():

#include <stdio.h>
#include <time.h>

void main() {
    struct tm t;
    char buf[256];
    size_t i;

    t.tm_year = 1900 - 1900;
    t.tm_mon = 1 - 1;
    t.tm_mday = 1;
    t.tm_hour = 13;
    t.tm_min = 0;
    t.tm_sec = 0;
    t.tm_wday = -3;
    t.tm_yday = 0;
    t.tm_isdst = -1;

    printf("calling strftime\n");
    i = strftime(buf, sizeof(buf), "%a", &t);
    printf("i: %d\n", i);
}

The problem is the negative value for tm_wday.  MS strftime 
isn't defensive, and uses the negative tm_wday to index into 
nonsense memory.  Ironically, if C had defined the % operator 
in the sane way (meaning Python's way <wink>), a negative 
tm_wday wouldn't have survived for the C library function to 
see.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-02-15 15:41

Message:
Logged In: YES 
user_id=80475

It is expected.  Well, now that I've confirmed it on Py2.3.3
and Py2.4, yes ;-) 

Is it desirable?  Heck no.

Brett, can you take a look at this?

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

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

From noreply at sourceforge.net  Mon Mar  1 23:54:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 23:55:11 2004
Subject: [ python-Bugs-873652 ] Platform module not documented
Message-ID: <E1Ay1vn-0002oV-00@sc8-sf-web1.sourceforge.net>

Bugs item #873652, was opened at 2004-01-09 01:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=873652&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Simon Brunning (brunns)
Assigned to: Brett Cannon (bcannon)
Summary: Platform module not documented

Initial Comment:
The platform module isn&#039;t mentioned in the standard
ducumentation, so far as I can see, though the
doc-strings look pretty good.

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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-01 20:54

Message:
Logged In: YES 
user_id=357491

OK, added as rev #1.2.2.1 .

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

Comment By: Brett Cannon (bcannon)
Date: 2004-01-09 22:10

Message:
Logged In: YES 
user_id=357491

The LaTeX docs are in 2.4 .  They have not been backported to 2.3 
.

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

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

From noreply at sourceforge.net  Mon Mar  1 23:57:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  1 23:57:10 2004
Subject: [ python-Bugs-883604 ] locale specific problem in test_strftime.py
Message-ID: <E1Ay1xp-0003r4-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: George Yoshida (quiver)
>Assigned to: Brett Cannon (bcannon)
Summary: locale specific problem in test_strftime.py

Initial Comment:
test/test_strftime.py compares an expectation and a 
result by regular expressions, but the pattern isn&#039;t 
escaped. So if the expectation includes a metacharacter,
  expectation == result
and
  re.match(expectation, result)
do not always return the same value.

In my case on Japanese Windows, time.tzname returns
  (&#039;\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;, &#039;\x93
\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;)
The output contains parentheses. 
This resuls in a message:
  Conflict for nonstandard &#039;%Z&#039; format (time zone name):
    Expected ???? (?W????), but got ???? (?W????)
re.match(foo, bar) != (foo == bar)

One workaround I can think of is changing re.match(e
[1], result) back to result == e[1].


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

Comment By: Brett Cannon (bcannon)
Date: 2004-01-29 18:23

Message:
Logged In: YES 
user_id=357491

That's not what I meant by the comment; sorry for not being 
clearer.  I meant is whether test_strftime's existence is because of 
Jython.

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

Comment By: George Yoshida (quiver)
Date: 2004-01-29 03:54

Message:
Logged In: YES 
user_id=671362

> Is  this for Jython or something?
No, it's Python 2.3.3 on Windows 2000.

time zone is classified as non standard(unpredictable) so it 
might be difficult to make test_stftime.py to support all 
locales. There are so many issues.

FYI, I checked time.tzname on other platforms.

# Jython
Jython 2.1 on java1.4.2 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname
('JST', 'JST')  # Japanese Standard Time

# Linux
On RHL 9.0(Python 2.2/2.3), time.tzname returns ('JST', 'JST').

They pass the test.


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

Comment By: Brett Cannon (bcannon)
Date: 2004-01-27 00:28

Message:
Logged In: YES 
user_id=357491

Does anyone know why we even have test_strftime?  It isn't like 
we have our own implementation and there are basic tests in 
test_time to make sure the wrapper around the C function works.  
I know the test module says it is for sanity checks, but if it fails 
legitimately on a platform there is not much we can do about it.  
Is this for Jython or something?

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

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

From noreply at sourceforge.net  Tue Mar  2 04:22:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 04:22:55 2004
Subject: [ python-Bugs-835353 ] logging.StreamHandler encodes log message in
	UTF-8
Message-ID: <E1Ay66t-0000jV-00@sc8-sf-web2.sourceforge.net>

Bugs item #835353, was opened at 2003-11-03 23:45
Message generated for change (Comment added) made by vdvo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835353&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Vaclav Dvorak (vdvo)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.StreamHandler encodes log message in UTF-8

Initial Comment:
For some reason that I do not see,
logging.StreamHandler in Python 2.3 insists on writing
plain non-Unicode strings to the stream, and the
encoding is hard-coded as UTF-8:

            if not hasattr(types, "UnicodeType"): #if
no unicode support...
                self.stream.write("%s\n" % msg)
            else:
                try:
                    self.stream.write("%s\n" % msg)
                except UnicodeError:
                    self.stream.write("%s\n" %
msg.encode("UTF-8"))

This behaviour is neither documented nor reasonable.
Files can be perfectly able to write Unicode strings
(e.g., through the use of codecs.EncodedFile or with a
default encoding of sys.stdout), and even if they are
not, UTF-8 is hardly the only choice for an encoding. I
propose to simply replace the above code with:

self.stream.write(msg)
self.stream.write("\n")


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

>Comment By: Vaclav Dvorak (vdvo)
Date: 2004-03-02 10:22

Message:
Logged In: YES 
user_id=545628

Hmmm... I can't remember what the exact problem was, but now
that I look at it again, I see that it must have been my
error. What a poor bug report this is. :-( Sorry.

Still, I'd like the encoding to be configurable: UTF-8 can
stay as the default, but it would be nice to have an option
to use, say, "iso-8859-2" or "windows-1250".

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

Comment By: Vinay Sajip (vsajip)
Date: 2004-03-01 13:10

Message:
Logged In: YES 
user_id=308438

Notice that UTF-8 is only used if a UnicodeError is detected. 
By default, "%s\n" % msg is written to the stream using the 
stream's write(). If the stream can handle this without raising 
a UnicodeError, then UTF-8 will not be used. Is there a 
specific use case/test script which demonstrates a problem?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-05 21:30

Message:
Logged In: YES 
user_id=21627

That would be an incompatible change, of course, as you then
may get encoding errors where you currently get none.

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

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

From noreply at sourceforge.net  Tue Mar  2 08:32:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 08:32:39 2004
Subject: [ python-Bugs-835353 ] logging.StreamHandler encodes log message in
	UTF-8
Message-ID: <E1AyA0d-0008Pp-00@sc8-sf-web1.sourceforge.net>

Bugs item #835353, was opened at 2003-11-03 22:45
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=835353&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Vaclav Dvorak (vdvo)
Assigned to: Vinay Sajip (vsajip)
Summary: logging.StreamHandler encodes log message in UTF-8

Initial Comment:
For some reason that I do not see,
logging.StreamHandler in Python 2.3 insists on writing
plain non-Unicode strings to the stream, and the
encoding is hard-coded as UTF-8:

            if not hasattr(types, "UnicodeType"): #if
no unicode support...
                self.stream.write("%s\n" % msg)
            else:
                try:
                    self.stream.write("%s\n" % msg)
                except UnicodeError:
                    self.stream.write("%s\n" %
msg.encode("UTF-8"))

This behaviour is neither documented nor reasonable.
Files can be perfectly able to write Unicode strings
(e.g., through the use of codecs.EncodedFile or with a
default encoding of sys.stdout), and even if they are
not, UTF-8 is hardly the only choice for an encoding. I
propose to simply replace the above code with:

self.stream.write(msg)
self.stream.write("\n")


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

>Comment By: Vinay Sajip (vsajip)
Date: 2004-03-02 13:32

Message:
Logged In: YES 
user_id=308438

If you want to use some other encoding, why not use a 
stream created using codecs.open(), and if necessary use a 
Formatter which is Unicode-aware to convert from msg + args 
to the formatted message? Then the exception handler should 
never be invoked.

Or, do you mean, for the exception handler? I think UTF-8 is 
OK as the default, since it is the most commonly used. I may 
consider making this configurable for a future release, if there 
is enough demand; for now you can patch it yourself.

I'll close this bug report now, I assume that's OK with you?

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

Comment By: Vaclav Dvorak (vdvo)
Date: 2004-03-02 09:22

Message:
Logged In: YES 
user_id=545628

Hmmm... I can't remember what the exact problem was, but now
that I look at it again, I see that it must have been my
error. What a poor bug report this is. :-( Sorry.

Still, I'd like the encoding to be configurable: UTF-8 can
stay as the default, but it would be nice to have an option
to use, say, "iso-8859-2" or "windows-1250".

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

Comment By: Vinay Sajip (vsajip)
Date: 2004-03-01 12:10

Message:
Logged In: YES 
user_id=308438

Notice that UTF-8 is only used if a UnicodeError is detected. 
By default, "%s\n" % msg is written to the stream using the 
stream's write(). If the stream can handle this without raising 
a UnicodeError, then UTF-8 will not be used. Is there a 
specific use case/test script which demonstrates a problem?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-11-05 20:30

Message:
Logged In: YES 
user_id=21627

That would be an incompatible change, of course, as you then
may get encoding errors where you currently get none.

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

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

From noreply at sourceforge.net  Tue Mar  2 09:20:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 09:20:31 2004
Subject: [ python-Bugs-908316 ] pdb should hash stdout
Message-ID: <E1AyAl2-0003f7-00@sc8-sf-web4.sourceforge.net>

Bugs item #908316, was opened at 2004-03-02 16:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908316&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Miki Tebeka (tebeka)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb should hash stdout

Initial Comment:
pdb should store a local copy of stdout and use it.

The problem:
I&#039;ve used pdb with a script that uses fileinput.input
with inplace=1
stdout is redirected and I can&#039;t see the pdb prompt
(which is directory to the output file).

Miki


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

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

From noreply at sourceforge.net  Tue Mar  2 12:41:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 12:41:17 2004
Subject: [ python-Bugs-908441 ] default index for __getslice__ is not
	sys.maxint
Message-ID: <E1AyDtJ-00016V-00@sc8-sf-web1.sourceforge.net>

Bugs item #908441, was opened at 2004-03-02 17:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908441&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Drochner (drochner)
Assigned to: Nobody/Anonymous (nobody)
Summary: default index for __getslice__ is not sys.maxint

Initial Comment:
(This applies also to __setslice__ and possibly more.)
(This was already present in Python-2.2.)

If the upper slice index is omitted, a default is
passed to the __getslice__ method.
Documentation claims this is sys.maxint.
This is wrong if INT_MAX and LONG_MAX differ; what
is passed is INT_MAX while sys.maxint is LONG_MAX.

I&#039;m not sure whether to call it a code bug or a
documentation bug; at least there is code out there
which compares to sys.maxint.

The whole code path from ceval.c:_PyEval_SliceIndex()
to operator.c:op_getslice() to 
abstract.c:PySequence_GetSlice() to
classobject.c:instance_slice() has just room for
an "int", so a code fix is pretty invasive...

A small test program to check this:
==========
import sys

class sl(object):
        def __getslice__(self, a, b):
                return (a, b)

print "sys.maxint = %ld" % sys.maxint
bounds = sl()[:]
print "default bounds = [%ld, %ld]" % bounds
==========
gives on NetBSD/amd64:
sys.maxint = 9223372036854775807
default bounds = [0, 2147483647]



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

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

From noreply at sourceforge.net  Tue Mar  2 12:42:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 12:42:22 2004
Subject: [ python-Bugs-902037 ] relative on-disk SYSTEM id handling is
	incorrect
Message-ID: <E1AyDuK-00049u-00@sc8-sf-web3.sourceforge.net>

Bugs item #902037, was opened at 2004-02-22 02:13
Message generated for change (Comment added) made by crhode
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902037&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: relative on-disk SYSTEM id handling is incorrect

Initial Comment:
XML.sax.saxutils.prepare_input_source checks os.path.isfile on a 
relative path without first combining it with the base path.  
Attached patch is against CVS HEAD (which is also broken, 
in the exact same way, so I imagine the patch should apply cleanly 
to 2.3).

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

Comment By: Chuck Rhode (crhode)
Date: 2004-03-02 11:42

Message:
Logged In: YES 
user_id=988879

See also Bugs 788931 and 616431.  -ccr-

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

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

From noreply at sourceforge.net  Tue Mar  2 12:44:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 12:44:18 2004
Subject: [ python-Bugs-788931 ] resolving relative paths for external
	entities with xml.sax
Message-ID: <E1AyDwE-0004HU-00@sc8-sf-web3.sourceforge.net>

Bugs item #788931, was opened at 2003-08-14 15:31
Message generated for change (Comment added) made by crhode
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788931&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bart Vanhaute (bartvh)
Assigned to: Nobody/Anonymous (nobody)
Summary: resolving relative paths for external entities with xml.sax

Initial Comment:
[This is a copy of a message posted on comp.lang.python
for which I did not see any response. After some
reflection, I began to see it as a bug in python, so
here is the bug report.]

I have a set of XML documents that use external entity
definitions for which I am having problems parsing them
using python and xml.sax. The problem is with the
resolution of relative paths in these. 
An example:

dir1/test.xml:
	<?xml version="1.0"?>
	<!DOCTYPE test SYSTEM " ../dir2/test.dtd">
	<test>&ent;</test>

dir2/test.dtd:
	<!ENTITY ent SYSTEM "test.inc">
	<!ELEMENT test (#PCDATA)>

dir2/test.inc:
	external entity test

>From what I understand of XML specs, relative paths in
external entities are relative to the location of the
document *in which they are defined*. However, using
xml.sax (which calls expat, I presume), the paths are
resolved relative to the current working directory. So
the parser can not find the test.inc when the current
working directory is e.g. dir1.

I do not see how creating an EntityResolver would help
here: how do I know against what base path I have to
resolve the entity? 

(the same thing can be read without problems with other
xml parser, for instance in Java).

Bart.


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

Comment By: Chuck Rhode (crhode)
Date: 2004-03-02 11:44

Message:
Logged In: YES 
user_id=988879

See also Bugs 902037 and 616431.  -ccr-

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

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

From noreply at sourceforge.net  Tue Mar  2 14:06:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 14:06:59 2004
Subject: [ python-Bugs-900580 ] IDLE docs broken on OSX
Message-ID: <E1AyFEE-0003iT-00@sc8-sf-web2.sourceforge.net>

Bugs item #900580, was opened at 2004-02-19 14:59
Message generated for change (Comment added) made by jbrandmeyer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900580&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jonathan Brandmeyer (jbrandmeyer)
Assigned to: Nobody/Anonymous (nobody)
Summary: IDLE docs broken on OSX

Initial Comment:
Under Apple&#039;s OSX operating system, the variable
sys.platform is named&#039;darwin&#039;.  In at least one place,
idle makes a test to see if thecurrent platform is MS
Windows by checking for the substring &#039;win&#039;
insys.platform, which leads to incorrect behavior on
the Mac.

In particular, in
lib/python2.3/idlelib/EditorWindow.py, member function
EditorWindow.python_docs() behaves incorrectly on OS X.
 I believe that if the test for MS Windows is
completely removed that you will get correct behavior
on all platforms, based on my reading of the webbrowser
module source.

Please change that function to the following (near line
313):    

>>>    def python_docs(self, event=None):
>>>        webbrowser.open(self.help_url)
>>>        return "break"


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

>Comment By: Jonathan Brandmeyer (jbrandmeyer)
Date: 2004-03-02 14:06

Message:
Logged In: YES 
user_id=676765

There are a series of changes related to the one I mentioned
before.  In addition, Safari requires the full URI to local
files when started via the webbrowser module (or via several
other methods) even though it automatically prepends that
string when entered in the address bar.  So, I have an
additional patch that makes appropriate modifications for
file:/// prefixed paths.

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

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

From noreply at sourceforge.net  Tue Mar  2 19:34:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 19:35:06 2004
Subject: [ python-Bugs-907575 ] "\textttNone" in Index
Message-ID: <E1AyKLh-0007P9-00@sc8-sf-web1.sourceforge.net>

Bugs item #907575, was opened at 2004-03-01 23:22
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=907575&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: "\textttNone" in Index

Initial Comment:
In the index of the Python 2.3.3 documentation (as 
started from IDLE on Windows XP), the references to

None
None object
NotImplemented
NotImplemented object

are shown as

\textttNone
\textttNone object
\textttNotImplemented
\textttNotImplemented object

and are therefore at the wrong place.

This is probably due to a typo.


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

Comment By: George Yoshida (quiver)
Date: 2004-03-03 09:34

Message:
Logged In: YES 
user_id=671362

This is a duplicate of bug #820344 and has been fixed.

See :
  http://www.python.org/sf/820344
commit log:
  http://mail.python.org/pipermail/python-checkins/2004-
January/039399.html

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

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

From noreply at sourceforge.net  Tue Mar  2 23:29:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  2 23:29:15 2004
Subject: [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E1AyO0H-0003U8-00@sc8-sf-web2.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Brett Cannon (bcannon)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-02 20:29

Message:
Logged In: YES 
user_id=357491

To force this error I inserted code to set all attributes of the threading 
module to None and then throw and exception.  After commenting out 
the two calls to currentThread in _Condition the thrown exception to 
trigger the problem propogated to the top correctly.

I did have the clean-up function give out since I set *everything* to 
None, but it doesn't look like a normal issue as shown in the exception 
traceback in the OP.  I don't think it is an issue.

So it seems commenting the two calls to currentThread in _Condition 
solves the problem.  But since this is threading code and the comment 
explicitly states it is for the side-effect I am going to try to get a second 
opinion.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-16 20:59

Message:
Logged In: YES 
user_id=357491

Does anyone know how to cause this error in isolation?  I have tried a 
bunch of different ways but cannot cause an exception to be raised at the 
correct point in Threading.__bootstrap() to lead to self.__stop() to be 
called while the interpreter is tearing itself down.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:18

Message:
Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.

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

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 06:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

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

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

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

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

From noreply at sourceforge.net  Wed Mar  3 04:40:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 04:41:05 2004
Subject: [ python-Bugs-215126 ] Over restricted type checking on eval()
	function
Message-ID: <E1AySrv-00029R-00@sc8-sf-web1.sourceforge.net>

Bugs item #215126, was opened at 2000-09-22 21:36
Message generated for change (Comment added) made by pfremy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=215126&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: Later
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Over restricted type checking on eval() function

Initial Comment:
The built-in function eval() takes a string argument and a dictionary.  The second argument should allow any instance which defines __getitem__ as opposed to just dictionaries.

The following example creates a type error:
  eval, argument 2: expected dictionary,   instance found

class SpreadSheet:
    _cells = {}
    def __setitem__( self, key, formula ):
        self._cells[key] = formula
    def __getitem__( self, key ):
        return eval( self._cells[key], self )

ss = SpreadSheet()
ss[&#039;a1&#039;] = &#039;5&#039;
ss[&#039;a2&#039;] = &#039;a1*5&#039;
ss[&#039;a2&#039;]


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

Comment By: Philippe Fremy (pfremy)
Date: 2004-03-03 10:40

Message:
Logged In: YES 
user_id=233844

I have exactly the same need as the original poster. The
only difference in my case is that I inhreted a dictionnary.

I want to use the eval() function as a simple expression
evaluator. I have the
follwing dictionnary:
d['a']='1'
d['b']='2'
d['c']='a+b'

I want the following results:
d[a] -> 1 
d[b] -> 2 
d[c] -> 3

To do that, I was planning to use the eval() function and
overloading the __getitem__ of the global or local dictionnary:

class MyDict( dict ) : 
	def __getitem__( self, key ):
		print "__getitem__", key
		val = dict.__getitem__( self, key )
		print "val = '%s'" % val
		return eval( val , self )

But it does not work:
d[a]:
__getitem__ a
val = '1'
-> 1

d[b]:
__getitem__ b
val = '2'
-> 2

d[c]:
__getitem__ c
val = 'e+1'
ERROR
Traceback (most recent call last):
  File "test_parse_jaycos_config.py", line 83, in testMyDict
    self.assertEquals( d['c'], 2 )
  File "parse_config_file.py", line 10, in __getitem__
    return eval( val , self )
  File "<string>", line 0, in ?
TypeError: cannot concatenate 'str' and 'int' objects

d['c'] did fetch the 'a+1' value, which was passed to eval.
However, eval()
tried to evaluate the expression using the content of the
dictionnary instead
of using __getitem__. So it fetched the string '1' for 'a'
instead of the value 1, so the result is not suitable for
the addition.



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

Comment By: Michael Chermside (mcherm)
Date: 2004-01-12 23:01

Message:
Logged In: YES 
user_id=99874

Hmm... I like this!

Of course, I am wary of adding *yet another* special double-
underscore function to satisfy a single special purpose, but 
this would satisfy all of *my* needs, and without any 
performance impact for lookups that are FOUND. Lookups that 
are NOT found would have a slight performance degrade (I 
know better than to speculate about the size of the effect 
without measuring it). I'm not really sure what percentage of 
dict lookups succeed.

At any rate, what are these "other contexts" you mention in 
which a __keyerror__ would "also be useful"? Because if we 
can find other places where it is useful, that significantly 
improves the usefulness.

OTOH, if the tests can be done ONLY for eval (I don't really 
think that's possible), then I'm certain no one cares about the 
performance of eval.

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

Comment By: Gregory Smith (gregsmith)
Date: 2004-01-12 20:38

Message:
Logged In: YES 
user_id=292741

This may be  a compromise solution, which could also be
useful in other contexts: What if the object passed
is derived from dict - presumably that doesn't help
because the point is to do low-level calls to the
actual dict's lookup functions.
 Now, suppose we modify the basic dict type, so
that before throwing
a KeyError, it checks to see if it is really a derived
object with a method __keyerror__, and if so, calls
that and returns its result (or lets it throw)?
Now you can make objects that look like dicts, and
act like them at the low level, but can automatically
populate themselves when non-existent keys are requested.
Of course, __keyerror__('x') does not have to make
an 'x' entry in the dict; it could make no change, or
add several entries, depending on the desired semantics
regarding future lookups. It could be set up so that
every lookup fails and is forwarded by __keyerror__ to
the __getitem__ of another object, for instance.

The cost of this to the 'normal' dict lookup is that
the need to do PyDict_CheckExact() each time
a lookup fails.


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

Comment By: Michael Chermside (mcherm)
Date: 2003-12-16 16:37

Message:
Logged In: YES 
user_id=99874

I'll just add my voice as somebody who would find this to 
be "darn handy" if it could ever done without noticably 
impacting the speed of python code that DOESN'T use eval().

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

Comment By: Tim Peters (tim_one)
Date: 2000-09-23 06:18

Message:
Added to PEP 42.

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

Comment By: Tim Peters (tim_one)
Date: 2000-09-22 21:42

Message:
Changed Group to Feature Request.  Should be added to PEP 42 (I'll do that if nobody beats me to it).

CPython requires a genuine dict now for speed.  I believe JPython allows any mapping object.


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

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

From noreply at sourceforge.net  Wed Mar  3 04:58:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 04:59:02 2004
Subject: [ python-Bugs-908936 ] rexec.r_eval() does not work like eval()
Message-ID: <E1AyT9V-0005B8-00@sc8-sf-web3.sourceforge.net>

Bugs item #908936, was opened at 2004-03-03 10:58
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908936&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec.r_eval() does not work like eval()

Initial Comment:
I want to use the eval() function of python as simple
ultra-restricted expression evaluator. So, when
executing r_eval(), I want to pass a dictionnary of the
local and global variables, just like it is possible
with eval(). However, r_eval() does not allow it.

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

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

From noreply at sourceforge.net  Wed Mar  3 11:20:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 11:21:36 2004
Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX
Message-ID: <E1AyZ6k-0005VG-00@sc8-sf-web1.sourceforge.net>

Bugs item #728330, was opened at 2003-04-27 05:21
Message generated for change (Comment added) made by billbaxter26
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Don't define _SGAPI on IRIX

Initial Comment:
Python release:
  2.3b1
Platform:
  IRIX 6.5
  MIPSpro Compilers: Version 7.3.1.2m
Commands used:
  ./configure --prefix=/usr/local_cci/Python-2.3b1t
  make

The socket module fails to compile. The output from 
the compiler is attached.


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

Comment By: Bill Baxter (billbaxter26)
Date: 2004-03-03 11:20

Message:
Logged In: YES 
user_id=892601

Got it down to one error:
% > ./python Lib/test/test_socket.py
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 6, in ?
    import socket
  File "/usr/local/spider/lib/python2.3/socket.py", line 44,
in ?
    import _socket
ImportError: 210454:./python: rld: Fatal Error: unresolvable
symbol in
/usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so:
_xpg5_accept

xpg5_accept does appear in any library on our SGI's that are
only 1-2 years old. It does appear in libc in very recent
revisions of Irix (> 6.5.19?)

Does anyone know how to get Python 2.3 to avoid the use of
xpg5_accept?

Thanks


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

Comment By: Bill Baxter (billbaxter26)
Date: 2004-01-12 13:59

Message:
Logged In: YES 
user_id=892601

Has anyone encountered problems with different versions of
IRIX 6.5? I finally got sockets to work in Python2.3.3, but
only on the most up-to-date version of IRIX (uname -v =
01100304). On any other machine with a lower version
(archetecture doesn't seem to matter), I get messages which
all seem to be related to sockets:

152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_vsnprintf
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recv
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_connect
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_bind
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_sendto
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_setsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_accept
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recvfrom
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_socket
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockname

Upgrading all of our SGIs is not something I have control
over.


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

Comment By: Maik Hertha (mhertha)
Date: 2003-12-22 13:52

Message:
Logged In: YES 
user_id=768223

Sorry if there is something unclear.
Redefine means: Set a value which is required to satisfy
ifdef-statements in the header files. As you see in the
definitions, given in the comment, the value for _NO_XOPEN4
is set as a result of some dependencies automatically
defined. A redefinition of _SGIAPI in the socketmodule.c is
not sufficient alone. Therefore to satisfy all requirements
in the header files, you should set the values for
_NO_XOPEN4 and _NO_XOPEN5 also manually.
Howto do in socketmodule.c?
...
#define _SGIAPI 1
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
...
If you are familiar with regular expressions, then you will
know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4,
_NO_XOPEN5.

Sorry if there was something wrong in my comment.

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

Comment By: Bill Baxter (billbaxter26)
Date: 2003-12-22 10:49

Message:
Logged In: YES 
user_id=892601

Can someone please clarify mherta's comment from 2003-12-16?

How should we "redefine _NO_XOPEN[45] in the socketmodule.c
at the same position like the _SGIAPI redefinition"?

Should those lines of code be added to socketmodule.c, or
are they the source of the problem?

Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5]
or are they all different?

Thanks.

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

Comment By: Maik Hertha (mhertha)
Date: 2003-12-16 12:27

Message:
Logged In: YES 
user_id=768223

I've tested the latest Python 2.3.3c1 to compile. The
problem reported is still present. To avoid the error
messages, about the incompatible types of several
netdb-functions (like inet_pton), you should redefine
_NO_XOPEN[45] in the socketmodule.c at the same position
like the _SGIAPI redefinition. If there are error messages
that types like u_short and u_char are not defined, please
add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay).
If anybody don't need a executable compiled with MipsPro,
gcc from the freeware.sgi.com could be a choice.
The problem for this seems in /usr/include/standards.h:
#define _NO_XOPEN4	(!defined(_XOPEN_SOURCE) || 				(defined(_XOPEN_SOURCE) && 				(_XOPEN_SOURCE+0 >= 500)))
#define _NO_XOPEN5	(!defined(_XOPEN_SOURCE) || 				(defined(_XOPEN_SOURCE) && 				(_XOPEN_SOURCE+0 < 500)))
As the first option is true (_XOPEN_SOURCE is set to 600 in
pyconfig.h) the second option will be false. The constant
#define NI_NUMERICHOST  0x00000002  /* return numeric form
of hostname */
is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5
(/usr/include/netdb.h) which is always false.
In the manual pages there is a example which uses the
constant NI_NUMERICHOST and compiles without error message.
I'm not sure to cut off the file pyconfig.h from compiling
the socketmodule.c?

Any comments?

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

Comment By: Hans Nowak (zephyrfalcon)
Date: 2003-10-30 22:04

Message:
Logged In: YES 
user_id=173607

My $0.02...

Yesterday I successfully compiled Python 2.3.2, with socket
module. I'm using an O2 running IRIX 6.5.11f.

I didn't encounter any of the problems described before, and
had no problems with _SGIAPI or anything. The reason it
didn't compile was that u_long and u_char were not defined
in some places; /usr/include/netinet/tcp.h to be precise,
and a Python file (getaddrinfo.c).

I'm using gcc 3.3 (the one downloaded from freeware.sgi.com).

If anyone is interested, drop me a mail at hans at
zephyrfalcon.org and I'll put the binary online somewhere.

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

Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-24 15:59

Message:
Logged In: YES 
user_id=892601

Here's the output from 'gmake', using MIPSpro Compiler 7.30
on IRIX 6.5

Sorry, I don't know how to attach something using the "Add a
Comment" box. Is there another way to post?

The patch at
www.python.org/2.3.2/patches/sgi-socketmodule.patch was
edited into socketmodule.c :
#include <netdb.h>
#endif

/* GCC 3.2 on Irix 6.5 fails to define this variable at all.
Based on 
   the above code, I'd say that the SGI headers are just
horked. */
#if defined(__sgi) && !defined(INET_ADDRSTRLEN)
#define INET_ADDRSTRLEN 16
#endif

/* Generic includes */
#include <sys/types.h>
#include <signal.h>


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

cc -OPT:Olimit=0 -DNDEBUG  -n32 -O -I. -I./Include 
-DPy_BUILD_CORE  -c ./Modules/socketmodule.c -o
Modules/socketmodule.o
cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line =
195
  Macro "_SGIAPI" (declared at line 210 of
"/usr/include/standards.h") has an
          incompatible redefinition.

  #define _SGIAPI 1
          ^

cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198
  The identifier "socklen_t" is undefined.

  extern int iruserok_sa(const void *, socklen_t, int, const
char *,
                                       ^

cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145
  Macro "_SS_ALIGNSIZE" (declared at line 246 of
"/usr/include/sys/socket.h")
          has an incompatible redefinition.

  #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG))
          ^

cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line =
822
  The identifier "NI_NUMERICHOST" is undefined.

                NI_NUMERICHOST);
                ^

cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line =
3054
  A value of type "int" cannot be assigned to an entity of
type "const char *".

        retval = inet_ntop(af, packed, ip, sizeof(ip));
               ^

3 errors detected in the compilation of
"./Modules/socketmodule.c".
gmake: *** [Modules/socketmodule.o] Error 2


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

Comment By: Michael Hudson (mwh)
Date: 2003-10-23 06:25

Message:
Logged In: YES 
user_id=6656

Just to be clear,  please "attach" the build rather than
pasting it inline.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-22 22:19

Message:
Logged In: YES 
user_id=29957

Did you try 2.3.2 with the patch from the 2.3.2 build bugs page?

If it failed, please post the build log of the failing bit
to this bug.
 

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

Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-22 14:26

Message:
Logged In: YES 
user_id=892601

Has there been any progress since August on getting
Python-2.3 to compile on IRIX 6.5? I really need to have
sockets working to use python.

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

Comment By: Maik Hertha (mhertha)
Date: 2003-08-14 07:37

Message:
Logged In: YES 
user_id=768223

I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m
on a FUEL 600Mhz.
The situation seems a little bit strange on this system. But
I have luck and get it compiled. As the current
implementation is not clean, my resolution also. Which
should be changed to get it work.
The manpage for gethostbyaddr_r says:
#include <sys/types>
#include <sys/socket>
#include <netinet/in.h>
#include <netdb.h>
So I included this in the __sgi-clause in socketmodule.c.
Looking in the header-files shows, that some variables are
defined if 
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
are set, before the includes. This defines some more
variables, so that pyconfig.h should be changed.
#define HAVE_ADDRINFO 1
#define HAVE_SOCKADDR_STORAGE 1
Sure there are warnings about the redefinition of the
_(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests
don't fail. Also my applications run without exception or
coredump on FUEL, Octane, Octane 2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-01 08:10

Message:
Logged In: YES 
user_id=33168

Ralf, I will try to work on this, but it won't be for a week
or two probably.  Can you tell me which machines (by name)
work and doesn't work.  The only IRIX machine I seem to know
about it rattler.

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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-08-01 03:34

Message:
Logged In: YES 
user_id=71407

For the records:
The Python2.3 (final) socket module still does not 
compile under IRIX 6.5.20. It only compiles under 6.5.10.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 14:07

Message:
Logged In: YES 
user_id=31392

I applied a slight variant of Neal's patch and that seemed
to fix things.  It still seems wrong that we define _SGIAPI,
but that will have to wait for 2.3.1.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 09:54

Message:
Logged In: YES 
user_id=31392

I learned a little about inet_ntop() in the last few
minutes.  It looks like the size_t argument is an older
spelling, and the current POSIX says it should be socklen_t.
 Regardless, it looks like we're using the new definition
when IRIX is actually providing the older definition.

Neal attached a patch that looks like it should clean up the
problem.  Have you tried it?  I think a better solution
would be to teach configure how to find inet_ntop() via
netdb.h, but that's probably too hard to get done in the new
couple of hours.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 09:42

Message:
Logged In: YES 
user_id=31392

There seem to be two causes of worry.  The actual compiler
error in your build log and the use of _SGIAPI that
Casavanti warns again.

It looks like the compiler problems is because our
inet_ntop() prototype is wrong.  That is Python says the
last argument is a socklen_t, but IRIX and Linux man pages
both say size_t.  Perhaps size_t and socklen_t are different
sizes on IRIX, but not on Linux.  What happens if you change
it to size_t?

The problematic code would appear to be these lines from
socketmodule.c:

#if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI
/* make sure that the reentrant (gethostbyaddr_r etc)
   functions are declared correctly if compiling with
   MIPSPro 7.x in ANSI C mode (default) */
#define _SGIAPI 1
#include "netdb.h"
#endif

It's the only use the _SGIAPI symbol that Casavant says we
shouldn't use.  What happens if you remove the use _SGIAPI,
i.e. just make it

#if defined(__sgi) && _COMPILER_VERSION > 700 
/* make sure that the reentrant (gethostbyaddr_r etc)
   functions are declared correctly if compiling with
   MIPSPro 7.x in ANSI C mode (default) */
#include "netdb.h"
#endif


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-16 20:27

Message:
Logged In: YES 
user_id=71407

We have confirmed that the socket module in Python 2.3b1 
and 2.3b2 fails to compile under these versions of IRIX:

6.5.10, MIPSpro 7.3.1.2m
6.5.19, MIPSpro 7.3.1.3m
6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge)

If Python 2.3 goes out without a working socket module it 
will be useless for many people in science where IRIX is still 
found quite frequently. Maybe even worse, we will also no 
longer be able to advertise Python as a language that "runs 
everywhere."


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-15 18:37

Message:
Logged In: YES 
user_id=71407

Date: Tue, 15 Jul 2003 15:06:25 -0500
From: "Brent Casavant" <bcasavan@sgi.com>
To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> 
Subject: Re: IRIX & Python 

Ralf,

I read through the sourceforge report.  I don't have a 
sourceforge
account so I didn't add there, but feel free to distribute my
ramblings.

First, they should be very careful about what version of the
operating system they are using.  Real IPv6 support was only
added a few releases ago (6.5.20 I believe, though my 
memory
is hazy).  Some of the functions/macros corresponding to 
IPv6
were introduced prior to that point, but implementation may
not have been complete.  If they have to play tricks with
#define values to get a symbol recongnized it most likely
means that SGI didn't intend for that symbol to be used yet.

I suspect the problems they are seeing are because they are
using some version of IRIX 6.5.x that includes inet_ntoa()
definitions under _SGIAPI, but for which real support was
not yet complete.  The namespace of symbols that begin 
with a
single underscore and a capital letter is reserved for the OS
vendors, and the fact that someone is trying to manually 
insert
a definition of _SGIAPI into the source should be a big red
warning flag.

That said, there is a correct method to deal with the new
capabilities of IRIX 6.5.x over time.  This comes in two
parts.  A better explanation is in /usr/include/optional_sym.h

First, when a new symbol is added to IRIX, the corresponding
header file will always have the following line in it:

	#pragma optional some_new_symbol

The presence of this #pragma will cause the linker to not
complain if the symbol is missing when the executable is
linked.  If SGI neglects to do so it is a bug that should
be reported to us.

The second part is that calls to these "optional" symbols
should be protected by a run-time check to see if the symbol
is actually present.  Just like this:

	#include <optional_sym.h>
	#include <header_file_for_some_new_symbol.h>

	. . .

	if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) {
		/* New function is present, use it */
		qux = some_new_symbol(foo, bar, baz);
	} else {
		/* New function isn't present, do 
something else */
		qux = builtin_some_new_symbol(foo, bar, 
baz);
	}

This ensures that a single executable will be able to function
properly (or at least degrade gracefully) on all version of
IRIX 6.5.x.  In other words you can compile on 6.5.20 and 
run
on 6.5.8, or vice versa.

In particular, this means that compile-time detection of 
features
such as inet_ntoa() is incorrect for IRIX 6.5.x -- these 
decisions
should be made at run-time instead.  If the decision is made 
at
compile time the executable may well not execute on an older
version of IRIX 6.5.x.  Unfortunately GNU configure is not 
equipped
to utilize such advanced binary-compatability mechanisms, 
so there's
no "easy" way to get GNU configure'd software to run across 
all
IRIX 6.5.x releases, short of compiling only on the original
non-upgraded version of IRIX 6.5.

Hope that helps,
Brent Casavant

On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote:

> We are developing a Python-based (www.python.org) 
application for
> IRIX. Until now the Python IRIX port was fully supported, 
but the last
> two beta releases of Python (2.3b1 and 2.3b2) make me 
increasingly
> worried because the crucial socket module (TCP/IP 
sockets) fails to
> build. A while ago I've filed a bug report, but the Python 
developers
> appear to be stuck:
>
> 
https://sourceforge.net/tracker/?
func=detail&aid=728330&group_id=5470&atid=105470
>
> Is there a way to bring this to the attention of developers 
at SGI to
> hopefully get some help?
>
> Thank you in advance!
>       Ralf
>

-- 
Brent Casavant      Silicon Graphics, Inc.  Where am I?  And 
what am I
IRIX O.S. Engineer  http://www.sgi.com/     doing in this 
handbasket?
bcasavan@sgi.com    44.8562N 93.1355W 860F      -- 
Unknown


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-06-30 10:21

Message:
Logged In: YES 
user_id=71407

The socket module still fails to compile with Python 
2.3b2, in addition to two other extensions. The full make 
log is attached.


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

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-22 02:47

Message:
Logged In: YES 
user_id=21627

I think it would be best if detect presence of
inet_aton/inet_pton. Is IPv6 support possible on this
system? Then it would be best if that was detected, as well.

If it is not possible to detect aton/pton/ipv6, what is the
problem with not using them?

I'd like to have a look at the relevant headers (in
particular to understand the duplicate definition of
_SGIAPI), indeed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-21 19:35

Message:
Logged In: YES 
user_id=33168

Argh!!!  This is a nightmare.  The attached hack ^h^h^h
patch fixes the problem, but ...

_SGIAPI needs to be defined (~192 in socketmodule.c) in
order to get the prototypes for inet_aton, inet_pton.  But
_SGIAPI can't be defined in the standard header files
because XOPEN_SOURCE is defined.

Martin, do you have any other suggestions?  I don't see how
to do this right within configure.  If you want I can send
you the header file(s).

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

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 13:41

Message:
Logged In: YES 
user_id=150999

I had the same problem compiling socket on Irix.
We did find that on our system ENABLE_IPV6 is not define and
all the error are cause by that.
  
System that do not enable IPV6 are not well supported with
the socketmodule.c code.
We were able to compile socket after making few change in
the code: 
I am not sure if I did it right but it compile.
I will post my patch but I do not see any place to attach my
file
example: See line 2794,2800

+ #ifdef ENABLE_IPV6
        char packed[MAX(sizeof(struct in_addr),
sizeof(struct in6_addr))];
+ #else
+       char packed[sizeof(struct in_addr)];
+ #endif

I am not sure how to post the patch or file.


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-05-05 14:44

Message:
Logged In: YES 
user_id=71407

This is not in my area of expertise, but I've tried a couple of 
(probably stupid) things:

#include <standards.h> in socketmodule.c instead of #define 
_SGIAPI.
This resulted in even more errors.

./configure --disable-ipv6
Same errors as before.

I am lost here. Sorry. But you still have ssh access to 
rattler.lbl.gov if that helps. Accounts for other Python developers 
are a possibility.


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

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-04 08:39

Message:
Logged In: YES 
user_id=21627

Can you analyse these compiler errors in more detail,
please? What, in your opinion, is causing these problems,
and how would you correct them?

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

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

From noreply at sourceforge.net  Wed Mar  3 14:53:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 14:54:10 2004
Subject: [ python-Bugs-909295 ] segmentation fault
Message-ID: <E1AycRG-00065T-00@sc8-sf-web1.sourceforge.net>

Bugs item #909295, was opened at 2004-03-03 14:53
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909295&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chuck Mason (cemason)
Assigned to: Nobody/Anonymous (nobody)
Summary: segmentation fault

Initial Comment:

$ python
Python 2.3.1 (#1, Sep 23 2003, 10:07:41)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def func(*a): print a
...
>>> func((1, 2, 3)
... )Segmentation fault


--------------------------
Not sure what other information you need, but I tested
it on several machines with the same version and it
seems to be hardware/other library independant.



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

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

From noreply at sourceforge.net  Wed Mar  3 13:07:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 15:18:16 2004
Subject: [ python-Bugs-909226 ] Can Not import a module with - (DASH) in
	filename
Message-ID: <E1Ayamj-0000LN-00@sc8-sf-web3.sourceforge.net>

Bugs item #909226, was opened at 2004-03-03 13:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909226&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can Not import a module with - (DASH) in filename

Initial Comment:
I am currently running, Python 2.3.2 (#49, Oct  2 2003, 
20:02:00) [MSC v.1200 32 bit (Intel)] on win32.

I have a file that I am attempting to import "report-
manager.py", that refuses to be imported.

C:\develope\versions>python
Python 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import report-manager
  File "<stdin>", line 1
    import report-manager
                 ^
SyntaxError: invalid syntax
>>> import "report-manager"
  File "<stdin>", line 1
    import "report-manager"

If this is not a bug, and is indeed expected behavior, is 
this documented in any manner?  I have not found any 
references covering this.

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

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

From noreply at sourceforge.net  Wed Mar  3 15:24:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 15:24:50 2004
Subject: [ python-Bugs-909308 ] Embedded Python Interpreter in MFC apps leaks
Message-ID: <E1Aycuk-0008Q6-00@sc8-sf-web3.sourceforge.net>

Bugs item #909308, was opened at 2004-03-03 21:24
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909308&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David (yakumoklesk)
Assigned to: Nobody/Anonymous (nobody)
Summary: Embedded Python Interpreter in MFC apps leaks

Initial Comment:
I am embedding the python interpreter in my MFC 
multidocument 
application. In the mainframe class, at creation time, I 
do Py_Initialize(). 
When the program comes to an end, in the mainframe 
destructor, I do 
Py_Finalize(). No Pyobject is created, no 
PyRun_SimpleString is called, 
nothing but the Py_Initialize() and the Py_Finalize() only. 
But those simple 
calls make the program to report leaks, that when are 
breakpointed with 
_CrtSetBreakAlloc (using <crtdbg.h> lib) the 
code "leaked" stops inside 
python code.

I made a new project from scratch (multidocument also), 
without adding no line except 
Py_Initialize and Py_Finalize, an the leak already exists. I 
did a Dialog 
application and used the same calls, and the leak 
already exists. But 
when I make a non MFC application, the leak do not 
exists.

Is this bug a real python bug, or its due an MFC bad 
implementation of 
memory allocation? Please, I need to know if there is a 
way to avoid 
this leaks, because I want to control what leaks are 
really mine (c++), 
what leaks are caused by c++ to python wrapped code, 
and what leaks 
are just python, to have a better control of the 
processes of my 
application.

I am using Python 2.3.3 and VC++ 6.0 with service pack 
5 on a Windows XP Professional with an Athlon XP.

David.

If any information is needed about the leaks and the 
lines that report to be leaked, just tell me and I&#039;ll made 
an inform.

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

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

From noreply at sourceforge.net  Wed Mar  3 15:26:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 15:28:09 2004
Subject: [ python-Bugs-909226 ] Can Not import a module with - (DASH) in
	filename
Message-ID: <E1AycwL-0003HD-00@sc8-sf-web2.sourceforge.net>

Bugs item #909226, was opened at 2004-03-03 12:07
Message generated for change (Settings changed) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909226&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Nobody/Anonymous (nobody)
Summary: Can Not import a module with - (DASH) in filename

Initial Comment:
I am currently running, Python 2.3.2 (#49, Oct  2 2003, 
20:02:00) [MSC v.1200 32 bit (Intel)] on win32.

I have a file that I am attempting to import "report-
manager.py", that refuses to be imported.

C:\develope\versions>python
Python 2.3.2 (#49, Oct  2 2003, 20:02:00) [MSC v.1200 
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more 
information.
>>> import report-manager
  File "<stdin>", line 1
    import report-manager
                 ^
SyntaxError: invalid syntax
>>> import "report-manager"
  File "<stdin>", line 1
    import "report-manager"

If this is not a bug, and is indeed expected behavior, is 
this documented in any manner?  I have not found any 
references covering this.

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

>Comment By: Skip Montanaro (montanaro)
Date: 2004-03-03 14:26

Message:
Logged In: YES 
user_id=44345

Yes it is expected and documented behavior.  Module names as 
mentioned in import statements must be valid Python identifiers.  
Hyphens are not allowed in identifiers.  Try renaming the file to 
reportmanager.py or report_manager.py.


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

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

From noreply at sourceforge.net  Wed Mar  3 13:13:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar  3 16:03:39 2004
Subject: [ python-Bugs-909230 ] bug in idna-encoding-module
Message-ID: <E1Ayas9-0000EC-00@sc8-sf-web4.sourceforge.net>

Bugs item #909230, was opened at 2004-03-03 18:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rumpeltux (rumpeltux)
Assigned to: Nobody/Anonymous (nobody)
Summary: bug in idna-encoding-module

Initial Comment:
in /usr/lib/python2.3/encodings/idna.py, line 175 it goes:
lables = input.split(&#039;.&#039;)
which causes the interpreter to stop executing the
program, but by changing it to
labels = dots.split(input)
everything&#039;s fine ;)

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

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

From noreply at sourceforge.net  Wed Mar  3 23:05:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 09:21:59 2004
Subject: [ python-Bugs-909295 ] segmentation fault
Message-ID: <E1Ayk7D-0003cb-00@sc8-sf-web3.sourceforge.net>

Bugs item #909295, was opened at 2004-03-03 14:53
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909295&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chuck Mason (cemason)
Assigned to: Nobody/Anonymous (nobody)
Summary: segmentation fault

Initial Comment:

$ python
Python 2.3.1 (#1, Sep 23 2003, 10:07:41)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def func(*a): print a
...
>>> func((1, 2, 3)
... )Segmentation fault


--------------------------
Not sure what other information you need, but I tested
it on several machines with the same version and it
seems to be hardware/other library independant.



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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-03 23:05

Message:
Logged In: YES 
user_id=80475

On WinMe, I cannot reproduce this on Py2.2.3,  Py2.3.3, or
Py2.4a0.

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

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

From noreply at sourceforge.net  Thu Mar  4 03:22:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 09:25:15 2004
Subject: [ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Message-ID: <E1Ayo7e-0003mK-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sankov Dmitry Alexandrovich (sankov_da)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.dispactcher: incorrect connect

Initial Comment:
When i use non-blocking socket, connect() method of
asyncore.dispatcher class looks like works incorrect.

Example: if connection have not established then socket
merely closed and handle_error not called and no
exception throwed.

One more example: if writable() and readble() methods
returns zero than handle_connect() will never be called
even if connection will be established.

Thanks.


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

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 11:22

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

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

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

From noreply at sourceforge.net  Thu Mar  4 03:23:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 09:25:17 2004
Subject: [ python-Bugs-887279 ] asyncore.py poll* missing urgent data
Message-ID: <E1Ayo8V-0003su-00@sc8-sf-web3.sourceforge.net>

Bugs item #887279, was opened at 2004-01-30 00:25
Message generated for change (Comment added) made by klimkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887279&group_id=5470

Category: Python Library
Group: Python 2.2.1 candidate
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.py poll* missing urgent data

Initial Comment:
According to the select.poll documentation, polling flags 
include POLLIN (regular data) and POLLPRI (urgent data).

asyncore poll2 and poll3 check readable objects for 
POLLIN, but do not check for POLLPRI.

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

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 11:23

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

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

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

From noreply at sourceforge.net  Thu Mar  4 03:23:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 09:25:20 2004
Subject: [ python-Bugs-777588 ] asyncore is broken for windows if connection
	is refused
Message-ID: <E1Ayo96-0003x0-00@sc8-sf-web3.sourceforge.net>

Bugs item #777588, was opened at 2003-07-25 18:43
Message generated for change (Comment added) made by klimkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777588&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Garth Bushell (garth42)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore is broken for windows if connection is refused

Initial Comment:
asyncore.poll is broken on windows. If a connection is
refused happens it will hang for ever and never raise
an exception.

The Select statment never checks the exfds. This is
needed as this is where windows reports failed
connections. The documentation in the microsoft
platform SDK mentions this. 

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/winsock/select_2.asp

The suggested fix is shown below althought this is
untested. The correct error number is recived from
getsockopt(SOL_SOCKET,SO_ERROR) 

def poll(timeout=0.0, map=None):
     if map is None:
         map = socket_map
     if map:
         r = []; w = []; e = []
         for fd, obj in map.items():
             if obj.readable():
                 r.append(fd)
             if obj.writable():
                 w.append(fd)

             if sys.platform == &#039;win32&#039;:
                 if not obj.connected:
                     e.append(fd)
         if [] == r == w == e:
             time.sleep(timeout)
         else:
             try:
                 r, w, e = select.select(r, w, e, timeout)
             except select.error, err:
                 if err[0] != EINTR:
                     raise
                 else:
                     return

         if sys.platform == &#039;win32&#039;:
             for fd in e:
                 obj = map.get(fd)
                 if obj is None:
                     continue
                 errno =
fs.getsockopt(socket.SOL_SOCKET, socket.SO_ERROR)
                 raise
socket.error,(errno,socketerrorTab[error])

         for fd in r:
             obj = map.get(fd)
             if obj is None:
                 continue
             read(obj)

         for fd in w:
             obj = map.get(fd)
             if obj is None:
                 continue
             write(obj)


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

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 11:23

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

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

Comment By: John J Smith (johnjsmith)
Date: 2003-07-29 16:49

Message:
Logged In: YES 
user_id=830565

I was bitten by the same problem.  My workaround (in a
Tkinter application) is given below.

Would it make sense to modify poll() to simply add the union
of r and w to e, and call handle_error() for any fd in e?

Workaround:

        try:
            self.connect(send_addr)
        except socket.error:
            self.handle_error()
        if sys.platform == 'win32':
            # Win98 select() doesn't seem to report errors for a
            # non-blocking connect().
            self.__connected = 0
            self.__frame.after(2000, self.__win_connect_poll)

...

    if sys.platform == 'win32':
        def __win_connect_poll (self):
            if self.__connected:
                return
            e = self.socket.getsockopt(socket.SOL_SOCKET,
                                       socket.SO_ERROR)
            if e in (0, errno.EINPROGRESS, 
errno.WSAEINPROGRESS):
                self.__frame.after(2000, self.__win_connect_poll)
            else:
                try:
                    str = socket.errorTab[e]
                except KeyError:
                    str = os.strerror(e)
                try:
                    raise socket.error(e, str)
                except socket.error:
                    self.handle_error()


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

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

From noreply at sourceforge.net  Thu Mar  4 03:24:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 09:25:21 2004
Subject: [ python-Bugs-658749 ] asyncore connect() and winsock errors
Message-ID: <E1Ayo9Q-0003us-00@sc8-sf-web4.sourceforge.net>

Bugs item #658749, was opened at 2002-12-26 21:25
Message generated for change (Comment added) made by klimkin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore connect() and winsock errors

Initial Comment:
asyncore&#039;s connect() method should interpret the
winsock errors; these are different from Unix (and
different between the Win98 family and the Win2k family).

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

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 11:24

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

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

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

From noreply at sourceforge.net  Thu Mar  4 03:24:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 09:25:23 2004
Subject: [ python-Bugs-654766 ] asyncore.py and "handle_expt"
Message-ID: <E1Ayo9f-0006v2-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jes?s Cea Avi?n (jcea)
Assigned to: Nobody/Anonymous (nobody)
Summary: asyncore.py and "handle_expt"

Initial Comment:
Python 2.2.2 here.

Asyncore.py doesn&#039;t invoke "handle_expt" ever
("handle_expt" is documented in docs). Managing OOB
data is imprescindible to handle "connection refused"
errors in Windows, for example.

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

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 11:24

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

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

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

From noreply at sourceforge.net  Thu Mar  4 03:59:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 09:29:47 2004
Subject: [ python-Bugs-909295 ] segmentation fault
Message-ID: <E1Ayoh8-0001Ra-00@sc8-sf-web2.sourceforge.net>

Bugs item #909295, was opened at 2004-03-03 20:53
Message generated for change (Comment added) made by zgoda
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909295&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chuck Mason (cemason)
Assigned to: Nobody/Anonymous (nobody)
Summary: segmentation fault

Initial Comment:

$ python
Python 2.3.1 (#1, Sep 23 2003, 10:07:41)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def func(*a): print a
...
>>> func((1, 2, 3)
... )Segmentation fault


--------------------------
Not sure what other information you need, but I tested
it on several machines with the same version and it
seems to be hardware/other library independant.



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

Comment By: Jarek Zgoda (zgoda)
Date: 2004-03-04 09:59

Message:
Logged In: YES 
user_id=92222

No such weirdness on W2KSp4 with Python 2.3.2

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-04 05:05

Message:
Logged In: YES 
user_id=80475

On WinMe, I cannot reproduce this on Py2.2.3,  Py2.3.3, or
Py2.4a0.

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

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

From noreply at sourceforge.net  Thu Mar  4 09:59:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar  4 10:00:02 2004
Subject: [ python-Bugs-909295 ] segmentation fault
Message-ID: <E1AyuKJ-00084v-00@sc8-sf-web4.sourceforge.net>

Bugs item #909295, was opened at 2004-03-03 14:53
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909295&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Chuck Mason (cemason)
Assigned to: Nobody/Anonymous (nobody)
Summary: segmentation fault

Initial Comment:

$ python
Python 2.3.1 (#1, Sep 23 2003, 10:07:41)
[GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def func(*a): print a
...
>>> func((1, 2, 3)
... )Segmentation fault


--------------------------
Not sure what other information you need, but I tested
it on several machines with the same version and it
seems to be hardware/other library independant.



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

>Comment By: Tim Peters (tim_one)
Date: 2004-03-04 09:59

Message:
Logged In: YES 
user_id=31435

Get into a debugger and show the top dozen functions on the 
call stack when the segfault occurs.  Segfaults in an 
interactive shell unique to Unixish systems usually get pinned 
on GNU readline in the end.

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

Comment By: Jarek Zgoda (zgoda)
Date: 2004-03-04 03:59

Message:
Logged In: YES 
user_id=92222

No such weirdness on W2KSp4 with Python 2.3.2

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-03 23:05

Message:
Logged In: YES 
user_id=80475

On WinMe, I cannot reproduce this on Py2.2.3,  Py2.3.3, or
Py2.4a0.

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

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

From noreply at sourceforge.net  Fri Mar  5 13:42:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  5 13:43:10 2004
Subject: [ python-Bugs-907575 ] "\textttNone" in Index
Message-ID: <E1AzKHi-0004x1-00@sc8-sf-web4.sourceforge.net>

Bugs item #907575, was opened at 2004-03-01 09:22
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=907575&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: "\textttNone" in Index

Initial Comment:
In the index of the Python 2.3.3 documentation (as 
started from IDLE on Windows XP), the references to

None
None object
NotImplemented
NotImplemented object

are shown as

\textttNone
\textttNone object
\textttNotImplemented
\textttNotImplemented object

and are therefore at the wrong place.

This is probably due to a typo.


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

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-03-05 13:42

Message:
Logged In: YES 
user_id=11375

Marking as closed.

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

Comment By: George Yoshida (quiver)
Date: 2004-03-02 19:34

Message:
Logged In: YES 
user_id=671362

This is a duplicate of bug #820344 and has been fixed.

See :
  http://www.python.org/sf/820344
commit log:
  http://mail.python.org/pipermail/python-checkins/2004-
January/039399.html

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

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

From noreply at sourceforge.net  Fri Mar  5 13:43:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  5 13:43:41 2004
Subject: [ python-Bugs-907575 ] "\textttNone" in Index
Message-ID: <E1AzKHt-0001Dd-00@sc8-sf-web3.sourceforge.net>

Bugs item #907575, was opened at 2004-03-01 09:22
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=907575&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Closed
Resolution: None
Priority: 5
Submitted By: Heiko Selber (drhok)
Assigned to: Nobody/Anonymous (nobody)
Summary: "\textttNone" in Index

Initial Comment:
In the index of the Python 2.3.3 documentation (as 
started from IDLE on Windows XP), the references to

None
None object
NotImplemented
NotImplemented object

are shown as

\textttNone
\textttNone object
\textttNotImplemented
\textttNotImplemented object

and are therefore at the wrong place.

This is probably due to a typo.


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

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-03-05 13:43

Message:
Logged In: YES 
user_id=11375

Marking as closed.

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

Comment By: A.M. Kuchling (akuchling)
Date: 2004-03-05 13:42

Message:
Logged In: YES 
user_id=11375

Marking as closed.

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

Comment By: George Yoshida (quiver)
Date: 2004-03-02 19:34

Message:
Logged In: YES 
user_id=671362

This is a duplicate of bug #820344 and has been fixed.

See :
  http://www.python.org/sf/820344
commit log:
  http://mail.python.org/pipermail/python-checkins/2004-
January/039399.html

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

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

From noreply at sourceforge.net  Fri Mar  5 14:52:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar  5 14:52:18 2004
Subject: [ python-Bugs-909230 ] bug in idna-encoding-module
Message-ID: <E1AzLMh-0002q2-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rumpeltux (rumpeltux)
>Assigned to: Martin v. L?wis (loewis)
Summary: bug in idna-encoding-module

Initial Comment:
in /usr/lib/python2.3/encodings/idna.py, line 175 it goes:
lables = input.split(&#039;.&#039;)
which causes the interpreter to stop executing the
program, but by changing it to
labels = dots.split(input)
everything&#039;s fine ;)

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-05 14:52

Message:
Logged In: YES 
user_id=33168

Martin, it looks like line 174: unicode(input, "ascii")
should be input = unicode(input, "ascii").
I'm not sure what's supposed to happenning here, but it
looks like the if/else code block may be able to be
rewritten as:

if not isinstance(input, unicode):
    input = unicode(input, "ascii")
labels = dots.split(input)


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

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

From noreply at sourceforge.net  Sat Mar  6 07:35:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  6 07:35:19 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1Azb1G-0000bt-00@sc8-sf-web2.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 18:00
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Guido van Rossum (gvanrossum)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


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

>Comment By: Phillip J. Eby (pje)
Date: 2004-03-06 12:35

Message:
Logged In: YES 
user_id=56214

Here's a patch against the CVS head to add a test for the
problem, and fix it.  Please backport to the 2.3 branch as
well.  Thanks!

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-25 19:09

Message:
Logged In: YES 
user_id=6656

I don't think you'll find any difference between the trunk
and release23-maint in this area, so it doesn't make much
difference.

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

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 19:06

Message:
Logged In: YES 
user_id=56214

super().descriptor example:

class Base(object):
    aProp = property(lambda self: "foo")

class Sub(Base):
    def test(klass):
        print super(Sub,klass).aProp
    test = classmethod(test)

Sub.test()

This prints "foo", when it should print "<property object at
0x4024f84c>" instead.

To be precise, the issue is that accessing any descriptor
that behaves differently when retrieved on the class vs. the
instance, will behave incorrectly when accessed via super()
from a classmethod in a subclass.  Classmethods themselves
work correctly because they behave the same way no matter
how you retrieve them.

At present I think the patch should simply change the
descr_get call in super_getattro so that it checks whether
su->obj==su->obj_type, and if so, pass in NULL instead of
su->obj as the second argument to descr_get.

Should I create this patch against the 2.3 maintenance
branch, or against the head?  I'd like to make sure it gets
into the next 2.3.x bugfix release.  (I didn't realize this
bug was still open until I stumbled across it the other day,
and I'm not expecting to upgrade to 2.3 production use for a
few months yet.  I've been using a pure-Python
reimplementation of super() as a workaround.)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 15:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

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

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 07:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

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

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

From noreply at sourceforge.net  Sat Mar  6 11:03:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  6 11:03:11 2004
Subject: [ python-Bugs-910986 ] copy.copy fails for array.array
Message-ID: <E1AzeGY-0001rT-00@sc8-sf-web2.sourceforge.net>

Bugs item #910986, was opened at 2004-03-06 11:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=910986&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Glenn Parker (redandgray)
Assigned to: Nobody/Anonymous (nobody)
Summary: copy.copy fails for array.array

Initial Comment:
Python version 2.3.3 under WindowsXP Home Edition

The standard library "copy" does not work with the
standard library "array".

import copy
import array
x = array.array(&#039;c&#039;, &#039;abcdef&#039;)
y = copy.copy(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/copy.py", line 95, in copy
    return _reconstruct(x, rv, 0)
  File "/usr/lib/python2.3/copy.py", line 338, in
_reconstruct
    y = callable(*args)
  File "/usr/lib/python2.3/copy_reg.py", line 92, in
__newobj__
    return cls.__new__(cls, *args)
TypeError: array() takes at least 1 argument (0 given)

The same thing happens for copy.deepcopy.

Judging from the TypeError details, it appears that
copy.copy assumes a new object of the same type as its
input argument can be created with no arguments, but
array.array requires at least one argument (describing
the type of items in the array).

array.array should have a custom method added to make
it work smoothly with copy.copy.

Documentation for copy.copy should be clearer about the
requirements on the type of its input argument.


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

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

From noreply at sourceforge.net  Sat Mar  6 15:41:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar  6 15:41:58 2004
Subject: [ python-Bugs-911080 ] string str.split() behaviour inconsistency
Message-ID: <E1AzicM-0006uN-00@sc8-sf-web4.sourceforge.net>

Bugs item #911080, was opened at 2004-03-06 20:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=911080&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (peteshinners)
Assigned to: Nobody/Anonymous (nobody)
Summary: string str.split() behaviour inconsistency

Initial Comment:
The str.split() method behaves differently depending on
if it uses the default (no arguments) separator, or if
you provide your own. There is no way to reproduce the
functionality of the default separator if you supply
your own.

>>> s = "a b  c"
>>> s.split()
[&#039;a&#039;, &#039;b&#039;, &#039;c&#039;]
>>> s.split(" ")
[&#039;a&#039;, &#039;b&#039;, &#039;&#039;, &#039;c&#039;]

The default split uses a different algorithm, where it
combines multiple separators into a single separator.
Providing a custom separator makes split separate each
individual separator.

Obviously there are good reasons for forcing a separate
entry between each separator. With simple comma or
colon separated records, you want to know if an entry
is blank.

The problem is there is not a way to reproduce the
functionality of the default behavior. This alternate
behavior is also not documented, so it becomes
confusing why split behaves different once you want
your own separators.

Fixing could be a problem. Changing the actual split()
method would break many programs. But adding an
different split is a potentially nice solution.

The other option would be to "re-use" the current
splitfields() function and have it work like the
current split. And change the split() to behave like it
does with no default. This would unfortunately still
"break stuff".

The easiest fix may just be documentation and letting
people know of this difference.

I&#039;ve been helping some newbies through Python. When
this came up I was a little surprised and we were
forced to learn it was just a little "magic and scary".


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

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

From noreply at sourceforge.net  Sun Mar  7 02:09:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  7 02:09:44 2004
Subject: [ python-Bugs-910986 ] copy.copy fails for array.array
Message-ID: <E1AzsPr-0004zV-00@sc8-sf-web1.sourceforge.net>

Bugs item #910986, was opened at 2004-03-06 11:03
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=910986&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Glenn Parker (redandgray)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: copy.copy fails for array.array

Initial Comment:
Python version 2.3.3 under WindowsXP Home Edition

The standard library "copy" does not work with the
standard library "array".

import copy
import array
x = array.array(&#039;c&#039;, &#039;abcdef&#039;)
y = copy.copy(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/copy.py", line 95, in copy
    return _reconstruct(x, rv, 0)
  File "/usr/lib/python2.3/copy.py", line 338, in
_reconstruct
    y = callable(*args)
  File "/usr/lib/python2.3/copy_reg.py", line 92, in
__newobj__
    return cls.__new__(cls, *args)
TypeError: array() takes at least 1 argument (0 given)

The same thing happens for copy.deepcopy.

Judging from the TypeError details, it appears that
copy.copy assumes a new object of the same type as its
input argument can be created with no arguments, but
array.array requires at least one argument (describing
the type of items in the array).

array.array should have a custom method added to make
it work smoothly with copy.copy.

Documentation for copy.copy should be clearer about the
requirements on the type of its input argument.


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

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

From noreply at sourceforge.net  Sun Mar  7 02:23:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  7 02:23:45 2004
Subject: [ python-Bugs-911080 ] string str.split() behaviour inconsistency
Message-ID: <E1AzsdP-00085S-00@sc8-sf-web3.sourceforge.net>

Bugs item #911080, was opened at 2004-03-06 15:41
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=911080&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Pete Shinners (peteshinners)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: string str.split() behaviour inconsistency

Initial Comment:
The str.split() method behaves differently depending on
if it uses the default (no arguments) separator, or if
you provide your own. There is no way to reproduce the
functionality of the default separator if you supply
your own.

>>> s = "a b  c"
>>> s.split()
[&#039;a&#039;, &#039;b&#039;, &#039;c&#039;]
>>> s.split(" ")
[&#039;a&#039;, &#039;b&#039;, &#039;&#039;, &#039;c&#039;]

The default split uses a different algorithm, where it
combines multiple separators into a single separator.
Providing a custom separator makes split separate each
individual separator.

Obviously there are good reasons for forcing a separate
entry between each separator. With simple comma or
colon separated records, you want to know if an entry
is blank.

The problem is there is not a way to reproduce the
functionality of the default behavior. This alternate
behavior is also not documented, so it becomes
confusing why split behaves different once you want
your own separators.

Fixing could be a problem. Changing the actual split()
method would break many programs. But adding an
different split is a potentially nice solution.

The other option would be to "re-use" the current
splitfields() function and have it work like the
current split. And change the split() to behave like it
does with no default. This would unfortunately still
"break stuff".

The easiest fix may just be documentation and letting
people know of this difference.

I&#039;ve been helping some newbies through Python. When
this came up I was a little surprised and we were
forced to learn it was just a little "magic and scary".


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

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

From noreply at sourceforge.net  Sun Mar  7 06:00:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  7 06:00:12 2004
Subject: [ python-Bugs-911080 ] string str.split() behaviour inconsistency
Message-ID: <E1Azw0p-0005b5-00@sc8-sf-web4.sourceforge.net>

Bugs item #911080, was opened at 2004-03-06 21:41
Message generated for change (Comment added) made by sjoerd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=911080&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Pete Shinners (peteshinners)
Assigned to: Raymond Hettinger (rhettinger)
Summary: string str.split() behaviour inconsistency

Initial Comment:
The str.split() method behaves differently depending on
if it uses the default (no arguments) separator, or if
you provide your own. There is no way to reproduce the
functionality of the default separator if you supply
your own.

>>> s = "a b  c"
>>> s.split()
[&#039;a&#039;, &#039;b&#039;, &#039;c&#039;]
>>> s.split(" ")
[&#039;a&#039;, &#039;b&#039;, &#039;&#039;, &#039;c&#039;]

The default split uses a different algorithm, where it
combines multiple separators into a single separator.
Providing a custom separator makes split separate each
individual separator.

Obviously there are good reasons for forcing a separate
entry between each separator. With simple comma or
colon separated records, you want to know if an entry
is blank.

The problem is there is not a way to reproduce the
functionality of the default behavior. This alternate
behavior is also not documented, so it becomes
confusing why split behaves different once you want
your own separators.

Fixing could be a problem. Changing the actual split()
method would break many programs. But adding an
different split is a potentially nice solution.

The other option would be to "re-use" the current
splitfields() function and have it work like the
current split. And change the split() to behave like it
does with no default. This would unfortunately still
"break stuff".

The easiest fix may just be documentation and letting
people know of this difference.

I&#039;ve been helping some newbies through Python. When
this came up I was a little surprised and we were
forced to learn it was just a little "magic and scary".


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

>Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-03-07 12:00

Message:
Logged In: YES 
user_id=43607

Use s.split(None) to get the same behavior as without arguments.
This is documented behavior, as far as I know.  If the
documentation isn't good enough, submit a bug report
specifically for that.

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

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

From noreply at sourceforge.net  Sun Mar  7 18:26:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  7 18:27:04 2004
Subject: [ python-Bugs-897817 ] test_strptime failures on FC2-test
Message-ID: <E1B07fd-0005vv-00@sc8-sf-web4.sourceforge.net>

Bugs item #897817, was opened at 2004-02-15 21:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897817&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Anthony Baxter (anthonybaxter)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: test_strptime failures on FC2-test

Initial Comment:
I&#039;m seeing test_strptime failures on this box, running
a version of Fedora Core that&#039;s between 1 and the new
test release.

test test_strptime failed -- Traceback (most recent
call last): 
File "Lib/test/test_strptime.py", line 258, in
test_timezone
    self.failUnlessEqual(strp_output.tm_isdst, 0)
AssertionError: -1 != 0

Note that the following line (which tests GMT) also
fails with a -1.

The underlying failure:
>>> import _strptime
>>> strp_output = _strptime.strptime("UTC", "%Z")
>>> strp_output.tm_isdst
-1
>>> strp_output = _strptime.strptime("GMT", "%Z")
>>> strp_output.tm_isdst
-1


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-07 15:26

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.31 .  Basically tweaked the test that checks if 
time.tzname[0] == time.tzname[1] (which is bad since then you can't 
tell when DST is in effect or not) to take into acct. if time.tzname[1] (the 
DST timezone) is set to UTC or GMT.  Since there is no adjustment, then 
just set let be set to 0 through the normal algorithm.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-23 20:26

Message:
Logged In: YES 
user_id=357491

A possible cause for this, Anthony, is having the timezone set to ("UTC", 
"GMT") and time.daylight to a 1.  This would lead to not passing the test 
since there is an explicit test in the strptime code for when duplicate 
non-DST and DST timezones are the same and this would do it since UTC 
and GMT are injected into the non-DST timezone list for comparisons.  
The default is -1 since you can't tell the proper value if both non-DST and 
DST are the same.  And UTC and GMT should not be considered DST 
timezones obviously.

Anyway, I hope you don't find anything wrong and it was just a weird 
glitch in the date settings.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-02-23 19:05

Message:
Logged In: YES 
user_id=29957

Very very strange. I rebuilt python, and the problem has
gone away. I will assign this to myself and try and
reproduce it. 

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 13:39

Message:
Logged In: YES 
user_id=357491

Anthony, can you let me know what the following commands spit out?::

import time; import _strptime
time.tzname
time.daylight
_strptime.LocaleTime().timezone
_strptime.TimeRE()['Z']

That should be enough info for me to debug this.

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

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

From noreply at sourceforge.net  Sun Mar  7 22:09:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar  7 22:09:07 2004
Subject: [ python-Bugs-905737 ] BuildApplet needs to get more
	BuildApplication features
Message-ID: <E1B0B8Y-0007mg-00@sc8-sf-web3.sourceforge.net>

Bugs item #905737, was opened at 2004-02-27 05:08
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905737&group_id=5470

Category: Macintosh
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: BuildApplet needs to get more BuildApplication features

Initial Comment:
BuildApplet needs to become a more complete interface to 
bundlebuilder, thereby also getting the function of the old 
BuildApplication, and various intermediate steps.

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

Comment By: Bob Ippolito (etrepum)
Date: 2004-03-07 22:09

Message:
Logged In: YES 
user_id=139309

Is there a summary of BuildApplication features anywhere?

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

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

From noreply at sourceforge.net  Mon Mar  8 11:53:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  8 11:53:43 2004
Subject: [ python-Bugs-728330 ] Don't define _SGAPI on IRIX
Message-ID: <E1B0O0S-0003qx-00@sc8-sf-web2.sourceforge.net>

Bugs item #728330, was opened at 2003-04-27 11:21
Message generated for change (Comment added) made by mhertha
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=728330&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: Later
Priority: 5
Submitted By: Ralf W. Grosse-Kunstleve (rwgk)
Assigned to: Neal Norwitz (nnorwitz)
Summary: Don't define _SGAPI on IRIX

Initial Comment:
Python release:
  2.3b1
Platform:
  IRIX 6.5
  MIPSpro Compilers: Version 7.3.1.2m
Commands used:
  ./configure --prefix=/usr/local_cci/Python-2.3b1t
  make

The socket module fails to compile. The output from 
the compiler is attached.


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

Comment By: Maik Hertha (mhertha)
Date: 2004-03-08 17:53

Message:
Logged In: YES 
user_id=768223

I got Python 2.3.3 compiled with MipsPro Compilers: Version
7.3.1.3m. The following changes were made to satisfy all needs.
Line 206 in Modules/socketmodule.c
#define _SGIAPI 1

NEW: #undef _XOPEN_SOURCE
NEW: #define HAVE_GETADDRINFO 1
NEW: #define HAVE_GETNAMEINFO 1

#define HAVE_INET_PTON
NEW: #include <sys/types.h>
NEW: #include <sys/socket.h>
NEW: #include <netinet/in.h>
#include <netdb.h>

Line 269:
/* #include "addrinfo.h" */

In addition to this I extend the CFLAGS with -D_BSD_TYPES to
satisfy the u_short and friends definition.
--maik./

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

Comment By: Bill Baxter (billbaxter26)
Date: 2004-03-03 17:20

Message:
Logged In: YES 
user_id=892601

Got it down to one error:
% > ./python Lib/test/test_socket.py
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 6, in ?
    import socket
  File "/usr/local/spider/lib/python2.3/socket.py", line 44,
in ?
    import _socket
ImportError: 210454:./python: rld: Fatal Error: unresolvable
symbol in
/usr/local/spider/lib/python2.3/lib-dynload/_socketmodule.so:
_xpg5_accept

xpg5_accept does appear in any library on our SGI's that are
only 1-2 years old. It does appear in libc in very recent
revisions of Irix (> 6.5.19?)

Does anyone know how to get Python 2.3 to avoid the use of
xpg5_accept?

Thanks


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

Comment By: Bill Baxter (billbaxter26)
Date: 2004-01-12 19:59

Message:
Logged In: YES 
user_id=892601

Has anyone encountered problems with different versions of
IRIX 6.5? I finally got sockets to work in Python2.3.3, but
only on the most up-to-date version of IRIX (uname -v =
01100304). On any other machine with a lower version
(archetecture doesn't seem to matter), I get messages which
all seem to be related to sockets:

152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_vsnprintf
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recv
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_connect
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_bind
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_sendto
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_setsockopt
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_accept
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_recvfrom
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_socket
152272:python2.3: rld: Error: unresolvable symbol in
python2.3: _xpg5_getsockname

Upgrading all of our SGIs is not something I have control
over.


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

Comment By: Maik Hertha (mhertha)
Date: 2003-12-22 19:52

Message:
Logged In: YES 
user_id=768223

Sorry if there is something unclear.
Redefine means: Set a value which is required to satisfy
ifdef-statements in the header files. As you see in the
definitions, given in the comment, the value for _NO_XOPEN4
is set as a result of some dependencies automatically
defined. A redefinition of _SGIAPI in the socketmodule.c is
not sufficient alone. Therefore to satisfy all requirements
in the header files, you should set the values for
_NO_XOPEN4 and _NO_XOPEN5 also manually.
Howto do in socketmodule.c?
...
#define _SGIAPI 1
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
...
If you are familiar with regular expressions, then you will
know that _NO_XOPEN[45] is a shorthand for _NO_XOPEN4,
_NO_XOPEN5.

Sorry if there was something wrong in my comment.

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

Comment By: Bill Baxter (billbaxter26)
Date: 2003-12-22 16:49

Message:
Logged In: YES 
user_id=892601

Can someone please clarify mherta's comment from 2003-12-16?

How should we "redefine _NO_XOPEN[45] in the socketmodule.c
at the same position like the _SGIAPI redefinition"?

Should those lines of code be added to socketmodule.c, or
are they the source of the problem?

Is _NO_XOPEN[45] shorthand for _NO_XOPEN[4] and _NO_XOPEN[5]
or are they all different?

Thanks.

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

Comment By: Maik Hertha (mhertha)
Date: 2003-12-16 18:27

Message:
Logged In: YES 
user_id=768223

I've tested the latest Python 2.3.3c1 to compile. The
problem reported is still present. To avoid the error
messages, about the incompatible types of several
netdb-functions (like inet_pton), you should redefine
_NO_XOPEN[45] in the socketmodule.c at the same position
like the _SGIAPI redefinition. If there are error messages
that types like u_short and u_char are not defined, please
add -D_BSD_TYPES in the Makefile (BASECFLAGS is okay).
If anybody don't need a executable compiled with MipsPro,
gcc from the freeware.sgi.com could be a choice.
The problem for this seems in /usr/include/standards.h:
#define _NO_XOPEN4	(!defined(_XOPEN_SOURCE) || 				(defined(_XOPEN_SOURCE) && 				(_XOPEN_SOURCE+0 >= 500)))
#define _NO_XOPEN5	(!defined(_XOPEN_SOURCE) || 				(defined(_XOPEN_SOURCE) && 				(_XOPEN_SOURCE+0 < 500)))
As the first option is true (_XOPEN_SOURCE is set to 600 in
pyconfig.h) the second option will be false. The constant
#define NI_NUMERICHOST  0x00000002  /* return numeric form
of hostname */
is enveloped in a clause #ifdef _NO_XOPEN4 && _NO_XOPEN5
(/usr/include/netdb.h) which is always false.
In the manual pages there is a example which uses the
constant NI_NUMERICHOST and compiles without error message.
I'm not sure to cut off the file pyconfig.h from compiling
the socketmodule.c?

Any comments?

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

Comment By: Hans Nowak (zephyrfalcon)
Date: 2003-10-31 04:04

Message:
Logged In: YES 
user_id=173607

My $0.02...

Yesterday I successfully compiled Python 2.3.2, with socket
module. I'm using an O2 running IRIX 6.5.11f.

I didn't encounter any of the problems described before, and
had no problems with _SGIAPI or anything. The reason it
didn't compile was that u_long and u_char were not defined
in some places; /usr/include/netinet/tcp.h to be precise,
and a Python file (getaddrinfo.c).

I'm using gcc 3.3 (the one downloaded from freeware.sgi.com).

If anyone is interested, drop me a mail at hans at
zephyrfalcon.org and I'll put the binary online somewhere.

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

Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-24 21:59

Message:
Logged In: YES 
user_id=892601

Here's the output from 'gmake', using MIPSpro Compiler 7.30
on IRIX 6.5

Sorry, I don't know how to attach something using the "Add a
Comment" box. Is there another way to post?

The patch at
www.python.org/2.3.2/patches/sgi-socketmodule.patch was
edited into socketmodule.c :
#include <netdb.h>
#endif

/* GCC 3.2 on Irix 6.5 fails to define this variable at all.
Based on 
   the above code, I'd say that the SGI headers are just
horked. */
#if defined(__sgi) && !defined(INET_ADDRSTRLEN)
#define INET_ADDRSTRLEN 16
#endif

/* Generic includes */
#include <sys/types.h>
#include <signal.h>


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

cc -OPT:Olimit=0 -DNDEBUG  -n32 -O -I. -I./Include 
-DPy_BUILD_CORE  -c ./Modules/socketmodule.c -o
Modules/socketmodule.o
cc-1047 cc: WARNING File = ./Modules/socketmodule.c, Line =
195
  Macro "_SGIAPI" (declared at line 210 of
"/usr/include/standards.h") has an
          incompatible redefinition.

  #define _SGIAPI 1
          ^

cc-1020 cc: ERROR File = /usr/include/netdb.h, Line = 198
  The identifier "socklen_t" is undefined.

  extern int iruserok_sa(const void *, socklen_t, int, const
char *,
                                       ^

cc-1047 cc: WARNING File = ./Modules/addrinfo.h, Line = 145
  Macro "_SS_ALIGNSIZE" (declared at line 246 of
"/usr/include/sys/socket.h")
          has an incompatible redefinition.

  #define _SS_ALIGNSIZE (sizeof(PY_LONG_LONG))
          ^

cc-1020 cc: ERROR File = ./Modules/socketmodule.c, Line =
822
  The identifier "NI_NUMERICHOST" is undefined.

                NI_NUMERICHOST);
                ^

cc-1515 cc: ERROR File = ./Modules/socketmodule.c, Line =
3054
  A value of type "int" cannot be assigned to an entity of
type "const char *".

        retval = inet_ntop(af, packed, ip, sizeof(ip));
               ^

3 errors detected in the compilation of
"./Modules/socketmodule.c".
gmake: *** [Modules/socketmodule.o] Error 2


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

Comment By: Michael Hudson (mwh)
Date: 2003-10-23 12:25

Message:
Logged In: YES 
user_id=6656

Just to be clear,  please "attach" the build rather than
pasting it inline.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-10-23 04:19

Message:
Logged In: YES 
user_id=29957

Did you try 2.3.2 with the patch from the 2.3.2 build bugs page?

If it failed, please post the build log of the failing bit
to this bug.
 

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

Comment By: Bill Baxter (billbaxter26)
Date: 2003-10-22 20:26

Message:
Logged In: YES 
user_id=892601

Has there been any progress since August on getting
Python-2.3 to compile on IRIX 6.5? I really need to have
sockets working to use python.

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

Comment By: Maik Hertha (mhertha)
Date: 2003-08-14 13:37

Message:
Logged In: YES 
user_id=768223

I have the same problem on IRIX 6.5.19m and MIPSpro 7.3.1.3m
on a FUEL 600Mhz.
The situation seems a little bit strange on this system. But
I have luck and get it compiled. As the current
implementation is not clean, my resolution also. Which
should be changed to get it work.
The manpage for gethostbyaddr_r says:
#include <sys/types>
#include <sys/socket>
#include <netinet/in.h>
#include <netdb.h>
So I included this in the __sgi-clause in socketmodule.c.
Looking in the header-files shows, that some variables are
defined if 
#define _NO_XOPEN4 1
#define _NO_XOPEN5 1
are set, before the includes. This defines some more
variables, so that pyconfig.h should be changed.
#define HAVE_ADDRINFO 1
#define HAVE_SOCKADDR_STORAGE 1
Sure there are warnings about the redefinition of the
_(SGIAPI|NO_XOPEN4|NO_XOPEN5) but it compiles and the tests
don't fail. Also my applications run without exception or
coredump on FUEL, Octane, Octane 2.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-08-01 14:10

Message:
Logged In: YES 
user_id=33168

Ralf, I will try to work on this, but it won't be for a week
or two probably.  Can you tell me which machines (by name)
work and doesn't work.  The only IRIX machine I seem to know
about it rattler.

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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-08-01 09:34

Message:
Logged In: YES 
user_id=71407

For the records:
The Python2.3 (final) socket module still does not 
compile under IRIX 6.5.20. It only compiles under 6.5.10.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 20:07

Message:
Logged In: YES 
user_id=31392

I applied a slight variant of Neal's patch and that seemed
to fix things.  It still seems wrong that we define _SGIAPI,
but that will have to wait for 2.3.1.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 15:54

Message:
Logged In: YES 
user_id=31392

I learned a little about inet_ntop() in the last few
minutes.  It looks like the size_t argument is an older
spelling, and the current POSIX says it should be socklen_t.
 Regardless, it looks like we're using the new definition
when IRIX is actually providing the older definition.

Neal attached a patch that looks like it should clean up the
problem.  Have you tried it?  I think a better solution
would be to teach configure how to find inet_ntop() via
netdb.h, but that's probably too hard to get done in the new
couple of hours.


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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-07-17 15:42

Message:
Logged In: YES 
user_id=31392

There seem to be two causes of worry.  The actual compiler
error in your build log and the use of _SGIAPI that
Casavanti warns again.

It looks like the compiler problems is because our
inet_ntop() prototype is wrong.  That is Python says the
last argument is a socklen_t, but IRIX and Linux man pages
both say size_t.  Perhaps size_t and socklen_t are different
sizes on IRIX, but not on Linux.  What happens if you change
it to size_t?

The problematic code would appear to be these lines from
socketmodule.c:

#if defined(__sgi)&&_COMPILER_VERSION>700 && !_SGIAPI
/* make sure that the reentrant (gethostbyaddr_r etc)
   functions are declared correctly if compiling with
   MIPSPro 7.x in ANSI C mode (default) */
#define _SGIAPI 1
#include "netdb.h"
#endif

It's the only use the _SGIAPI symbol that Casavant says we
shouldn't use.  What happens if you remove the use _SGIAPI,
i.e. just make it

#if defined(__sgi) && _COMPILER_VERSION > 700 
/* make sure that the reentrant (gethostbyaddr_r etc)
   functions are declared correctly if compiling with
   MIPSPro 7.x in ANSI C mode (default) */
#include "netdb.h"
#endif


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-17 02:27

Message:
Logged In: YES 
user_id=71407

We have confirmed that the socket module in Python 2.3b1 
and 2.3b2 fails to compile under these versions of IRIX:

6.5.10, MIPSpro 7.3.1.2m
6.5.19, MIPSpro 7.3.1.3m
6.5.20, MIPSpro 7.3.1.3m (latest available, to my knowledge)

If Python 2.3 goes out without a working socket module it 
will be useless for many people in science where IRIX is still 
found quite frequently. Maybe even worse, we will also no 
longer be able to advertise Python as a language that "runs 
everywhere."


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-07-16 00:37

Message:
Logged In: YES 
user_id=71407

Date: Tue, 15 Jul 2003 15:06:25 -0500
From: "Brent Casavant" <bcasavan@sgi.com>
To: "Ralf W. Grosse-Kunstleve" <rwgk@yahoo.com> 
Subject: Re: IRIX & Python 

Ralf,

I read through the sourceforge report.  I don't have a 
sourceforge
account so I didn't add there, but feel free to distribute my
ramblings.

First, they should be very careful about what version of the
operating system they are using.  Real IPv6 support was only
added a few releases ago (6.5.20 I believe, though my 
memory
is hazy).  Some of the functions/macros corresponding to 
IPv6
were introduced prior to that point, but implementation may
not have been complete.  If they have to play tricks with
#define values to get a symbol recongnized it most likely
means that SGI didn't intend for that symbol to be used yet.

I suspect the problems they are seeing are because they are
using some version of IRIX 6.5.x that includes inet_ntoa()
definitions under _SGIAPI, but for which real support was
not yet complete.  The namespace of symbols that begin 
with a
single underscore and a capital letter is reserved for the OS
vendors, and the fact that someone is trying to manually 
insert
a definition of _SGIAPI into the source should be a big red
warning flag.

That said, there is a correct method to deal with the new
capabilities of IRIX 6.5.x over time.  This comes in two
parts.  A better explanation is in /usr/include/optional_sym.h

First, when a new symbol is added to IRIX, the corresponding
header file will always have the following line in it:

	#pragma optional some_new_symbol

The presence of this #pragma will cause the linker to not
complain if the symbol is missing when the executable is
linked.  If SGI neglects to do so it is a bug that should
be reported to us.

The second part is that calls to these "optional" symbols
should be protected by a run-time check to see if the symbol
is actually present.  Just like this:

	#include <optional_sym.h>
	#include <header_file_for_some_new_symbol.h>

	. . .

	if (_MIPS_SYMBOL_PRESENT(some_new_symbol)) {
		/* New function is present, use it */
		qux = some_new_symbol(foo, bar, baz);
	} else {
		/* New function isn't present, do 
something else */
		qux = builtin_some_new_symbol(foo, bar, 
baz);
	}

This ensures that a single executable will be able to function
properly (or at least degrade gracefully) on all version of
IRIX 6.5.x.  In other words you can compile on 6.5.20 and 
run
on 6.5.8, or vice versa.

In particular, this means that compile-time detection of 
features
such as inet_ntoa() is incorrect for IRIX 6.5.x -- these 
decisions
should be made at run-time instead.  If the decision is made 
at
compile time the executable may well not execute on an older
version of IRIX 6.5.x.  Unfortunately GNU configure is not 
equipped
to utilize such advanced binary-compatability mechanisms, 
so there's
no "easy" way to get GNU configure'd software to run across 
all
IRIX 6.5.x releases, short of compiling only on the original
non-upgraded version of IRIX 6.5.

Hope that helps,
Brent Casavant

On Tue, 15 Jul 2003, Ralf W. Grosse-Kunstleve wrote:

> We are developing a Python-based (www.python.org) 
application for
> IRIX. Until now the Python IRIX port was fully supported, 
but the last
> two beta releases of Python (2.3b1 and 2.3b2) make me 
increasingly
> worried because the crucial socket module (TCP/IP 
sockets) fails to
> build. A while ago I've filed a bug report, but the Python 
developers
> appear to be stuck:
>
> 
https://sourceforge.net/tracker/?
func=detail&aid=728330&group_id=5470&atid=105470
>
> Is there a way to bring this to the attention of developers 
at SGI to
> hopefully get some help?
>
> Thank you in advance!
>       Ralf
>

-- 
Brent Casavant      Silicon Graphics, Inc.  Where am I?  And 
what am I
IRIX O.S. Engineer  http://www.sgi.com/     doing in this 
handbasket?
bcasavan@sgi.com    44.8562N 93.1355W 860F      -- 
Unknown


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-06-30 16:21

Message:
Logged In: YES 
user_id=71407

The socket module still fails to compile with Python 
2.3b2, in addition to two other extensions. The full make 
log is attached.


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

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-22 08:47

Message:
Logged In: YES 
user_id=21627

I think it would be best if detect presence of
inet_aton/inet_pton. Is IPv6 support possible on this
system? Then it would be best if that was detected, as well.

If it is not possible to detect aton/pton/ipv6, what is the
problem with not using them?

I'd like to have a look at the relevant headers (in
particular to understand the duplicate definition of
_SGIAPI), indeed.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-05-22 01:35

Message:
Logged In: YES 
user_id=33168

Argh!!!  This is a nightmare.  The attached hack ^h^h^h
patch fixes the problem, but ...

_SGIAPI needs to be defined (~192 in socketmodule.c) in
order to get the prototypes for inet_aton, inet_pton.  But
_SGIAPI can't be defined in the standard header files
because XOPEN_SOURCE is defined.

Martin, do you have any other suggestions?  I don't see how
to do this right within configure.  If you want I can send
you the header file(s).

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

Comment By: alexandre gillet (gillet)
Date: 2003-05-12 19:41

Message:
Logged In: YES 
user_id=150999

I had the same problem compiling socket on Irix.
We did find that on our system ENABLE_IPV6 is not define and
all the error are cause by that.
  
System that do not enable IPV6 are not well supported with
the socketmodule.c code.
We were able to compile socket after making few change in
the code: 
I am not sure if I did it right but it compile.
I will post my patch but I do not see any place to attach my
file
example: See line 2794,2800

+ #ifdef ENABLE_IPV6
        char packed[MAX(sizeof(struct in_addr),
sizeof(struct in6_addr))];
+ #else
+       char packed[sizeof(struct in_addr)];
+ #endif

I am not sure how to post the patch or file.


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

Comment By: Ralf W. Grosse-Kunstleve (rwgk)
Date: 2003-05-05 20:44

Message:
Logged In: YES 
user_id=71407

This is not in my area of expertise, but I've tried a couple of 
(probably stupid) things:

#include <standards.h> in socketmodule.c instead of #define 
_SGIAPI.
This resulted in even more errors.

./configure --disable-ipv6
Same errors as before.

I am lost here. Sorry. But you still have ssh access to 
rattler.lbl.gov if that helps. Accounts for other Python developers 
are a possibility.


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

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-04 14:39

Message:
Logged In: YES 
user_id=21627

Can you analyse these compiler errors in more detail,
please? What, in your opinion, is causing these problems,
and how would you correct them?

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

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

From noreply at sourceforge.net  Mon Mar  8 15:52:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  8 15:52:23 2004
Subject: [ python-Bugs-897872 ] Unknown color name on HP-UX
Message-ID: <E1B0RjP-0001oB-00@sc8-sf-web3.sourceforge.net>

Bugs item #897872, was opened at 2004-02-16 03:37
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=897872&group_id=5470

Category: IDLE
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Richard Townsend (rptownsend)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Unknown color name on HP-UX

Initial Comment:
When I click on a node in the class browser tree widget, 
I get: 

TclError: unknown color name "darkblue".

This is coming from line 253 in TreeWidget.py where the 
background color is hard-coded as "darkblue".

On HP-UX 11.11 there is no entry for "darkblue" in 
rgb.txt.



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

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-03-08 15:52

Message:
Logged In: YES 
user_id=149084

Fixed by Nigel Rowe's Patch 
[ 805830 ] Highlight builtins

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

Comment By: Richard Townsend (rptownsend)
Date: 2004-02-21 11:30

Message:
Logged In: YES 
user_id=200117

One of my collegues tried adding an entry to rgb.txt on
HP-UX and running the rgb util, but he couldn't get X to
recognise the new color.

Looking at the rgb.txt files on HP-UX and Linux (SuSE 8.2)
there  are many differences, not just color names that are
missing, but definitions which are different. 

I wrote a little script to compare the files. I have
attached its output.

However, the definition for 'darkblue' on Linux is identical
to 'blue4' on both Linux and HP-UX (0, 0, 139). 

Perhaps the simplest thing would be for IDLE to use 'blue4' ?



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

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-18 19:48

Message:
Logged In: YES 
user_id=593130

Given the apparent absence of problems on others systems, 
perhaps the absence of a 'darkblue' entry is a bug that should 
be reported to HP.  Do you know anything of the specs for 
rgb.txt?  And can you add such an entry to fix the problem?

If you are sure the absence if legit, what color can be 
depended on if 'darkblue' does not work?

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

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

From noreply at sourceforge.net  Mon Mar  8 17:34:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  8 17:34:53 2004
Subject: [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E1B0TKa-00059y-00@sc8-sf-web3.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Brett Cannon (bcannon)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-08 14:32

Message:
Logged In: YES 
user_id=357491

OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just 
removed the two calls to currentThread in the _Condition class that were 
commented to be for their side-effect).

Just because I don't feel rock-solid on my fix to the point of it not 
changing some obscure semantics that I would be willing to put a gun to 
my head over it I am not going to backport this until I hear from 
someone who had this bug and reports that they have not had any issues 
for a long time.  Otherwise I will just leave the fix in 2.4 only.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-03-02 20:29

Message:
Logged In: YES 
user_id=357491

To force this error I inserted code to set all attributes of the threading 
module to None and then throw and exception.  After commenting out 
the two calls to currentThread in _Condition the thrown exception to 
trigger the problem propogated to the top correctly.

I did have the clean-up function give out since I set *everything* to 
None, but it doesn't look like a normal issue as shown in the exception 
traceback in the OP.  I don't think it is an issue.

So it seems commenting the two calls to currentThread in _Condition 
solves the problem.  But since this is threading code and the comment 
explicitly states it is for the side-effect I am going to try to get a second 
opinion.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-16 20:59

Message:
Logged In: YES 
user_id=357491

Does anyone know how to cause this error in isolation?  I have tried a 
bunch of different ways but cannot cause an exception to be raised at the 
correct point in Threading.__bootstrap() to lead to self.__stop() to be 
called while the interpreter is tearing itself down.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:18

Message:
Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.

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

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 06:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

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

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

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

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

From noreply at sourceforge.net  Mon Mar  8 17:36:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar  8 17:36:36 2004
Subject: [ python-Bugs-754449 ] Exceptions when a thread exits
Message-ID: <E1B0TMJ-0002li-00@sc8-sf-web1.sourceforge.net>

Bugs item #754449, was opened at 2003-06-14 03:32
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=754449&group_id=5470

Category: Threads
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: Matthias Klose (doko)
Assigned to: Brett Cannon (bcannon)
Summary: Exceptions when a thread exits

Initial Comment:
[forwarded from http://bugs.debian.org/195812]

The application mentioned is offlineimap, available
from ftp://ftp.debian.org/dists/unstable/main/source/.

This behavior is new to Python 2.3.

When my application exits, I get a lot of these messages:

Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable
jgoerzen@christoph:~/tree/offlineimap-3.99.18$
./offlineimap.py  -l log -d maildir -a Personal,Excel
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive LocalExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable
Unhandled exception in thread started by <bound method
ExitNotifyThread.__bootstrap of <ExitNotifyThread(Keep
alive RemoteExcel, stopped daemon)>>
Traceback (most recent call last):
  File "/usr/lib/python2.3/threading.py", line 426, in
__bootstrap
    self.__stop()
  File "/usr/lib/python2.3/threading.py", line 435, in
__stop
    self.__block.notifyAll()
  File "/usr/lib/python2.3/threading.py", line 239, in
notifyAll
    self.notify(len(self.__waiters))
  File "/usr/lib/python2.3/threading.py", line 221, in
notify
    currentThread() # for side-effect
TypeError: &#039;NoneType&#039; object is not callable


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-08 14:36

Message:
Logged In: YES 
user_id=357491

OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just 
removed the two calls to currentThread in the _Condition class that were 
commented to be for their side-effect).

Just because I don't feel rock-solid on my fix to the point of it not 
changing some obscure semantics that I would be willing to put a gun to 
my head over it I am not going to backport this until I hear from 
someone who had this bug and reports that they have not had any issues 
for a long time.  Otherwise I will just leave the fix in 2.4 only.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-03-08 14:32

Message:
Logged In: YES 
user_id=357491

OK, this has been fixed in Python 2.4 (rev. 1.41 of Lib/threading.py; just 
removed the two calls to currentThread in the _Condition class that were 
commented to be for their side-effect).

Just because I don't feel rock-solid on my fix to the point of it not 
changing some obscure semantics that I would be willing to put a gun to 
my head over it I am not going to backport this until I hear from 
someone who had this bug and reports that they have not had any issues 
for a long time.  Otherwise I will just leave the fix in 2.4 only.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-03-02 20:29

Message:
Logged In: YES 
user_id=357491

To force this error I inserted code to set all attributes of the threading 
module to None and then throw and exception.  After commenting out 
the two calls to currentThread in _Condition the thrown exception to 
trigger the problem propogated to the top correctly.

I did have the clean-up function give out since I set *everything* to 
None, but it doesn't look like a normal issue as shown in the exception 
traceback in the OP.  I don't think it is an issue.

So it seems commenting the two calls to currentThread in _Condition 
solves the problem.  But since this is threading code and the comment 
explicitly states it is for the side-effect I am going to try to get a second 
opinion.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-16 20:59

Message:
Logged In: YES 
user_id=357491

Does anyone know how to cause this error in isolation?  I have tried a 
bunch of different ways but cannot cause an exception to be raised at the 
correct point in Threading.__bootstrap() to lead to self.__stop() to be 
called while the interpreter is tearing itself down.

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-09 17:18

Message:
Logged In: YES 
user_id=357491

After staring at the code, I am not even sure if the calls for its side-
effect are needed.  If you call currentThread(), it either returns a value 
from _active which is a dict of running Thread instances indexed by 
thread idents, or a new _DummyThread instance that inserts itself into 
_active.  Now the two calls in the _Condition class are purely for this 
possible side-effect.

And yet at no point is anything from _active, through currentThread or 
direct access, even touched by a _Condition method.  The only chance 
this might be an issue is if a _Condition instance uses an RLock instance 
for its locking, which is the default behavior.

But this still makes the side-effect need useless.  RLocks will call 
currentThread on their own and since this is all in the same thread the 
result won't change.  And in this specific case of this bug, the _Condition 
instance is created with a Lock instance since that is what the Thread 
instance uses for constructing the _Condition instance it use, which is just 
thread.allocate_lock() which is obviously not an RLock.

In other words I can't find the point to the side-effect in _Condition.  I 
will try to come up with some testing code that reproduces the error and 
then see if just removing the calls in _Condition remove the error and 
still pass the regression tests.

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

Comment By: John Goerzen (jgoerzen)
Date: 2003-06-16 06:26

Message:
Logged In: YES 
user_id=491567

I can confirm that this behavior is not present in Python 2.2 in 
the same version that I am using to test against Python 2.3. 
 
I will be on vacation for most of this and next week.  I'll try to 
get to the logging script before I leave, but I might not get to it 
until I return. 
 
FYI, you can also obtain OfflineIMAP at 
http://quux.org/devel/offlineimap. 
 
 

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:58

Message:
Logged In: YES 
user_id=357491

OK, following Tim's advice I checked and it seems that Thread 
calls a method while shutting itself down that calls 
Condition.notifyAll which calls currentThread which is a global.  It 
would appear that offlineimap is leaving its threads running, the 
program gets shut down, the threads raise an error while 
shutting down (probably because things are being torn down), 
this triggers the stopping method in Thread, and this raises its 
own exception because of the teardown which is what we are 
seeing as the TypeError.

So the question is whether Condition should store a local 
reference to currentThread or not.  It is not the most pure 
solution since this shutdown issue is not Condition's, but the only 
other solution I can think of is to have Thread keep a reference 
to currentThread, inject it into the current frame's global 
namespace, call Condition.notifyAll, and then remove the 
reference from the frame again.  I vote for the cleaner, less pure 
solution.  =)

Am I insane on this or does it at least sound like this is the 
problem and proper solution?

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 23:19

Message:
Logged In: YES 
user_id=357491

Nuts.  For some reason I thought the OP had said when threads 
were exiting.

I will ask on python-dev for a good explanation of what happens 
when Python is shutting down.

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

Comment By: Tim Peters (tim_one)
Date: 2003-06-15 18:05

Message:
Logged In: YES 
user_id=31435

Note that the OP said "when my application exits".  When 
Python is tearing down the universe, it systematically sets 
module-global bindings to None.  currentThread() is a module 
global.  I can't make more time for this now, so for more info 
talk about it on Python-Dev.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 16:44

Message:
Logged In: YES 
user_id=357491

Well, I'm stumped.  I checked the diff from when 2.2 was initially 
released until now and the only change that seems to be related 
to any of this is that what is returned by currentThread is not 
saved in a variable.  But since the error is the calling of 
currentThread itself and not saving the return value I don't see 
how that would affect anything.

I also went through offlineimap but I didn't see anything there 
that seemed to be setting currentThread to None.  Although 
since several files do ``import *`` so there still is a possibility of 
overwriting currentThread locally.

So, for my owning learning and to help solve this, I have written 
a tracing function that writes to stderr using the logging package 
when it detects that either currentThread or 
threading.currentThread has been set to None, locally or globally 
(I assume the code is not injecting into builtins so I didn't bother 
checking there).  The file is named tracer.py and I have attached 
it to this bug report.  If you can execute 
``sys.settrace(tracer.trace_currentThread)`` before offlinemap 
starts executing and immediately within each thread (it has to be 
called in *every* thread since tracing functions are no inherited 
from the main thread) it should print out a message when 
currentThread becomes None.  If you *really* want to make this 
robust you can also have it check sys.modules['threading'] every 
time as well, but I figure there is not going to be much renaming 
and masking of currentThread.

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

Comment By: Matthias Klose (doko)
Date: 2003-06-15 01:44

Message:
Logged In: YES 
user_id=60903

Please see
http://packages.debian.org/unstable/mail/offlineimap.html

or for the tarball:
http://ftp.debian.org/debian/pool/main/o/offlineimap/offlineimap_3.99.18.tar.gz

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-15 01:19

Message:
Logged In: YES 
user_id=357491

I went to the FTP site and all I found was some huge, 
compressed files (after changing the path to ftp://ftp.debian.org/
debian/dists/sid/main/source); no specific program called 
offlinemap.  If it is in one of those files can you just add the file 
to the bug report?

As for the reported bug, it looks like currentThread is being 
redefined, although how that is happening is beyond me.  I 
checked the 'threading' module and no where is currentThread 
redefined which could lead to None.  Has the app being run been 
changed at all since Python 2.2 was released?

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

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

From noreply at sourceforge.net  Tue Mar  9 07:20:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 07:21:00 2004
Subject: [ python-Bugs-789290 ] Minor FP bug in object.c
Message-ID: <E1B0gEA-0007yB-00@sc8-sf-web2.sourceforge.net>

Bugs item #789290, was opened at 2003-08-15 15:15
Message generated for change (Comment added) made by nmm1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor FP bug in object.c

Initial Comment:
This is closely related to the one I have reported
in floatobject.c (789159).  VERY closely.  It is
shown up by the following test on a machine with
64-bit longs and floating-point trapping turned on
(though it might show up as bogus results even with
no trapping):

print int( 9223372036854775200.0)
print int( 9223372036854775800.0)
print int(-9223372036854776800.0)
print int(-9223372036854777000.0)

958,959c958,959
<       double intpart, fractpart;
<       int expo;
---
>       double intpart, fractpart, z;
>       int expo, i, j;
978c978,989
<               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
---
>               /* Remember that (double)LONG_MAX can
round either way. */
>               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
>                       z = 0.0;
>               else {
>                       z = (intpart >= 0.0 ? intpart :
-intpart);
>                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
>                               x = LONG_MAX;
>                               for (j = 0; j < i; ++j)
x >>= 16;
>                               z -=
ldexp(x&0xffff,16*i);
>                       }
>               }
>               if (z > 0.0) {


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

>Comment By: Nick Maclaren (nmm1)
Date: 2004-03-09 12:20

Message:
Logged In: YES 
user_id=652073

The bug is overflow (i.e. undefined behaviour), and so
the symptoms will vary according to the system.  Under
the conditions I was running, there was no output,
because Python terminated with a SIGFPE.  As I said, it
could as easily show up as erroneous results.

In THIS case, the failure occurs in the input processing,
and the purpose of prefixing it by print and int() is if
you try it on a system where it gives wrong answers.  If
you don't have access to a system where overflow can be
turned on or one that uses unusual arithmetic, you will not
be able to repeat it.  That is why I created a fix.

The reason that I didn't attach is is that attachment was
broken; I don't know why, and have neither the time nor the
inclination to debug a Web interface that I do not manage.
I can trivially send such things by Email, which is far
more reliable.  There doesn't appear to be a mechanism to
try again, so here is a context diff:

*** object.c.org        Wed Feb 19 03:21:21 2003
--- object.c    Fri Aug 15 15:22:50 2003
***************
*** 955,962 ****
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart;
!       int expo;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
--- 955,962 ----
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart, z;
!       int expo, i, j;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
***************
*** 975,981 ****
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))
--- 975,992 ----
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               /* Remember that (double)LONG_MAX can round
either way. */
!               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
!                       z = 0.0;
!               else {
!                       z = (intpart >= 0.0 ? intpart :
-intpart);
!                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
!                               x = LONG_MAX;
!                               for (j = 0; j < i; ++j) x
>>= 16;
!                               z -= ldexp(x&0xffff,16*i);
!                       }
!               }
!               if (z > 0.0) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))


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

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:22

Message:
Logged In: YES 
user_id=31435

Sorry, I can't make for this, so unassigned it.

To help the next person,

1. Please say something about what "the bug" is.  You show 4 
lines printing int(big_integer), but don't show any output.  In 
addition, the patch *appears* to be against _Py_HashDouble
(), but that function isn't involved in int() or in printing.

2. Please generate a context diff for patches, and attach the 
patch to the bug report instead of pasting it into the text 
box.  SourceForge destroys the intended line structure and 
indentation in text boxes, and this non-context diff patch is 
very hard to follow in this mangled form.

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

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

From noreply at sourceforge.net  Tue Mar  9 09:33:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 10:29:04 2004
Subject: [ python-Bugs-912758 ] AskFolder (EasyDialogs) does not work?
Message-ID: <E1B0iIt-0005Xr-00@sc8-sf-web1.sourceforge.net>

Bugs item #912758, was opened at 2004-03-09 09:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912758&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Jack Jansen (jackjansen)
Summary: AskFolder (EasyDialogs) does not work?

Initial Comment:
I previously was using this code:

#fss , ok = macfs.GetDirectory(&#039;Folder to search:&#039;)

Which worked fine on Python v2.3 on MOSX v10.3.

But, I am updating the code to use:

test = EasyDialogs.AskFolder ( message="Please choose a folder to 
process", defaultLocation=".", wanted=string)

Which results in:

Traceback (most recent call last):
  File "Panther:Users:benjamin:Desktop:Python:finders:re-dup-
file.py", line 59, in ?
    test = EasyDialogs.AskFolder ( message="Please choose a folder 
to process", defaultLocation=".", wanted=string)
AttributeError: &#039;module&#039; object has no attribute &#039;AskFolder&#039;

If I run the EasyDialogs.py self test, it dies (without a traceback), 
right after the following code:

  rv = AskFileForSave(wanted=Carbon.File.FSRef, 
savedFileName="%s.txt"%s)
    Message("rv.as_pathname: %s"%rv.as_pathname())
 
Which the AskFolder test is what appears to be crashing the 
EasyDialogs test...  (Since the pathname test message is appearing 
during the self test).



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

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

From noreply at sourceforge.net  Tue Mar  9 09:19:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 11:02:34 2004
Subject: [ python-Bugs-912747 ] Unable to overwrite file with
	findertools.move
Message-ID: <E1B0i4r-0002BV-00@sc8-sf-web3.sourceforge.net>

Bugs item #912747, was opened at 2004-03-09 09:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912747&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Benjamin Schollnick (bscholln)
Assigned to: Jack Jansen (jackjansen)
Summary: Unable to overwrite file with findertools.move

Initial Comment:
I am revising a application that was working on MOSX 10.2, but 
Python v2.3 appears to have subtle broke a few items...

if mac_mode:
	findertools.move (old_path + filename, new_path)

Is dying with the following error...


Main, filename : 01_100_QTSKINS_L_12.JPG
Moving
-------------------------------------
Traceback (most recent call last):
  File "Panther:Users:benjamin:Desktop:Python:finders:re-dup-
file.py", line 102, in ?
    move_file ( pathname, new_dir, filename )
  File "Panther:Users:benjamin:Desktop:Python:finders:re-dup-
file.py", line 53, in move_file
    findertools.move (old_path + filename, new_path)
  File "mac:Applications:Python 2.2.2:Mac:Lib:findertools.py", line 
74, in move
    return finder.move(src_fss, to=dst_fss)
  File "mac:Applications:Python 2.2.2:Mac:Lib:lib-scriptpackages:
Finder:Standard_Suite.py", line 294, in move
    raise aetools.Error, aetools.decodeerror(_arguments)
aetools.Error: (-10000, &#039;errAEEventFailed&#039;, None)

As far as I can tell, the move command is not allowing a overwrite 
situation...

If this is expected behavior, is there any way we could add a flag 
for allowing overwrite?




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

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

From noreply at sourceforge.net  Tue Mar  9 11:32:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 11:32:30 2004
Subject: [ python-Bugs-912845 ] urllib2 checks for http return code 200 only.
Message-ID: <E1B0k9Z-0006le-00@sc8-sf-web2.sourceforge.net>

Bugs item #912845, was opened at 2004-03-09 18:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912845&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ahmed F. (oneofone)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 checks for http return code 200 only.

Initial Comment:
from urllib2 import *
req = Request("http://someurl/page.html",
headers={&#039;range: bytes=%s&#039;:&#039;20-40&#039;})
result = urlopen(req)

will die with something like :
  File "/usr/lib/python2.3/urllib2.py", line 306, in
_call_chain
    result = func(*args)
  File "/usr/lib/python2.3/urllib2.py", line 412, in
http_error_default
    raise HTTPError(req.get_full_url(), code, msg,
hdrs, fp)
urllib2.HTTPError: HTTP Error 206: Partial Content


line 892 in {PATH}/urllib2.py should be changed from :
if code == 200:
to
if code in [200, 206]:

peace



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

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

From noreply at sourceforge.net  Tue Mar  9 14:16:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 14:16:53 2004
Subject: [ python-Bugs-912943 ] 7.5.6 Thread Objects is too vague
Message-ID: <E1B0mic-0001rA-00@sc8-sf-web1.sourceforge.net>

Bugs item #912943, was opened at 2004-03-09 14:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=912943&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Roy Smith (roysmith)
Assigned to: Nobody/Anonymous (nobody)
Summary: 7.5.6 Thread Objects is too vague

Initial Comment:
Some items which could be improved....

"Once the thread&#039;s activity is started, the thread is considered 
&#039;alive&#039; and &#039;active&#039; (these concepts are almost, but not quite 
exactly, the same; their definition is intentionally somewhat 
vague)."

This is a bit silly.  Either these attributes are intended to be 
exposed to users or they&#039;re not.  If they are, they should be well 
defined.  If not, they shouldn&#039;t be mentioned at all.

"If the subclass overrides the constructor, it must make sure to 
invoke the base class constructor (Thread.__init__()) before doing 
anything else to the thread."

This is misleading.  You need to call "Thread.__init__ (self)", i.e. 
pass along the self argument.  At least I think you do :-)

"join([timeout]) ... When the timeout argument is present and not 
None, it should be a floating point number specifying a timeout for 
the operation in seconds (or fractions thereof)."

What happens if you pass None?  Does it wait forever?  Is this any 
different from not passing any argument at all?  What happens if a 
timeout occurs?  Is there any way to differentiate between a 
timeout and a normal return?

"A thread can be join()ed many times."

Presumably only if all but the last call timed out?  Or maybe not?  
If you get a normal return (i.e. not a timeout) from join(), and 
then call join() again, what happens?  Does it just return 
immediately with no error?


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

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

From noreply at sourceforge.net  Tue Mar  9 09:13:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 15:03:09 2004
Subject: [ python-Feature Requests-912738 ] Generator-support in map() and
	filter()
Message-ID: <E1B0hzE-00045u-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #912738, was opened at 2004-03-09 14:13
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=912738&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ragnar Kj?rstad (ragnark)
Assigned to: Nobody/Anonymous (nobody)
Summary: Generator-support in map() and filter()

Initial Comment:
The current implementation of map() and filter()
returns a list when executed on any iterator, including
generators.

However, it may be very useful to map and filter the
output from generators without having to generate all
the data and allocate memory for it.

I would propose for map() and filter() to return a
generator-object instead of a list when the
input-argument is a generator.

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

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

From noreply at sourceforge.net  Tue Mar  9 15:11:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 15:11:59 2004
Subject: [ python-Feature Requests-912738 ] Generator-support in map() and
	filter()
Message-ID: <E1B0nZv-00087c-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #912738, was opened at 2004-03-09 09:13
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=912738&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Ragnar Kj?rstad (ragnark)
Assigned to: Nobody/Anonymous (nobody)
Summary: Generator-support in map() and filter()

Initial Comment:
The current implementation of map() and filter()
returns a list when executed on any iterator, including
generators.

However, it may be very useful to map and filter the
output from generators without having to generate all
the data and allocate memory for it.

I would propose for map() and filter() to return a
generator-object instead of a list when the
input-argument is a generator.

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

>Comment By: Tim Peters (tim_one)
Date: 2004-03-09 15:11

Message:
Logged In: YES 
user_id=31435

It's (far) too late to change the signature of map() and filter
().  Look in the itertools module instead:  its ifilter() and imap
() functions already do what you asked for (and more).

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

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

From noreply at sourceforge.net  Tue Mar  9 16:21:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 16:22:00 2004
Subject: [ python-Feature Requests-668905 ] logging module documentation
Message-ID: <E1B0ofi-0001QO-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #668905, was opened at 2003-01-16 16:07
Message generated for change (Comment added) made by richard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module documentation

Initial Comment:
I believe the logging module documentation needs to give an 
example of how to simply log to a file. The following example snippet 
could be appropriate: 
 
import logging 
logger = logging.getLogger(&#039;myapp&#039;) 
hdlr = FileHandler(&#039;/var/myapp/debug.log&#039;) 
hdlr.setFormatter(Formatter(&#039;%(asctime)s %(level)s %(message)s&#039;)) 
logger.addHandler(hdlr) 
logger.setLevel(DEBUG) 
 
 

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

>Comment By: Richard Jones (richard)
Date: 2004-03-10 08:21

Message:
Logged In: YES 
user_id=6405

Please consider adding a simpler interface for people who just 
want to log to a file: 
 
  import logging 
  logger = logging.open('/var/log/myapp.log') 
 
which does the equivalent of: 
 
  import logging 
  logger = logging.getLogger('<default>') 
  hdlr = logging.FileHandler('/var/log/myapp.log') 
  formatter = logging.Formatter('%(asctime)s %(levelname)s 
%(message)s') 
  hdlr.setFormatter(formatter) 
  logger.addHandler(hdlr) 
  logger.setLevel(logging.INFO) 
 
which is what I expect most users will want when they first 
see this module. If they then want to mess around with 
additional handers, or different formatting or whatever, then 
they can read the reference doc. 
 
Please make the simplest use-case much simpler! 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-01 18:10

Message:
Logged In: YES 
user_id=80475

I would also like to see a more thorough set of introductory
examples.  The second page of the unittest documentation
could serve as a model -- it attempts to cover the 90% of
what you need to know in a single page of examples.   As it
stands now, the documentation for the logging module is
formidable.  Those wanting to take advantage of the module
face a steep learning curve from rather heavyweight
documentation -- it's complexity exceeds that of almost all
modules except for the email and xml packages.

Assigning to Vinay Sajip to work with Anthony to improve the
docs.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-07-08 16:32

Message:
Logged In: YES 
user_id=29957

Why was this closed? nnorwitz's doc fixes, as seen in CVS or 
http://www.python.org/dev/doc/devel/lib/module-logging.html
have no examples section.  

Running the current logging module docs past a number of 
python coders here produced a consistent "what the heck?"
response - the opening introduction provides no indications of
how to use the package. 
This is a problem for me, right now, so I'm re-opening and
assigning to myself to fix.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 16:37

Message:
Logged In: YES 
user_id=80475

Reviewed.
Closing RFE.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-26 08:36

Message:
Logged In: YES 
user_id=33168

I just updated the logging documentation.  Could you please
review for accuracy and completeness?

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

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

From noreply at sourceforge.net  Tue Mar  9 16:35:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 16:35:05 2004
Subject: [ python-Bugs-678265 ] test_coercion fails on AIX
Message-ID: <E1B0osQ-0002qs-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_coercion fails on AIX

Initial Comment:
Tim, I assigned this to you to see if you had any 
insight/ideas about this problem.

test_coercion fails on AIX.  All the failures are due to the 
test expecting n+0j, but the output is n-0j.

Here&#039;s an example:

- <MethodNumber 1> / (2+0j) = (0.5+0j)
?                                 ^
+ <MethodNumber 1> / (2+0j) = (0.5-0j)
?                                 ^

I have another compiler, so I&#039;ll probably try that.  
Especially since it&#039;s gcc. :-)

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-09 15:35

Message:
Logged In: YES 
user_id=994239

I've run into this same problem under AIX 4.3.3 with IBM
compiler version 6.0.0.5 and under AIX 5.1 with IBM compiler
version 6.0.0.4.

Is there a work-around, other than building with gcc?


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-31 15:08

Message:
Logged In: YES 
user_id=31435

You really need a platform wizard for something like this.  If 
there are any compiler options with descriptions 
like "generate IEEE-754 compatible code" (or "stricter 754 
xyz"), or "disable generation of fused multiply-add", they 
would be relevant.

OTOH, Python promises nothing about how the sign bit of a 
floating zero behaves, so it would be OK by me if the test 
were changed not to produce complex results with zero 
imaginary members.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-31 13:26

Message:
Logged In: YES 
user_id=33168

The test passes with gcc 3.2.  The C compiler is in vac.C 
version 4.4.0.3 (lslpp -l vac.C).

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

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

From noreply at sourceforge.net  Tue Mar  9 18:22:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 18:22:53 2004
Subject: [ python-Bugs-678265 ] test_coercion fails on AIX
Message-ID: <E1B0qYj-0005pM-00@sc8-sf-web4.sourceforge.net>

Bugs item #678265, was opened at 2003-01-31 18:10
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_coercion fails on AIX

Initial Comment:
Tim, I assigned this to you to see if you had any 
insight/ideas about this problem.

test_coercion fails on AIX.  All the failures are due to the 
test expecting n+0j, but the output is n-0j.

Here&#039;s an example:

- <MethodNumber 1> / (2+0j) = (0.5+0j)
?                                 ^
+ <MethodNumber 1> / (2+0j) = (0.5-0j)
?                                 ^

I have another compiler, so I&#039;ll probably try that.  
Especially since it&#039;s gcc. :-)

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-09 23:22

Message:
Logged In: YES 
user_id=35752

I really didn't intend for test_coercion to become a
platform fp quirks test.  The attached patch changes the
test to format floating point
numbers to one decimal place.


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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-09 21:35

Message:
Logged In: YES 
user_id=994239

I've run into this same problem under AIX 4.3.3 with IBM
compiler version 6.0.0.5 and under AIX 5.1 with IBM compiler
version 6.0.0.4.

Is there a work-around, other than building with gcc?


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-31 21:08

Message:
Logged In: YES 
user_id=31435

You really need a platform wizard for something like this.  If 
there are any compiler options with descriptions 
like "generate IEEE-754 compatible code" (or "stricter 754 
xyz"), or "disable generation of fused multiply-add", they 
would be relevant.

OTOH, Python promises nothing about how the sign bit of a 
floating zero behaves, so it would be OK by me if the test 
were changed not to produce complex results with zero 
imaginary members.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-31 19:26

Message:
Logged In: YES 
user_id=33168

The test passes with gcc 3.2.  The C compiler is in vac.C 
version 4.4.0.3 (lslpp -l vac.C).

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

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

From noreply at sourceforge.net  Tue Mar  9 19:16:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar  9 19:16:47 2004
Subject: [ python-Bugs-678265 ] test_coercion fails on AIX
Message-ID: <E1B0rOu-00019I-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_coercion fails on AIX

Initial Comment:
Tim, I assigned this to you to see if you had any 
insight/ideas about this problem.

test_coercion fails on AIX.  All the failures are due to the 
test expecting n+0j, but the output is n-0j.

Here&#039;s an example:

- <MethodNumber 1> / (2+0j) = (0.5+0j)
?                                 ^
+ <MethodNumber 1> / (2+0j) = (0.5-0j)
?                                 ^

I have another compiler, so I&#039;ll probably try that.  
Especially since it&#039;s gcc. :-)

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-09 19:16

Message:
Logged In: YES 
user_id=33168

IIRC, there was a command line switch to xlc which would
change the math behaviour.  I don't recall trying it but
from the description it seemed like it would work.  

Neil, I'll try to look at your patch.  If you think it's not
controversial, just check it in.  I'll definitely review it
in that case. :-)

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

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-09 18:22

Message:
Logged In: YES 
user_id=35752

I really didn't intend for test_coercion to become a
platform fp quirks test.  The attached patch changes the
test to format floating point
numbers to one decimal place.


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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-09 16:35

Message:
Logged In: YES 
user_id=994239

I've run into this same problem under AIX 4.3.3 with IBM
compiler version 6.0.0.5 and under AIX 5.1 with IBM compiler
version 6.0.0.4.

Is there a work-around, other than building with gcc?


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-31 16:08

Message:
Logged In: YES 
user_id=31435

You really need a platform wizard for something like this.  If 
there are any compiler options with descriptions 
like "generate IEEE-754 compatible code" (or "stricter 754 
xyz"), or "disable generation of fused multiply-add", they 
would be relevant.

OTOH, Python promises nothing about how the sign bit of a 
floating zero behaves, so it would be OK by me if the test 
were changed not to produce complex results with zero 
imaginary members.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-31 14:26

Message:
Logged In: YES 
user_id=33168

The test passes with gcc 3.2.  The C compiler is in vac.C 
version 4.4.0.3 (lslpp -l vac.C).

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

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

From noreply at sourceforge.net  Wed Mar 10 11:52:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 11:52:54 2004
Subject: [ python-Bugs-678265 ] test_coercion fails on AIX
Message-ID: <E1B16wp-0005OZ-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_coercion fails on AIX

Initial Comment:
Tim, I assigned this to you to see if you had any 
insight/ideas about this problem.

test_coercion fails on AIX.  All the failures are due to the 
test expecting n+0j, but the output is n-0j.

Here&#039;s an example:

- <MethodNumber 1> / (2+0j) = (0.5+0j)
?                                 ^
+ <MethodNumber 1> / (2+0j) = (0.5-0j)
?                                 ^

I have another compiler, so I&#039;ll probably try that.  
Especially since it&#039;s gcc. :-)

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 10:52

Message:
Logged In: YES 
user_id=994239

Looks like the test is still failing, even with this patch.

Any idea what that xlc option might have been?  I looked
through the list of options, but it wasn't immediately
obvious to me which one might have helped.

Any other ideas?  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-09 18:16

Message:
Logged In: YES 
user_id=33168

IIRC, there was a command line switch to xlc which would
change the math behaviour.  I don't recall trying it but
from the description it seemed like it would work.  

Neil, I'll try to look at your patch.  If you think it's not
controversial, just check it in.  I'll definitely review it
in that case. :-)

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

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-09 17:22

Message:
Logged In: YES 
user_id=35752

I really didn't intend for test_coercion to become a
platform fp quirks test.  The attached patch changes the
test to format floating point
numbers to one decimal place.


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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-09 15:35

Message:
Logged In: YES 
user_id=994239

I've run into this same problem under AIX 4.3.3 with IBM
compiler version 6.0.0.5 and under AIX 5.1 with IBM compiler
version 6.0.0.4.

Is there a work-around, other than building with gcc?


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-31 15:08

Message:
Logged In: YES 
user_id=31435

You really need a platform wizard for something like this.  If 
there are any compiler options with descriptions 
like "generate IEEE-754 compatible code" (or "stricter 754 
xyz"), or "disable generation of fused multiply-add", they 
would be relevant.

OTOH, Python promises nothing about how the sign bit of a 
floating zero behaves, so it would be OK by me if the test 
were changed not to produce complex results with zero 
imaginary members.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-31 13:26

Message:
Logged In: YES 
user_id=33168

The test passes with gcc 3.2.  The C compiler is in vac.C 
version 4.4.0.3 (lslpp -l vac.C).

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

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

From noreply at sourceforge.net  Wed Mar 10 12:00:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:00:24 2004
Subject: [ python-Bugs-913619 ] httplib: HTTPS does not close() connection
	properly
Message-ID: <E1B1745-00060X-00@sc8-sf-web4.sourceforge.net>

Bugs item #913619, was opened at 2004-03-10 12:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=913619&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: rick (sf_rick)
Assigned to: Nobody/Anonymous (nobody)
Summary: httplib:  HTTPS does not close() connection properly

Initial Comment:
When looping through requests to an HTTP server close()
closes out the active connection.  An the second loop
through a new HTTP connection is created.

When looping through requests to an HTTPS server
close() does not close the connection.  It keeps it
active.  On the second pass through the loop
httplib.HTTPS uses the previously initiated connection.
 Shouldn&#039;t close() close out the connection as it does
for the HTTP connection?

sample code to illustrate:

def getdata(): 
    params = urllib.urlencode({&#039;username&#039;: &#039;test&#039;,
&#039;password&#039;: &#039;test&#039;})
    h = httplib.HTTPS(host = "test.site.com", port =
443, key_file = "fake.pem", cert_file = "fake.pem")
    h.putrequest(&#039;POST&#039;, &#039;/scripts/cgi.exe?&#039;)
    h.putheader(&#039;Content-length&#039;, &#039;%d&#039;%len(params))
    h.putheader(&#039;Accept&#039;, &#039;text/plain&#039;)
    h.putheader(&#039;Host&#039;, &#039;test.site.com&#039;)
    h.endheaders()
    h.send(params)
    reply, msg, hdrs = h.getreply()
    data = h.getfile().read()
    file(&#039;test.file&#039;, &#039;w&#039;).write(data)
    h.close()
    


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

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

From noreply at sourceforge.net  Wed Mar 10 11:02:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:06:51 2004
Subject: [ python-Bugs-913581 ] PythonLauncher-run scripts have funny $CWD
Message-ID: <E1B169m-0007O9-00@sc8-sf-web2.sourceforge.net>

Bugs item #913581, was opened at 2004-03-10 17:02
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=913581&group_id=5470

Category: Macintosh
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PythonLauncher-run scripts have funny $CWD

Initial Comment:
PythonLauncher suffers from the general .app problem that it&#039;s 
working directory is "/". This affects scripts run with 
PythonLauncher without a terminal window: they inherit that home 
directory.

Scripts run with a terminal window get $HOME as working 
directory.

PythonLauncher should do something unified, best is probably to 
either always use $HOME, or to use the directory where the script 
is located.

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

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

From noreply at sourceforge.net  Wed Mar 10 12:14:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:14:39 2004
Subject: [ python-Bugs-678250 ] test_mmap failling on AIX
Message-ID: <E1B17Hq-000802-00@sc8-sf-web4.sourceforge.net>

Bugs item #678250, was opened at 2003-01-31 11:44
Message generated for change (Comment added) made by mdr0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678250&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_mmap failling on AIX

Initial Comment:
test_mmap is failing on a flush while trying to do:
  Copy-on-write memory map data not written correctly

The problem is that the mmap is opened with 
ACCESS_COPY.  This translates to MAP_PRIVATE.  
On AIX, the msync man page says:  "When the 
MS_SYNC and MAP_PRIVATE flags both are used, the 
msync subroutine returns an errno value of EINVAL."

I&#039;m not sure what the correct fix should be.

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 11:14

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this something that's going to affect python if I put it
into production, or is it "safe" to ignore it?


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-01-07 16:06

Message:
Logged In: YES 
user_id=33168

run the test with the -v flag:  ./python
./Lib/test/regrtest.py -v test_mmap

I think only everything should be fine up to copy-on-write
tests.  Here's what a good run looks like:

[neal@epoch c3]$ ./python ./Lib/test/regrtest.py -v test_mmap
test_mmap
<type 'mmap.mmap'>
  Position of foo: 1.0 pages
  Length of file: 2.0 pages
  Contents of byte 0: '\x00'
  Contents of first 3 bytes: '\x00\x00\x00'
                                                           
                    
  Modifying file's content...
  Contents of byte 0: '3'
  Contents of first 3 bytes: '3\x00\x00'
  Contents of second page: '\x00foobar\x00'
  Regex match on mmap (page start, length of match): 1.0 6
  Seek to zeroth byte
  Seek to 42nd byte
  Seek to last byte
  Try to seek to negative position...
  Try to seek beyond end of mmap...
  Try to seek to negative position...
  Attempting resize()
  Creating 10 byte test data file.
  Opening mmap with access=ACCESS_READ
  Ensuring that readonly mmap can't be slice assigned.
  Ensuring that readonly mmap can't be item assigned.
  Ensuring that readonly mmap can't be write() to.
  Ensuring that readonly mmap can't be write_byte() to.
  Ensuring that readonly mmap can't be resized.
  Opening mmap with size too big
  Opening mmap with access=ACCESS_WRITE
  Modifying write-through memory map.
  Opening mmap with access=ACCESS_COPY
  Modifying copy-on-write memory map.
  Ensuring copy-on-write maps cannot be resized.
  Ensuring invalid access parameter raises exception.
 Test passed
1 test OK.


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

Comment By: Richard Wheeler (wheelrl)
Date: 2004-01-07 15:57

Message:
Logged In: YES 
user_id=249546

I am getting the same error on AIX 5.2 with Python 2.3.3 
release.  What can I do to get around the test error and 
verify the mmap is working?

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-06 15:00

Message:
Logged In: YES 
user_id=31435

Hmm.  I suspect the flush docs() are too strong (does flush 
really promise to materialize bytes *on disk*?  it doesn't for 
other Python file objects, you also need os.fsync() for that).

Your point is well taken, though, and whatever flush() does 
normally do, it's not going to do it for a copy-on-write mmap.  
So fine by me if we declare that attempting to flush() a copy-
on-write mmap raises an exception.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-03 05:09

Message:
Logged In: YES 
user_id=21627

The documentation for flush says

"Flushes changes made to the in-memory copy of a file back
to disk."

But it doesn't do that, and we all agree it shouldn't do
that. So I would claim that it is an error to use .flush on
an mmap object that was opened in ACCESS_COPY. 

This is like trying to write to a file that was opened for
reading only: one *could* declare that the write just does
nothing, but it helps the developer more if you get an
exception, because the code is likely wrong (i.e. not
following the likely intentions of the author).

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 14:55

Message:
Logged In: YES 
user_id=31435

Sorry, I've had nothing to do with mmap beyond fixing bugs.  
The "access" feature was due to Jay Miller, although I believe 
I checked in his patch.

Martin, I don't understand why you think it's reasonable for 
flush to complain here:  the mmap is open for writing, so 
what's surprising about expecting to be able to flush after a 
write?  Simply that there's no associated file, due to copy-on-
write?  Then user code would have to be acutely aware of how 
an mmap'ed object was opened, just to avoid nuisance 
complaints when they flush after writing.

So that's a third alternative:  alter the implementation to make 
mmap.flush() do nothing when an mmap object was opened 
as copy-on-write.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-03-04 01:00

Message:
Logged In: YES 
user_id=21627

I think the test is somewhat bogus: It tries to check that
modification to an ACCESS_COPY doesn't modify the underlying
file, but assumes that .flush becomes a no-op, even though
an exception is more reasonable (IMO; errors should never
pass silently).

So I see two options: Declare that .flush() always raises an
exception (and modify implementations that don't produce an
exception accordingly), or declare that aspect to be
system-dependent, and modify the test (and the
documentation) to expect and ignore an exception.

Assigning to Tim, as he incorporated that feature into mmap.

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

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

From noreply at sourceforge.net  Wed Mar 10 12:22:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:22:42 2004
Subject: [ python-Bugs-713169 ] test_pty fails on HP-UX and AIX when run
	after test_openpty
Message-ID: <E1B17Pe-0007gV-00@sc8-sf-web3.sourceforge.net>

Bugs item #713169, was opened at 2003-04-01 01:35
Message generated for change (Comment added) made by mdr0
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=713169&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_pty fails on HP-UX and AIX when run after test_openpty

Initial Comment:
Here is the output from test_pty.py:

capulet:dist/src > ./python Lib/test/test_pty.py
Calling master_open()
Got master_fd &#039;3&#039;, slave_name &#039;/dev/pts/0&#039;
Calling slave_open(&#039;/dev/pts/0&#039;)
Got slave_fd &#039;4&#039;
Traceback (most recent call last):
  File "Lib/test/test_pty.py", line 58, in ?
    test_basic_pty()
  File "Lib/test/test_pty.py", line 29, in 
test_basic_pty
    if not os.isatty(slave_fd):
  File "Lib/test/test_pty.py", line 50, in handle_sig
    raise TestFailed, "isatty hung"
test.test_support.TestFailed: isatty hung


This was running Python 2.3a2 (downloaded from 
CVS on Sunday 30th March) built on HP-UX11i.

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 11:22

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this going to cause a problem if I put python into
produciton, or is it "safe" to ignore it?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 10:31

Message:
Logged In: YES 
user_id=33168

Actually, there is a 'fix' which is really a work-around the
problem.  You can disable os.openpty() in pty.master_open. 
I added a raise OSError at line 50 (before os.openpty()). 
This allows the test to pass.  I think Martin and I agreed
that globally disabling wasn't the best solution.  That
would probably be in some patch.

Also, just in case it isn't clear--if you run test_pty
BEFORE test_openpty, both tests pass.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-04-01 10:02

Message:
Logged In: YES 
user_id=33168

I fixed the test hanging, but not the actual bug.  The bug
appears when running test_pty after test_openpty.  There's
some interaction, but I don't know what it is.  The problem
happens on AIX also.  I searched through some man pages, but
nothing leapt out at me.  I think I tried googling for the
answer to no avail. Any insight or ideas would be helpful. 
This may have started when adding /dev/ptmx (ptc for AIX)
support.

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

Comment By: Michael Hudson (mwh)
Date: 2003-04-01 04:26

Message:
Logged In: YES 
user_id=6656

Neal?  I thought you thought this was fixed?

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

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

From noreply at sourceforge.net  Wed Mar 10 12:26:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:26:30 2004
Subject: [ python-Bugs-678264 ] test_resource fails when file size is limited
Message-ID: <E1B17TK-0008Dw-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Neal Norwitz (nnorwitz)
Summary: test_resource fails when file size is limited

Initial Comment:
test_resource does:

   print resource.RLIM_INFINITY == max

I&#039;m not sure of the benefit of this line.  For machines 
which have limited file sizes, it causes the test to fail.  
Otherwise the test seems to work properly.

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 11:26

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under AIX 4.3.3 and 5.1.  Is
this going to cause a problem if I put python into
production, or is it "safe" to ignore it?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-03-30 14:49

Message:
Logged In: YES 
user_id=21627

I'm really not that much concerned about fixing the test,
but more about fixing the code itself.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-30 14:25

Message:
Logged In: YES 
user_id=33168

Hmmm, sounds like a lot of work.  How about something like this:

    expected_max = resource.RLIM_INFINITY
    if expected_max != max:
        # read the file resource limit
        fsize_ulimit = os.popen('ulimit -f').read()
        try:
            # convert the file size to bytes (from 512 byte
blocks)
            expected_max = int(fsize_ulimit.strip()) * 512
        except ValueError:
            raise TestSkipped, "unable to determine expected
resource value"
    print expected_max == max

This works, but I'm pretty sure this is not portable.  On
Linux blocks are 1k.  This only works when the block size is
512 bytes.  Shall we close this bug as a test environment
problem and won't fix?

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-03-30 10:15

Message:
Logged In: YES 
user_id=21627

The rationale of the line is explained in the comment: The
code tests whether the limit is a really large number, i.e.
whether represenation of large limits works.

Unfortunately, it doesn't  (which is a separate issue): On
Linux, RLIM_INFINITY is reported as -1. This comes from
RLIM_INFINITY being the larges unsigned long long number,
i.e. 0xffffffffffffffffuLL. The resource module represents
this incorrectly.

I think there is no way to verify that Python computes the
real limit correctly (unless we invoke the shell's ulimit
for comparison). So you could weaken the test to verify that
the limit is non-negative (and, as a side effect, verify
that it doesn't raise an exception).

If you do so, you'll also have to fix the implementation, so
that the weakened-strengthened test passes on Linux.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-03-03 16:17

Message:
Logged In: YES 
user_id=33168

Martin, welcome back!  Now I get to assign some bugs to you
to see if you have any input. :-)

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

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

From noreply at sourceforge.net  Wed Mar 10 12:27:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:28:02 2004
Subject: [ python-Bugs-678265 ] test_coercion fails on AIX
Message-ID: <E1B17Ub-0001XM-00@sc8-sf-web4.sourceforge.net>

Bugs item #678265, was opened at 2003-01-31 18:10
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_coercion fails on AIX

Initial Comment:
Tim, I assigned this to you to see if you had any 
insight/ideas about this problem.

test_coercion fails on AIX.  All the failures are due to the 
test expecting n+0j, but the output is n-0j.

Here&#039;s an example:

- <MethodNumber 1> / (2+0j) = (0.5+0j)
?                                 ^
+ <MethodNumber 1> / (2+0j) = (0.5-0j)
?                                 ^

I have another compiler, so I&#039;ll probably try that.  
Especially since it&#039;s gcc. :-)

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-10 17:27

Message:
Logged In: YES 
user_id=35752

My patch didn't update the expected output for the test. 
I've uploaded a new patch that does (if you want to test it
again).

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 16:52

Message:
Logged In: YES 
user_id=994239

Looks like the test is still failing, even with this patch.

Any idea what that xlc option might have been?  I looked
through the list of options, but it wasn't immediately
obvious to me which one might have helped.

Any other ideas?  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-10 00:16

Message:
Logged In: YES 
user_id=33168

IIRC, there was a command line switch to xlc which would
change the math behaviour.  I don't recall trying it but
from the description it seemed like it would work.  

Neil, I'll try to look at your patch.  If you think it's not
controversial, just check it in.  I'll definitely review it
in that case. :-)

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

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-09 23:22

Message:
Logged In: YES 
user_id=35752

I really didn't intend for test_coercion to become a
platform fp quirks test.  The attached patch changes the
test to format floating point
numbers to one decimal place.


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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-09 21:35

Message:
Logged In: YES 
user_id=994239

I've run into this same problem under AIX 4.3.3 with IBM
compiler version 6.0.0.5 and under AIX 5.1 with IBM compiler
version 6.0.0.4.

Is there a work-around, other than building with gcc?


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-31 21:08

Message:
Logged In: YES 
user_id=31435

You really need a platform wizard for something like this.  If 
there are any compiler options with descriptions 
like "generate IEEE-754 compatible code" (or "stricter 754 
xyz"), or "disable generation of fused multiply-add", they 
would be relevant.

OTOH, Python promises nothing about how the sign bit of a 
floating zero behaves, so it would be OK by me if the test 
were changed not to produce complex results with zero 
imaginary members.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-31 19:26

Message:
Logged In: YES 
user_id=33168

The test passes with gcc 3.2.  The C compiler is in vac.C 
version 4.4.0.3 (lslpp -l vac.C).

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

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

From noreply at sourceforge.net  Wed Mar 10 12:34:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:35:05 2004
Subject: [ python-Bugs-678265 ] test_coercion fails on AIX
Message-ID: <E1B17bf-0002cQ-00@sc8-sf-web4.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_coercion fails on AIX

Initial Comment:
Tim, I assigned this to you to see if you had any 
insight/ideas about this problem.

test_coercion fails on AIX.  All the failures are due to the 
test expecting n+0j, but the output is n-0j.

Here&#039;s an example:

- <MethodNumber 1> / (2+0j) = (0.5+0j)
?                                 ^
+ <MethodNumber 1> / (2+0j) = (0.5-0j)
?                                 ^

I have another compiler, so I&#039;ll probably try that.  
Especially since it&#039;s gcc. :-)

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 11:34

Message:
Logged In: YES 
user_id=994239

Looks like that fixed it.  Thanks!

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

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-10 11:27

Message:
Logged In: YES 
user_id=35752

My patch didn't update the expected output for the test. 
I've uploaded a new patch that does (if you want to test it
again).

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 10:52

Message:
Logged In: YES 
user_id=994239

Looks like the test is still failing, even with this patch.

Any idea what that xlc option might have been?  I looked
through the list of options, but it wasn't immediately
obvious to me which one might have helped.

Any other ideas?  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-09 18:16

Message:
Logged In: YES 
user_id=33168

IIRC, there was a command line switch to xlc which would
change the math behaviour.  I don't recall trying it but
from the description it seemed like it would work.  

Neil, I'll try to look at your patch.  If you think it's not
controversial, just check it in.  I'll definitely review it
in that case. :-)

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

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-09 17:22

Message:
Logged In: YES 
user_id=35752

I really didn't intend for test_coercion to become a
platform fp quirks test.  The attached patch changes the
test to format floating point
numbers to one decimal place.


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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-09 15:35

Message:
Logged In: YES 
user_id=994239

I've run into this same problem under AIX 4.3.3 with IBM
compiler version 6.0.0.5 and under AIX 5.1 with IBM compiler
version 6.0.0.4.

Is there a work-around, other than building with gcc?


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-31 15:08

Message:
Logged In: YES 
user_id=31435

You really need a platform wizard for something like this.  If 
there are any compiler options with descriptions 
like "generate IEEE-754 compatible code" (or "stricter 754 
xyz"), or "disable generation of fused multiply-add", they 
would be relevant.

OTOH, Python promises nothing about how the sign bit of a 
floating zero behaves, so it would be OK by me if the test 
were changed not to produce complex results with zero 
imaginary members.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-31 13:26

Message:
Logged In: YES 
user_id=33168

The test passes with gcc 3.2.  The C compiler is in vac.C 
version 4.4.0.3 (lslpp -l vac.C).

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

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

From noreply at sourceforge.net  Wed Mar 10 12:39:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 12:39:42 2004
Subject: [ python-Bugs-678265 ] test_coercion fails on AIX
Message-ID: <E1B17gA-00034U-00@sc8-sf-web2.sourceforge.net>

Bugs item #678265, was opened at 2003-01-31 18:10
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=678265&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
>Assigned to: Neil Schemenauer (nascheme)
Summary: test_coercion fails on AIX

Initial Comment:
Tim, I assigned this to you to see if you had any 
insight/ideas about this problem.

test_coercion fails on AIX.  All the failures are due to the 
test expecting n+0j, but the output is n-0j.

Here&#039;s an example:

- <MethodNumber 1> / (2+0j) = (0.5+0j)
?                                 ^
+ <MethodNumber 1> / (2+0j) = (0.5-0j)
?                                 ^

I have another compiler, so I&#039;ll probably try that.  
Especially since it&#039;s gcc. :-)

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

>Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-10 17:39

Message:
Logged In: YES 
user_id=35752

Patch commited (test_coercion.py 1.7, test_coercion 1.6).

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 17:34

Message:
Logged In: YES 
user_id=994239

Looks like that fixed it.  Thanks!

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

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-10 17:27

Message:
Logged In: YES 
user_id=35752

My patch didn't update the expected output for the test. 
I've uploaded a new patch that does (if you want to test it
again).

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 16:52

Message:
Logged In: YES 
user_id=994239

Looks like the test is still failing, even with this patch.

Any idea what that xlc option might have been?  I looked
through the list of options, but it wasn't immediately
obvious to me which one might have helped.

Any other ideas?  Thanks!

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-10 00:16

Message:
Logged In: YES 
user_id=33168

IIRC, there was a command line switch to xlc which would
change the math behaviour.  I don't recall trying it but
from the description it seemed like it would work.  

Neil, I'll try to look at your patch.  If you think it's not
controversial, just check it in.  I'll definitely review it
in that case. :-)

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

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-09 23:22

Message:
Logged In: YES 
user_id=35752

I really didn't intend for test_coercion to become a
platform fp quirks test.  The attached patch changes the
test to format floating point
numbers to one decimal place.


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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-09 21:35

Message:
Logged In: YES 
user_id=994239

I've run into this same problem under AIX 4.3.3 with IBM
compiler version 6.0.0.5 and under AIX 5.1 with IBM compiler
version 6.0.0.4.

Is there a work-around, other than building with gcc?


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-31 21:08

Message:
Logged In: YES 
user_id=31435

You really need a platform wizard for something like this.  If 
there are any compiler options with descriptions 
like "generate IEEE-754 compatible code" (or "stricter 754 
xyz"), or "disable generation of fused multiply-add", they 
would be relevant.

OTOH, Python promises nothing about how the sign bit of a 
floating zero behaves, so it would be OK by me if the test 
were changed not to produce complex results with zero 
imaginary members.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-31 19:26

Message:
Logged In: YES 
user_id=33168

The test passes with gcc 3.2.  The C compiler is in vac.C 
version 4.4.0.3 (lslpp -l vac.C).

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

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

From noreply at sourceforge.net  Wed Mar 10 15:49:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 15:49:19 2004
Subject: [ python-Bugs-913698 ] smtplib module : fatal error with unresolved
	hostname
Message-ID: <E1B1Adf-0005PO-00@sc8-sf-web3.sourceforge.net>

Bugs item #913698, was opened at 2004-03-10 21:49
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=913698&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zarro (chaica)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib module : fatal error with unresolved hostname

Initial Comment:
I checked in the last cvs and the bug wasn&#039;t corriged.

if your hostname can&#039;t be resolved, so the module will
panic and raise a socket.gaierror in line 254:

addr = socket.gethostbyname(socket.gethostname())

>>> import socket
>>> socket.gethostname()
&#039;desktop&#039;
>>> socket.gethostbyname(socket.gethostname())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.gaierror: (-2, &#039;Name or service not known&#039;)

To correct, catch the exception and give a generic
value for self.local_hostname, for example localhost
127.0.0.1

try:
    addr = socket.gethostbyname(socket.gethostname())
    self.local_hostname = &#039;[%s]&#039; % addr
except socket.gaierror, msg:
    self.local_hostname = &#039;[%s]&#039; % &#039;127.0.0.1&#039;

Keep me tuned,
chaica@ohmytux.com


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

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

From noreply at sourceforge.net  Wed Mar 10 17:22:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 10 17:22:48 2004
Subject: [ python-Bugs-875404 ] global stmt causes breakpoints to be ignored
Message-ID: <E1B1C66-0000AN-00@sc8-sf-web1.sourceforge.net>

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

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Maciej Kalisiak (mackal)
Assigned to: Nobody/Anonymous (nobody)
Summary: global stmt causes breakpoints to be ignored

Initial Comment:
It seems that having a "global" statement in "main()" 
(perhaps elsewhere too) causes pdb to ignore
breakpoints in the whole application.  See the attached
example small program.

Procedure:
- pdb python_bug.py  # the attached program
- &#039;s&#039;, and then &#039;n&#039; once or twice to make sure prog loaded
- &#039;break main&#039;
- &#039;c&#039;

If the "global foo" statement is present, pdb will not
stop at the breakpoint.  If it is commented out (and
"foo = 1" as well, of course), the breakpoint is obeyed.

I&#039;m using
Python 2.3   (from the Debian "sid" distribution)
Tried under Linux 2.2.20, as well as 2.4.*.

Maciej Kalisiak
mac at dgp dot toronto dot edu


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

Comment By: Ilya Sandler (isandler)
Date: 2004-03-10 14:22

Message:
Logged In: YES 
user_id=971153

The same behaviour exists in the CVS version of python

Here is what (I think) happens:

1. When you try to set a break on a function: e.g "b main"
pdb sets a breakpoint not at "def main", but at the next non
comment/non-blank line of code

2. Sample code has "global " as a first
non-comment/non-blank line of code, so that's where pdb sets
the breakpoint

3. But global is a compile-time statement, the line with
global is never reached at run time, so pdb never stops there

Workaround for the original submitter: put any other
executable stmt as the first line of your main(), or set a
bkpt via line number

However, this behaviour is still wrong...The bug could be
probably fixed by adding more logic to pdb.checkline()....

Are there any other compile-time only statements?

I think I could submit a patch for this problem, but does
anyone look at pdb related patches?? My previous pdb patch
#896011 has been sitting in the queue for a month now...




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

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

From noreply at sourceforge.net  Thu Mar 11 09:14:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 11 09:14:16 2004
Subject: [ python-Bugs-914148 ] xml.sax segfault on error
Message-ID: <E1B1Qwv-0000E9-00@sc8-sf-web2.sourceforge.net>

Bugs item #914148, was opened at 2004-03-11 14:14
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914148&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Sampson (adamsampson)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax segfault on error

Initial Comment:
While (mistakenly) using Mark Pilgrim&#039;s feedparser
module to parse data from
<http://www.gothamist.com/archives/news_nyc/index.php>,
Python segfaults when it should invoke an error handler
for invalid XML. The attached code demonstrates the
problem; it occurs with Python 2.2.3 and 2.3.3 on my
system. I&#039;ve tried to chop the example data down as far
as possible, but reducing it any further doesn&#039;t
exhibit the problem (it&#039;s currently just above 64k,
which might be a coincidence).

The gdb traceback I get from the example is as follows:

#0  normal_updatePosition (enc=0x404a4fc0, 
    ptr=0x40682000 <Address 0x40682000 out of bounds>, 
    end=0x81e87e0 "a></div>\n\n<div
id=\content\>\n\n<div class=\blog\>\n<!--\n<rdf:RDF
xmlns:rdf=\http://www.w3.org/1999/02/22-rdf-syntax-ns#\\n
       
xmlns:trackback=\http://madskills.com/public/xml/rss/module/trackback/\\n"...,
pos=0x81e7dac)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmltok_impl.c:1745
#1  0x40484288 in XML_GetCurrentLineNumber
(parser=0x81e7c18)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmlparse.c:1605
#2  0x40481fc5 in set_error (self=0x0,
code=XML_ERROR_TAG_MISMATCH)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:124
#3  0x40480ae7 in xmlparse_Parse (self=0x402fddac,
args=0x0)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:888
#4  0x080fc25a in PyCFunction_Call (func=0x402faa0c,
arg=0x402f338c, 
    kw=0xfffffffb) at Objects/methodobject.c:108
#5  0x080aa674 in call_function (pp_stack=0xbffff03c,
oparg=0)
    at Python/ceval.c:3439
#6  0x080a8a2e in eval_frame (f=0x816e45c) at
Python/ceval.c:2116
#7  0x080a95bc in PyEval_EvalCodeEx (co=0x40303de0,
globals=0xfffffffb, 
    locals=0x0, args=0x816e5a8, argcount=2,
kws=0x816a9fc, kwcount=0, 
    defs=0x40321678, defcount=1, closure=0x0) at
Python/ceval.c:2663
#8  0x080aa729 in fast_function (func=0xfffffffb,
pp_stack=0xbffff1bc, n=2, 
    na=0, nk=135703028) at Python/ceval.c:3529
#9  0x080aa56c in call_function (pp_stack=0xbffff1bc,
oparg=0)
    at Python/ceval.c:3458
#10 0x080a8a2e in eval_frame (f=0x816a894) at
Python/ceval.c:2116
#11 0x080a95bc in PyEval_EvalCodeEx (co=0x402fd2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x402f3318, argcount=2, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#12 0x080fbda7 in function_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/funcobject.c:504
#13 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#14 0x08062288 in instancemethod_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/classobject.c:2433
#15 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#16 0x080aa892 in do_call (func=0x4032025c,
pp_stack=0x402f330c, na=0, nk=0)
    at Python/ceval.c:3644
#17 0x080aa4f9 in call_function (pp_stack=0xbffff5fc,
oparg=0)
    at Python/ceval.c:3460
#18 0x080a8a2e in eval_frame (f=0x818b414) at
Python/ceval.c:2116
#19 0x080aa7ad in fast_function (func=0xfffffffb,
pp_stack=0xbffff71c, n=2, 
    na=0, nk=1076865996) at Python/ceval.c:3518
#20 0x080aa56c in call_function (pp_stack=0xbffff71c,
oparg=0)
    at Python/ceval.c:3458
#21 0x080a8a2e in eval_frame (f=0x8183814) at
Python/ceval.c:2116
#22 0x080a95bc in PyEval_EvalCodeEx (co=0x402ed2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#23 0x080abdb9 in PyEval_EvalCode (co=0x0, globals=0x0,
locals=0x0)
    at Python/ceval.c:537
#24 0x080d7d2b in run_node (n=0x402bb79c, filename=0x0,
globals=0x0, 
    locals=0x0, flags=0x0) at Python/pythonrun.c:1265
#25 0x080d74df in PyRun_SimpleFileExFlags (fp=0x8139050, 
    filename=0xbffffa4d "testexpat.py",
closeit=-1073743283, flags=0xbffff878)
    at Python/pythonrun.c:862
#26 0x08054dd5 in Py_Main (argc=1, argv=0xbffff8f4) at
Modules/main.c:415
#27 0x0805492b in main (argc=0, argv=0x0) at
Modules/python.c:23


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

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

From noreply at sourceforge.net  Thu Mar 11 13:59:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 11 13:59:16 2004
Subject: [ python-Bugs-678250 ] test_mmap failling on AIX
Message-ID: <E1B1VOg-00032z-00@sc8-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neal Norwitz (nnorwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_mmap failling on AIX

Initial Comment:
test_mmap is failing on a flush while trying to do:
  Copy-on-write memory map data not written correctly

The problem is that the mmap is opened with 
ACCESS_COPY.  This translates to MAP_PRIVATE.  
On AIX, the msync man page says:  "When the 
MS_SYNC and MAP_PRIVATE flags both are used, the 
msync subroutine returns an errno value of EINVAL."

I&#039;m not sure what the correct fix should be.

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

>Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-11 13:59

Message:
Logged In: YES 
user_id=33168

Mark, the 3 bugs you commented on (this one, 713169, and
678264) are all test errors AFAIK.  It should be safe to
ignore them.  They are in extension modules that are not
used by many people.

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

Comment By: Mark D. Roth (mdr0)
Date: 2004-03-10 12:14

Message:
Logged In: YES 
user_id=994239

I'm running into this problem under both AIX 4.3.3 and 5.1.
 Is this something that's going to affect python if I put it
into production, or is it "safe" to ignore it?


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

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-01-07 17:06

Message:
Logged In: YES 
user_id=33168

run the test with the -v flag:  ./python
./Lib/test/regrtest.py -v test_mmap

I think only everything should be fine up to copy-on-write
tests.  Here's what a good run looks like:

[neal@epoch c3]$ ./python ./Lib/test/regrtest.py -v test_mmap
test_mmap
<type 'mmap.mmap'>
  Position of foo: 1.0 pages
  Length of file: 2.0 pages
  Contents of byte 0: '\x00'
  Contents of first 3 bytes: '\x00\x00\x00'
                                                           
                    
  Modifying file's content...
  Contents of byte 0: '3'
  Contents of first 3 bytes: '3\x00\x00'
  Contents of second page: '\x00foobar\x00'
  Regex match on mmap (page start, length of match): 1.0 6
  Seek to zeroth byte
  Seek to 42nd byte
  Seek to last byte
  Try to seek to negative position...
  Try to seek beyond end of mmap...
  Try to seek to negative position...
  Attempting resize()
  Creating 10 byte test data file.
  Opening mmap with access=ACCESS_READ
  Ensuring that readonly mmap can't be slice assigned.
  Ensuring that readonly mmap can't be item assigned.
  Ensuring that readonly mmap can't be write() to.
  Ensuring that readonly mmap can't be write_byte() to.
  Ensuring that readonly mmap can't be resized.
  Opening mmap with size too big
  Opening mmap with access=ACCESS_WRITE
  Modifying write-through memory map.
  Opening mmap with access=ACCESS_COPY
  Modifying copy-on-write memory map.
  Ensuring copy-on-write maps cannot be resized.
  Ensuring invalid access parameter raises exception.
 Test passed
1 test OK.


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

Comment By: Richard Wheeler (wheelrl)
Date: 2004-01-07 16:57

Message:
Logged In: YES 
user_id=249546

I am getting the same error on AIX 5.2 with Python 2.3.3 
release.  What can I do to get around the test error and 
verify the mmap is working?

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

Comment By: Tim Peters (tim_one)
Date: 2003-05-06 16:00

Message:
Logged In: YES 
user_id=31435

Hmm.  I suspect the flush docs() are too strong (does flush 
really promise to materialize bytes *on disk*?  it doesn't for 
other Python file objects, you also need os.fsync() for that).

Your point is well taken, though, and whatever flush() does 
normally do, it's not going to do it for a copy-on-write mmap.  
So fine by me if we declare that attempting to flush() a copy-
on-write mmap raises an exception.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-05-03 06:09

Message:
Logged In: YES 
user_id=21627

The documentation for flush says

"Flushes changes made to the in-memory copy of a file back
to disk."

But it doesn't do that, and we all agree it shouldn't do
that. So I would claim that it is an error to use .flush on
an mmap object that was opened in ACCESS_COPY. 

This is like trying to write to a file that was opened for
reading only: one *could* declare that the write just does
nothing, but it helps the developer more if you get an
exception, because the code is likely wrong (i.e. not
following the likely intentions of the author).

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

Comment By: Tim Peters (tim_one)
Date: 2003-04-28 15:55

Message:
Logged In: YES 
user_id=31435

Sorry, I've had nothing to do with mmap beyond fixing bugs.  
The "access" feature was due to Jay Miller, although I believe 
I checked in his patch.

Martin, I don't understand why you think it's reasonable for 
flush to complain here:  the mmap is open for writing, so 
what's surprising about expecting to be able to flush after a 
write?  Simply that there's no associated file, due to copy-on-
write?  Then user code would have to be acutely aware of how 
an mmap'ed object was opened, just to avoid nuisance 
complaints when they flush after writing.

So that's a third alternative:  alter the implementation to make 
mmap.flush() do nothing when an mmap object was opened 
as copy-on-write.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-03-04 02:00

Message:
Logged In: YES 
user_id=21627

I think the test is somewhat bogus: It tries to check that
modification to an ACCESS_COPY doesn't modify the underlying
file, but assumes that .flush becomes a no-op, even though
an exception is more reasonable (IMO; errors should never
pass silently).

So I see two options: Declare that .flush() always raises an
exception (and modify implementations that don't produce an
exception accordingly), or declare that aspect to be
system-dependent, and modify the test (and the
documentation) to expect and ignore an exception.

Assigning to Tim, as he incorporated that feature into mmap.

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

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

From noreply at sourceforge.net  Thu Mar 11 14:33:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 11 14:33:30 2004
Subject: [ python-Bugs-914375 ] modulefinder is not documented
Message-ID: <E1B1Vvq-0006Y3-00@sc8-sf-web4.sourceforge.net>

Bugs item #914375, was opened at 2004-03-11 14:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914375&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: modulefinder is not documented

Initial Comment:
The "modulefinder" module has not been documented.  Now
that it is a module, it needs to be documented.

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

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

From noreply at sourceforge.net  Fri Mar 12 12:24:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 12 12:24:52 2004
Subject: [ python-Bugs-751124 ] Enhancements to pdb.py when invoked as script
Message-ID: <E1B1qOr-0007As-00@sc8-sf-web3.sourceforge.net>

Bugs item #751124, was opened at 2003-06-08 19:19
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=751124&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Christian Stork (cst)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enhancements to pdb.py when invoked as script

Initial Comment:
Three little enhancements/mini-bugs:

1) Adding the following lines to the "main part" of pdb.py 
gives it the ability to stay in pdb if the program crashes.  
Very handy!

    # Ensure that we end up in pdb if we crash
    def pdb_on_crash(type, value, tb):
        sys.__excepthook__(type, value, tb)
        post_mortem(tb)
    sys.excepthook = pdb_on_crash

2) There&#039;s also a problem in the last lines of pdb.py:

    # Insert script directory in front of module search path
    sys.path.insert(0, os.path.dirname(filename))

This leaves the directory path under which pdb.py was 
invoked in sys.path.  This is a problem if pdb.py was 
invoked e.g. via a link a la /usr/pdb.  This leads to the last 
and related suggestion.

3) It would be very convenient if a pyhon installation would 
also install a link /usr/pdb -> /usr/lib/python2.3/pdb.py.  
This provides for easy invocation and, for example, it&#039;s also 
the default command used by Emacs&#039; pdb-mode.

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

Comment By: Ilya Sandler (isandler)
Date: 2004-03-12 09:24

Message:
Logged In: YES 
user_id=971153

a note for the reviewer:

patch #896011 fixes bug (2) and  implements (in a different
manner but with the same result)  feature (1),

PS. I  would also like to add my vote for (3). Being a
command line tool pdb.py deserves to be installed right next
to python binary..(on Linux that would often be /usr/bin)


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

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

From noreply at sourceforge.net  Sat Mar 13 13:28:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 13:38:18 2004
Subject: [ python-Bugs-910986 ] copy.copy fails for array.array
Message-ID: <E1B2Drp-0000kk-00@sc8-sf-web3.sourceforge.net>

Bugs item #910986, was opened at 2004-03-06 11:03
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=910986&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Glenn Parker (redandgray)
Assigned to: Raymond Hettinger (rhettinger)
Summary: copy.copy fails for array.array

Initial Comment:
Python version 2.3.3 under WindowsXP Home Edition

The standard library "copy" does not work with the
standard library "array".

import copy
import array
x = array.array(&#039;c&#039;, &#039;abcdef&#039;)
y = copy.copy(x)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/copy.py", line 95, in copy
    return _reconstruct(x, rv, 0)
  File "/usr/lib/python2.3/copy.py", line 338, in
_reconstruct
    y = callable(*args)
  File "/usr/lib/python2.3/copy_reg.py", line 92, in
__newobj__
    return cls.__new__(cls, *args)
TypeError: array() takes at least 1 argument (0 given)

The same thing happens for copy.deepcopy.

Judging from the TypeError details, it appears that
copy.copy assumes a new object of the same type as its
input argument can be created with no arguments, but
array.array requires at least one argument (describing
the type of items in the array).

array.array should have a custom method added to make
it work smoothly with copy.copy.

Documentation for copy.copy should be clearer about the
requirements on the type of its input argument.


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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 13:28

Message:
Logged In: YES 
user_id=80475

Okay, added support for the copy module.

See Modules/arraymodule.c 2.93

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

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

From noreply at sourceforge.net  Sat Mar 13 16:48:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 18:00:17 2004
Subject: [ python-Feature Requests-686323 ] Minor array module enhancements
Message-ID: <E1B2GzD-0008Be-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #686323, was opened at 2003-02-13 20:13
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=686323&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: Later
Priority: 4
Submitted By: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Minor array module enhancements

Initial Comment:
1) I notice that array(&#039;B&#039;, (2,3,4)) throws an error
saying the
2nd arg must be a list or string.  That is, array(&#039;B&#039;,
[2,3,4]) is
legal but using the tuple (2,3,4) is not.  The
limitation doesn&#039;t
seem harmful, but I also don&#039;t see any good reason for
it.  May
as well remove it.

2) Of more usefulness (and maybe of more controversy), I
think the byte array methods should accept string
arguments,
for example
   a = array(&#039;B&#039;, &#039;abc&#039;)
   a.append(&#039;def&#039;)
should do the obvious thing.  That gives a natural way to
build up a string in pieces instead of making a list of
strings
and doing the counterintuitive &#039;&#039;.join(x) maneuver. 
Appending
to byte arrays is the usual way to build up a string in
Java,
if that matters.  So I favor this change too.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 05:48

Message:
Logged In: YES 
user_id=80475

Added the first request as
  arraymodule.c 2.88

I'm passing on the second request for now.
Auto-promoting the argument entails attempting
to construct a new array object of the same type
as that being extended.  That is a bit cumbersome
but doable.  It also requires that any array creation
errors be trapped and re-explained the context of
array.extend().

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

Comment By: paul rubin (phr)
Date: 2003-02-13 23:42

Message:
Logged In: YES 
user_id=72053

You're correct, second request should be for extend rather
than append.

That is,

a = array('B', 'abc')
a.extend('def')

should do the obvious thing.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-13 23:34

Message:
Logged In: YES 
user_id=80475

The first request is reasonable.

The second is not the natural meaning of append().  In 
python, multiple appends are handled with extend().  The 
array module already provides extend.  So, for the 
example given above, the code is:

>>> a = array('B', 'abc')
>>> a.extend(array('B', 'def'))
>>> a
array('B', [97, 98, 99, 100, 101, 102])

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

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

From noreply at sourceforge.net  Sat Mar 13 18:13:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 18:23:34 2004
Subject: [ python-Bugs-733819 ] PackMan recursive/force fails on pseudo
	packages
Message-ID: <E1B2IJU-0004P9-00@sc8-sf-web1.sourceforge.net>

Bugs item #733819, was opened at 2003-05-07 13:53
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=733819&group_id=5470

Category: Macintosh
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jack Jansen (jackjansen)
Assigned to: Jack Jansen (jackjansen)
Summary: PackMan recursive/force fails on pseudo packages

Initial Comment:
If you set both install dependencies and overwrite, and the package 
depends on a pseudo-package, PackMan tries to install that pseudo-
package and fails.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2004-03-14 00:13

Message:
Logged In: YES 
user_id=45365

Fixed in 1.32 by making overwrite apply only to the package you're 
installing, not to its dependencies.

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

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

From noreply at sourceforge.net  Sat Mar 13 16:42:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 18:31:57 2004
Subject: [ python-Feature Requests-904770 ] http://doc.python.org
Message-ID: <E1B2Gts-0007n8-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #904770, was opened at 2004-02-25 21:55
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=904770&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Aahz (aahz)
Summary: http://doc.python.org

Initial Comment:
If http://python.org/doc/ were mirrored at http://doc.python.org/ it 
would be much easier to search, especially via google.

f.ex. "datetime site:doc.python.org"

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 16:42

Message:
Logged In: YES 
user_id=80475

This use case seems pluasable enough to warrant
consideration.  Aahz, what do you think?

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

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

From noreply at sourceforge.net  Sat Mar 13 16:45:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 18:45:45 2004
Subject: [ python-Feature Requests-740495 ] API enhancement:
	poplib.MailReader()
Message-ID: <E1B2GwP-0007z6-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #740495, was opened at 2003-05-20 09:35
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=740495&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Hartmut Goebel (htgoebel)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: API enhancement: poplib.MailReader()

Initial Comment:
When retrieving POP3 mails using poplib, messages are
returned as
list of lines. Converting them to a email.Messages requires
concatinating them into a single string.

I suggest writing a little file-like class wrapper
which may be used for
parsing these type of messages without concatinating
the lines first.
This wrapper may be exposed in the poplib module.

I suggest calling this class &#039;MailReader&#039;, but I would
appreciate better naeming :-)

If this is of interest, I may volunteer writing this
wrapper.

See also:
Feature Requests item #736494, was opened at 2003-05-12
11:17
Message generated for change (Comment added) made by
bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=384681&aid=736494&group_id=25568


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-01 01:50

Message:
Logged In: YES 
user_id=80475

Perhaps the adaptor should be part of the email package
rather than a part of poplib.

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

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

From noreply at sourceforge.net  Sat Mar 13 17:46:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 20:01:33 2004
Subject: [ python-Feature Requests-721061 ] Add copyrange method to array.
Message-ID: <E1B2Hts-00038H-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #721061, was opened at 2003-04-14 22:41
Message generated for change (Comment added) made by nyamatongwe
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=721061&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Hodgson (nyamatongwe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add copyrange method to array.

Initial Comment:
The split buffer data structure commonly used in text 
editors to efficiently manipulate text and data attached 
to that text can be implemented using the Python array 
type with the addition of a way to rapidly copy data 
within arrays. There may be other situations in which 
rapidly copying blocks within an array is useful.

-- Neil Hodgson

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

>Comment By: Neil Hodgson (nyamatongwe)
Date: 2004-03-14 09:46

Message:
Logged In: YES 
user_id=12579

If you are asking how the copyrange differs from a sliced
copy like
>>> import array
>>> a = array.array("c", "0123456789")
>>> a
array('c', '0123456789')
>>> a[5:8] = a[0:3]
>>> a
array('c', '0123401289')

   There is an extra object creation and copy for the
temporary slice. I think the actual copy between slices of
the same type is fast. Possibly the original patch was lost
so it can be found at
http://scintilla.sourceforge.net/arraycopyrange.diff
   I didn't chase this much before as it may be better for
me to produce a 'text' class that combines more features
into an efficient mutable document type.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-14 08:44

Message:
Logged In: YES 
user_id=80475

How does this differ from slice semantics?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 17:44

Message:
Logged In: YES 
user_id=80475

Moving to feature requests.

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

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

From noreply at sourceforge.net  Sat Mar 13 16:44:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 20:03:36 2004
Subject: [ python-Feature Requests-721061 ] Add copyrange method to array.
Message-ID: <E1B2Gvu-0007wZ-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #721061, was opened at 2003-04-14 07:41
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=721061&group_id=5470

Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Neil Hodgson (nyamatongwe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add copyrange method to array.

Initial Comment:
The split buffer data structure commonly used in text 
editors to efficiently manipulate text and data attached 
to that text can be implemented using the Python array 
type with the addition of a way to rapidly copy data 
within arrays. There may be other situations in which 
rapidly copying blocks within an array is useful.

-- Neil Hodgson

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 16:44

Message:
Logged In: YES 
user_id=80475

How does this differ from slice semantics?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 02:44

Message:
Logged In: YES 
user_id=80475

Moving to feature requests.

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

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

From noreply at sourceforge.net  Sat Mar 13 16:32:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 20:17:36 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1B2GkM-000764-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Sherborne (matiu)
>Assigned to: Brett Cannon (bcannon)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of &#039;dd-mm-yy&#039;

Now in python:
>>> from time import *
>>> print strftime(&#039;%c&#039;, localtime)
02/17/04 09:15:10
>>> print strftime(&#039;%x&#039;, localtime())
02/17/04

This is giving the date in the format &#039;mm-dd-yy&#039;
(American).

Could it be to do with the &#039;locale.nl_langinfo&#039; bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 16:50

Message:
Logged In: YES 
user_id=357491

This is a Windows C library bug and nothing to do with our end.  
Since time.strftime is just a wrapper around ISO C's strftime function we 
just pass in the arguments and then pass them back out without fiddling 
with anything.

So unless there is some compiler setting that needs to be set to be more 
locale-sensitive (doubt it, but since I don't have a Windows box I have no 
way of knowing; this is why I am unassigning this from myself) this is 
probably invalid and Microsoft's fault.

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 15:29

Message:
Logged In: YES 
user_id=304464

Sorry, code should be:

>>> from time import *
>>> print strftime('%c', localtime())
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

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

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

From noreply at sourceforge.net  Sat Mar 13 16:31:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 21:08:54 2004
Subject: [ python-Bugs-896330 ] pyconfig.h is not placed in --includedir
Message-ID: <E1B2Giz-0006zO-00@sc8-sf-web2.sourceforge.net>

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

Category: Installation
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: G?ran Uddeborg (goeran)
>Assigned to: Martin v. L?wis (loewis)
Summary: pyconfig.h is not placed in --includedir

Initial Comment:
When configuring Python with an explicit --includedir
most of the header files do turn up in this directory.
 But the pyconfig.h is still placed in $(prefix)/include.

I assume it is a bug, and this file too should be
placed according to --includedir.

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

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

From noreply at sourceforge.net  Sat Mar 13 16:32:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 21:42:53 2004
Subject: [ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Message-ID: <E1B2Gju-00073n-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Sankov Dmitry Alexandrovich (sankov_da)
>Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore.dispactcher: incorrect connect

Initial Comment:
When i use non-blocking socket, connect() method of
asyncore.dispatcher class looks like works incorrect.

Example: if connection have not established then socket
merely closed and handle_error not called and no
exception throwed.

One more example: if writable() and readble() methods
returns zero than handle_connect() will never be called
even if connection will be established.

Thanks.


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

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 03:22

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

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

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

From noreply at sourceforge.net  Sat Mar 13 16:41:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 22:25:56 2004
Subject: [ python-Feature Requests-846553 ] Addition to break and continue
Message-ID: <E1B2GsW-0007g8-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #846553, was opened at 2003-11-21 07:48
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846553&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Alexander R?dseth (alexanro)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: Addition to break and continue

Initial Comment:
It would be great if one could use "break for", "break
while", "continue for" or "continue while".

A silly example:

for i in range(100):
    counter = 0
    while 1+1 == 2:
        counter += 1
        if counter > 5:
            break for

"break for" should here jump out of the for-loop, as
opposed to just "break" that would jump out of just the
while loop. Using "break for" and friends will make
code a lot more readable and explicit, and avoid using
exception throwing and catching, and other acrobatics.

I believe this suggestion is in sync with the Python
Design guidelines.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 16:41

Message:
Logged In: YES 
user_id=80475

Guido, I recommend against accepting these forms which are
out of sync with the way the rest of the world uses break,
continue, try, and except.

The proposal is also thin on use cases and does not fit
comfortably with the current implementation.

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

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-21 20:43

Message:
Logged In: YES 
user_id=39274

What you will do to exit from outer of two for's from inside
inner?

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

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

From noreply at sourceforge.net  Sat Mar 13 23:24:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 13 23:24:44 2004
Subject: [ python-Feature Requests-846553 ] Addition to break and continue
Message-ID: <E1B2NAz-0001iG-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #846553, was opened at 2003-11-21 07:48
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=846553&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Alexander R?dseth (alexanro)
Assigned to: Guido van Rossum (gvanrossum)
Summary: Addition to break and continue

Initial Comment:
It would be great if one could use "break for", "break
while", "continue for" or "continue while".

A silly example:

for i in range(100):
    counter = 0
    while 1+1 == 2:
        counter += 1
        if counter > 5:
            break for

"break for" should here jump out of the for-loop, as
opposed to just "break" that would jump out of just the
while loop. Using "break for" and friends will make
code a lot more readable and explicit, and avoid using
exception throwing and catching, and other acrobatics.

I believe this suggestion is in sync with the Python
Design guidelines.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-13 23:24

Message:
Logged In: YES 
user_id=6380

Rejected -- break and continue already have a goto-like
flavor (you can easily write really inscrutable code using
them) and this would just make it worse.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 16:41

Message:
Logged In: YES 
user_id=80475

Guido, I recommend against accepting these forms which are
out of sync with the way the rest of the world uses break,
continue, try, and except.

The proposal is also thin on use cases and does not fit
comfortably with the current implementation.

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

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-21 20:43

Message:
Logged In: YES 
user_id=39274

What you will do to exit from outer of two for's from inside
inner?

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

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

From noreply at sourceforge.net  Sun Mar 14 00:53:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 00:53:24 2004
Subject: [ python-Feature Requests-686323 ] Minor array module enhancements
Message-ID: <E1B2OYn-00079b-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #686323, was opened at 2003-02-13 20:13
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=686323&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 4
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Minor array module enhancements

Initial Comment:
1) I notice that array(&#039;B&#039;, (2,3,4)) throws an error
saying the
2nd arg must be a list or string.  That is, array(&#039;B&#039;,
[2,3,4]) is
legal but using the tuple (2,3,4) is not.  The
limitation doesn&#039;t
seem harmful, but I also don&#039;t see any good reason for
it.  May
as well remove it.

2) Of more usefulness (and maybe of more controversy), I
think the byte array methods should accept string
arguments,
for example
   a = array(&#039;B&#039;, &#039;abc&#039;)
   a.append(&#039;def&#039;)
should do the obvious thing.  That gives a natural way to
build up a string in pieces instead of making a list of
strings
and doing the counterintuitive &#039;&#039;.join(x) maneuver. 
Appending
to byte arrays is the usual way to build up a string in
Java,
if that matters.  So I favor this change too.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-14 00:53

Message:
Logged In: YES 
user_id=80475

Implemented the second request as a form of array.extend().

Given, a=array('c', 'the quick'), you can now write,
a.extend(' brown fox').

See Modules/arraymodule.c 2.95

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-24 05:48

Message:
Logged In: YES 
user_id=80475

Added the first request as
  arraymodule.c 2.88

I'm passing on the second request for now.
Auto-promoting the argument entails attempting
to construct a new array object of the same type
as that being extended.  That is a bit cumbersome
but doable.  It also requires that any array creation
errors be trapped and re-explained the context of
array.extend().

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

Comment By: paul rubin (phr)
Date: 2003-02-13 23:42

Message:
Logged In: YES 
user_id=72053

You're correct, second request should be for extend rather
than append.

That is,

a = array('B', 'abc')
a.extend('def')

should do the obvious thing.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-02-13 23:34

Message:
Logged In: YES 
user_id=80475

The first request is reasonable.

The second is not the natural meaning of append().  In 
python, multiple appends are handled with extend().  The 
array module already provides extend.  So, for the 
example given above, the code is:

>>> a = array('B', 'abc')
>>> a.extend(array('B', 'def'))
>>> a
array('B', [97, 98, 99, 100, 101, 102])

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

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

From noreply at sourceforge.net  Sun Mar 14 01:03:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 01:03:07 2004
Subject: [ python-Feature Requests-721061 ] Add copyrange method to array.
Message-ID: <E1B2OiE-0007qC-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #721061, was opened at 2003-04-14 07:41
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=721061&group_id=5470

Category: Extension Modules
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Neil Hodgson (nyamatongwe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add copyrange method to array.

Initial Comment:
The split buffer data structure commonly used in text 
editors to efficiently manipulate text and data attached 
to that text can be implemented using the Python array 
type with the addition of a way to rapidly copy data 
within arrays. There may be other situations in which 
rapidly copying blocks within an array is useful.

-- Neil Hodgson

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-14 01:03

Message:
Logged In: YES 
user_id=80475

The 'text' class is likely the way to go.

I see your point about the extra object creation.  However,
given that there is currently a way (not a good) to do it,
does the use case warrant the addition of non general
purpose method.  I don't think so; even lists don't have
copyrange().

Am closing this request.  If you change your mind and decide
that this is an essential addition, feel free to re-open it.

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

Comment By: Neil Hodgson (nyamatongwe)
Date: 2004-03-13 17:46

Message:
Logged In: YES 
user_id=12579

If you are asking how the copyrange differs from a sliced
copy like
>>> import array
>>> a = array.array("c", "0123456789")
>>> a
array('c', '0123456789')
>>> a[5:8] = a[0:3]
>>> a
array('c', '0123401289')

   There is an extra object creation and copy for the
temporary slice. I think the actual copy between slices of
the same type is fast. Possibly the original patch was lost
so it can be found at
http://scintilla.sourceforge.net/arraycopyrange.diff
   I didn't chase this much before as it may be better for
me to produce a 'text' class that combines more features
into an efficient mutable document type.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 16:44

Message:
Logged In: YES 
user_id=80475

How does this differ from slice semantics?

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-05-22 02:44

Message:
Logged In: YES 
user_id=80475

Moving to feature requests.

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

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

From noreply at sourceforge.net  Sun Mar 14 01:04:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 01:04:11 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1B2OjE-0007sZ-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Sherborne (matiu)
>Assigned to: Tim Peters (tim_one)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of &#039;dd-mm-yy&#039;

Now in python:
>>> from time import *
>>> print strftime(&#039;%c&#039;, localtime)
02/17/04 09:15:10
>>> print strftime(&#039;%x&#039;, localtime())
02/17/04

This is giving the date in the format &#039;mm-dd-yy&#039;
(American).

Could it be to do with the &#039;locale.nl_langinfo&#039; bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-14 01:04

Message:
Logged In: YES 
user_id=80475

Tim, what do you think?

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 16:50

Message:
Logged In: YES 
user_id=357491

This is a Windows C library bug and nothing to do with our end.  
Since time.strftime is just a wrapper around ISO C's strftime function we 
just pass in the arguments and then pass them back out without fiddling 
with anything.

So unless there is some compiler setting that needs to be set to be more 
locale-sensitive (doubt it, but since I don't have a Windows box I have no 
way of knowing; this is why I am unassigning this from myself) this is 
probably invalid and Microsoft's fault.

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 15:29

Message:
Logged In: YES 
user_id=304464

Sorry, code should be:

>>> from time import *
>>> print strftime('%c', localtime())
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

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

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

From noreply at sourceforge.net  Sun Mar 14 01:18:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 01:19:05 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1B2Oxf-00013r-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Sherborne (matiu)
>Assigned to: Nobody/Anonymous (nobody)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of &#039;dd-mm-yy&#039;

Now in python:
>>> from time import *
>>> print strftime(&#039;%c&#039;, localtime)
02/17/04 09:15:10
>>> print strftime(&#039;%x&#039;, localtime())
02/17/04

This is giving the date in the format &#039;mm-dd-yy&#039;
(American).

Could it be to do with the &#039;locale.nl_langinfo&#039; bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

>Comment By: Tim Peters (tim_one)
Date: 2004-03-14 01:18

Message:
Logged In: YES 
user_id=31435

I think it's a feature that locale-dependent behavior defaults 
to "C" locale, and doesn't change unless you explicitly change 
the locale.

>>> import time, locale
>>> now = time.localtime()
>>> time.strftime("%c", now)
'03/14/04 01:14:52'
>>> locale.setlocale(locale.LC_ALL, "german")
'German_Germany.1252'
>>> time.strftime("%c", now) # that changed what "%c" does
'14.03.04 01:14:52'
>>>

I also think C's locale gimmicks suck (e.g., there's no portable 
set of locale names across platforms), but that's all we've got 
for now.

IOW, this isn't a bug.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-14 01:04

Message:
Logged In: YES 
user_id=80475

Tim, what do you think?

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 16:50

Message:
Logged In: YES 
user_id=357491

This is a Windows C library bug and nothing to do with our end.  
Since time.strftime is just a wrapper around ISO C's strftime function we 
just pass in the arguments and then pass them back out without fiddling 
with anything.

So unless there is some compiler setting that needs to be set to be more 
locale-sensitive (doubt it, but since I don't have a Windows box I have no 
way of knowing; this is why I am unassigning this from myself) this is 
probably invalid and Microsoft's fault.

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 15:29

Message:
Logged In: YES 
user_id=304464

Sorry, code should be:

>>> from time import *
>>> print strftime('%c', localtime())
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

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

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

From noreply at sourceforge.net  Sun Mar 14 04:58:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 04:58:45 2004
Subject: [ python-Bugs-898253 ] strftime ignores date format on winxp
Message-ID: <E1B2SOE-0002jF-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Matthew Sherborne (matiu)
Assigned to: Nobody/Anonymous (nobody)
Summary: strftime ignores date format on winxp

Initial Comment:
On Windows XP in the control panel set your country to
"New Zealand".

This gives a short date format of &#039;dd-mm-yy&#039;

Now in python:
>>> from time import *
>>> print strftime(&#039;%c&#039;, localtime)
02/17/04 09:15:10
>>> print strftime(&#039;%x&#039;, localtime())
02/17/04

This is giving the date in the format &#039;mm-dd-yy&#039;
(American).

Could it be to do with the &#039;locale.nl_langinfo&#039; bieng
unavailable in xp?

Versions:
ActivePython 2.3.2 Build 232 (ActiveState Corp.) based
on Python 2.3.2 (#49, Nov 13 2003, 10:34:54) [MSC
v.1200 32 bit (Intel)] on win32
Windows XP Home Edition (up to dateish)

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

Comment By: Tim Peters (tim_one)
Date: 2004-03-14 01:18

Message:
Logged In: YES 
user_id=31435

I think it's a feature that locale-dependent behavior defaults 
to "C" locale, and doesn't change unless you explicitly change 
the locale.

>>> import time, locale
>>> now = time.localtime()
>>> time.strftime("%c", now)
'03/14/04 01:14:52'
>>> locale.setlocale(locale.LC_ALL, "german")
'German_Germany.1252'
>>> time.strftime("%c", now) # that changed what "%c" does
'14.03.04 01:14:52'
>>>

I also think C's locale gimmicks suck (e.g., there's no portable 
set of locale names across platforms), but that's all we've got 
for now.

IOW, this isn't a bug.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-14 01:04

Message:
Logged In: YES 
user_id=80475

Tim, what do you think?

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

Comment By: Brett Cannon (bcannon)
Date: 2004-02-17 16:50

Message:
Logged In: YES 
user_id=357491

This is a Windows C library bug and nothing to do with our end.  
Since time.strftime is just a wrapper around ISO C's strftime function we 
just pass in the arguments and then pass them back out without fiddling 
with anything.

So unless there is some compiler setting that needs to be set to be more 
locale-sensitive (doubt it, but since I don't have a Windows box I have no 
way of knowing; this is why I am unassigning this from myself) this is 
probably invalid and Microsoft's fault.

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

Comment By: Matthew Sherborne (matiu)
Date: 2004-02-16 15:29

Message:
Logged In: YES 
user_id=304464

Sorry, code should be:

>>> from time import *
>>> print strftime('%c', localtime())
02/17/04 09:15:10
>>> print strftime('%x', localtime())
02/17/04

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

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

From noreply at sourceforge.net  Sun Mar 14 05:22:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 05:23:06 2004
Subject: [ python-Bugs-915942 ] CFStringGetUnicode() returns null-terminated
	unicode string
Message-ID: <E1B2Sln-0004Ig-00@sc8-sf-web1.sourceforge.net>

Bugs item #915942, was opened at 2004-03-14 10:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=915942&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: has (hhas)
Assigned to: Jack Jansen (jackjansen)
Summary: CFStringGetUnicode() returns null-terminated unicode string

Initial Comment:
Carbon.CoreFoundation CFStringGetUnicode() wrapper returns a 
null-terminated unicode string. Example:

#######

#!/usr/local/bin/pythonw

import Carbon.CoreFoundation as CF
from appscript import LaunchServices

path = &#039;TextEdit.app&#039;

fURL = LaunchServices.LSFindApplicationForInfo (&#039;????&#039;, None, 
path)[1]

print [c for c in 
(fURL.CFURLCopyFileSystemPath(CF.kCFURLPOSIXPathStyle).CFSt
ringGetUnicode())]

--> [u&#039;/&#039;, u&#039;A&#039;, u&#039;p&#039;, u&#039;p&#039;, u&#039;l&#039;, u&#039;i&#039;, u&#039;c&#039;, u&#039;a&#039;, u&#039;t&#039;, u&#039;i&#039;, u&#039;o&#039;, u&#039;n&#039;, u&#039;s&#039;, 
u&#039;/&#039;, u&#039;T&#039;, u&#039;e&#039;, u&#039;x&#039;, u&#039;t&#039;, u&#039;E&#039;, u&#039;d&#039;, u&#039;i&#039;, u&#039;t&#039;, u&#039;.&#039;, u&#039;a&#039;, u&#039;p&#039;, u&#039;p&#039;, u&#039;x00&#039;] -- why is last character 0x00???

#######

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

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

From noreply at sourceforge.net  Sun Mar 14 08:29:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 08:29:41 2004
Subject: [ python-Bugs-916013 ] Improving MacPython's IAC support
Message-ID: <E1B2VgO-0000wF-00@sc8-sf-web4.sourceforge.net>

Bugs item #916013, was opened at 2004-03-14 13:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=916013&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: has (hhas)
Assigned to: Jack Jansen (jackjansen)
Summary: Improving MacPython's IAC support

Initial Comment:
While usable, MacPython&#039;s high-level Apple event-based inter-
application communication (IAC) support is not as good as it 
could be. As a first step to overhauling it, I&#039;d like to suggest 
replacing the aepack.py, aetools.py, aetypes.py and 
gensuitemodule.py modules with appscript, a new MacPython-
Apple Event Manager bridge [c/o yrs truly] submitted here for 
your consideration:

http://freespace.virgin.net/hamish.sanderson/appscript.html

(Note: appscript development is ongoing as of 3/14/04. 
Assuming provisional acceptance, some discussion of Things To 
Be Done Before It&#039;s Included will be needed; the MacPython SIG 
might be a good place for this.)

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

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

From noreply at sourceforge.net  Sun Mar 14 12:35:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 15:42:21 2004
Subject: [ python-Bugs-913698 ] smtplib : module bug with unresolved hostname
Message-ID: <E1B2ZWk-00083g-00@sc8-sf-web1.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Zarro (chaica)
Assigned to: Nobody/Anonymous (nobody)
>Summary: smtplib : module bug with unresolved hostname

Initial Comment:
I checked in the last cvs and the bug wasn&#039;t corriged.

if your hostname can&#039;t be resolved, so the module will
panic and raise a socket.gaierror in line 254:

addr = socket.gethostbyname(socket.gethostname())

>>> import socket
>>> socket.gethostname()
&#039;desktop&#039;
>>> socket.gethostbyname(socket.gethostname())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.gaierror: (-2, &#039;Name or service not known&#039;)

To correct, catch the exception and give a generic
value for self.local_hostname, for example localhost
127.0.0.1

try:
    addr = socket.gethostbyname(socket.gethostname())
    self.local_hostname = &#039;[%s]&#039; % addr
except socket.gaierror, msg:
    self.local_hostname = &#039;[%s]&#039; % &#039;127.0.0.1&#039;

Keep me tuned,
chaica@ohmytux.com


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

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

From noreply at sourceforge.net  Sun Mar 14 23:27:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 14 23:27:27 2004
Subject: [ python-Bugs-789290 ] Minor FP bug in object.c
Message-ID: <E1B2jhB-0000Hh-00@sc8-sf-web1.sourceforge.net>

Bugs item #789290, was opened at 2003-08-15 11:15
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor FP bug in object.c

Initial Comment:
This is closely related to the one I have reported
in floatobject.c (789159).  VERY closely.  It is
shown up by the following test on a machine with
64-bit longs and floating-point trapping turned on
(though it might show up as bogus results even with
no trapping):

print int( 9223372036854775200.0)
print int( 9223372036854775800.0)
print int(-9223372036854776800.0)
print int(-9223372036854777000.0)

958,959c958,959
<       double intpart, fractpart;
<       int expo;
---
>       double intpart, fractpart, z;
>       int expo, i, j;
978c978,989
<               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
---
>               /* Remember that (double)LONG_MAX can
round either way. */
>               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
>                       z = 0.0;
>               else {
>                       z = (intpart >= 0.0 ? intpart :
-intpart);
>                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
>                               x = LONG_MAX;
>                               for (j = 0; j < i; ++j)
x >>= 16;
>                               z -=
ldexp(x&0xffff,16*i);
>                       }
>               }
>               if (z > 0.0) {


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

>Comment By: Tim Peters (tim_one)
Date: 2004-03-14 23:27

Message:
Logged In: YES 
user_id=31435

Nick, that helps (thanks!), but I still don't understand the 
connection between your examples and the patch.  The 
patch is indeed to _Py_HashDouble(), but that shouldn't get 
executed when doing, e.g.,

print int(9223372036854775200.0)

Is there a relationship between the examples and the patch, 
or do the examples belong to some other bug report?

Or is another assumption here that you're typing those 
examples in to an interactive Python shell?  *Then* 
_Py_HashDouble() would get called, as part of compilation.

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

Comment By: Nick Maclaren (nmm1)
Date: 2004-03-09 07:20

Message:
Logged In: YES 
user_id=652073

The bug is overflow (i.e. undefined behaviour), and so
the symptoms will vary according to the system.  Under
the conditions I was running, there was no output,
because Python terminated with a SIGFPE.  As I said, it
could as easily show up as erroneous results.

In THIS case, the failure occurs in the input processing,
and the purpose of prefixing it by print and int() is if
you try it on a system where it gives wrong answers.  If
you don't have access to a system where overflow can be
turned on or one that uses unusual arithmetic, you will not
be able to repeat it.  That is why I created a fix.

The reason that I didn't attach is is that attachment was
broken; I don't know why, and have neither the time nor the
inclination to debug a Web interface that I do not manage.
I can trivially send such things by Email, which is far
more reliable.  There doesn't appear to be a mechanism to
try again, so here is a context diff:

*** object.c.org        Wed Feb 19 03:21:21 2003
--- object.c    Fri Aug 15 15:22:50 2003
***************
*** 955,962 ****
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart;
!       int expo;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
--- 955,962 ----
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart, z;
!       int expo, i, j;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
***************
*** 975,981 ****
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))
--- 975,992 ----
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               /* Remember that (double)LONG_MAX can round
either way. */
!               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
!                       z = 0.0;
!               else {
!                       z = (intpart >= 0.0 ? intpart :
-intpart);
!                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
!                               x = LONG_MAX;
!                               for (j = 0; j < i; ++j) x
>>= 16;
!                               z -= ldexp(x&0xffff,16*i);
!                       }
!               }
!               if (z > 0.0) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))


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

Comment By: Tim Peters (tim_one)
Date: 2004-02-16 19:22

Message:
Logged In: YES 
user_id=31435

Sorry, I can't make for this, so unassigned it.

To help the next person,

1. Please say something about what "the bug" is.  You show 4 
lines printing int(big_integer), but don't show any output.  In 
addition, the patch *appears* to be against _Py_HashDouble
(), but that function isn't involved in int() or in printing.

2. Please generate a context diff for patches, and attach the 
patch to the bug report instead of pasting it into the text 
box.  SourceForge destroys the intended line structure and 
indentation in text boxes, and this non-context diff patch is 
very hard to follow in this mangled form.

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

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

From noreply at sourceforge.net  Mon Mar 15 05:22:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 05:22:20 2004
Subject: [ python-Bugs-914148 ] xml.sax segfault on error
Message-ID: <E1B2pEc-0008JZ-00@sc8-sf-web3.sourceforge.net>

Bugs item #914148, was opened at 2004-03-11 06:14
Message generated for change (Comment added) made by moraes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914148&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Sampson (adamsampson)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax segfault on error

Initial Comment:
While (mistakenly) using Mark Pilgrim&#039;s feedparser
module to parse data from
<http://www.gothamist.com/archives/news_nyc/index.php>,
Python segfaults when it should invoke an error handler
for invalid XML. The attached code demonstrates the
problem; it occurs with Python 2.2.3 and 2.3.3 on my
system. I&#039;ve tried to chop the example data down as far
as possible, but reducing it any further doesn&#039;t
exhibit the problem (it&#039;s currently just above 64k,
which might be a coincidence).

The gdb traceback I get from the example is as follows:

#0  normal_updatePosition (enc=0x404a4fc0, 
    ptr=0x40682000 <Address 0x40682000 out of bounds>, 
    end=0x81e87e0 "a></div>\n\n<div
id=\content\>\n\n<div class=\blog\>\n<!--\n<rdf:RDF
xmlns:rdf=\http://www.w3.org/1999/02/22-rdf-syntax-ns#\\n
       
xmlns:trackback=\http://madskills.com/public/xml/rss/module/trackback/\\n"...,
pos=0x81e7dac)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmltok_impl.c:1745
#1  0x40484288 in XML_GetCurrentLineNumber
(parser=0x81e7c18)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmlparse.c:1605
#2  0x40481fc5 in set_error (self=0x0,
code=XML_ERROR_TAG_MISMATCH)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:124
#3  0x40480ae7 in xmlparse_Parse (self=0x402fddac,
args=0x0)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:888
#4  0x080fc25a in PyCFunction_Call (func=0x402faa0c,
arg=0x402f338c, 
    kw=0xfffffffb) at Objects/methodobject.c:108
#5  0x080aa674 in call_function (pp_stack=0xbffff03c,
oparg=0)
    at Python/ceval.c:3439
#6  0x080a8a2e in eval_frame (f=0x816e45c) at
Python/ceval.c:2116
#7  0x080a95bc in PyEval_EvalCodeEx (co=0x40303de0,
globals=0xfffffffb, 
    locals=0x0, args=0x816e5a8, argcount=2,
kws=0x816a9fc, kwcount=0, 
    defs=0x40321678, defcount=1, closure=0x0) at
Python/ceval.c:2663
#8  0x080aa729 in fast_function (func=0xfffffffb,
pp_stack=0xbffff1bc, n=2, 
    na=0, nk=135703028) at Python/ceval.c:3529
#9  0x080aa56c in call_function (pp_stack=0xbffff1bc,
oparg=0)
    at Python/ceval.c:3458
#10 0x080a8a2e in eval_frame (f=0x816a894) at
Python/ceval.c:2116
#11 0x080a95bc in PyEval_EvalCodeEx (co=0x402fd2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x402f3318, argcount=2, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#12 0x080fbda7 in function_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/funcobject.c:504
#13 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#14 0x08062288 in instancemethod_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/classobject.c:2433
#15 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#16 0x080aa892 in do_call (func=0x4032025c,
pp_stack=0x402f330c, na=0, nk=0)
    at Python/ceval.c:3644
#17 0x080aa4f9 in call_function (pp_stack=0xbffff5fc,
oparg=0)
    at Python/ceval.c:3460
#18 0x080a8a2e in eval_frame (f=0x818b414) at
Python/ceval.c:2116
#19 0x080aa7ad in fast_function (func=0xfffffffb,
pp_stack=0xbffff71c, n=2, 
    na=0, nk=1076865996) at Python/ceval.c:3518
#20 0x080aa56c in call_function (pp_stack=0xbffff71c,
oparg=0)
    at Python/ceval.c:3458
#21 0x080a8a2e in eval_frame (f=0x8183814) at
Python/ceval.c:2116
#22 0x080a95bc in PyEval_EvalCodeEx (co=0x402ed2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#23 0x080abdb9 in PyEval_EvalCode (co=0x0, globals=0x0,
locals=0x0)
    at Python/ceval.c:537
#24 0x080d7d2b in run_node (n=0x402bb79c, filename=0x0,
globals=0x0, 
    locals=0x0, flags=0x0) at Python/pythonrun.c:1265
#25 0x080d74df in PyRun_SimpleFileExFlags (fp=0x8139050, 
    filename=0xbffffa4d "testexpat.py",
closeit=-1073743283, flags=0xbffff878)
    at Python/pythonrun.c:862
#26 0x08054dd5 in Py_Main (argc=1, argv=0xbffff8f4) at
Modules/main.c:415
#27 0x0805492b in main (argc=0, argv=0x0) at
Modules/python.c:23


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

Comment By: Mark Moraes (moraes)
Date: 2004-03-15 02:22

Message:
Logged In: YES 
user_id=390363

I ran into this as well -- turns out that 64k is relevant: I
have a simpler script that reproduces this problem -- create
an unterminated character ref such as "&#171" without the
trailing semi-colon and add roughly 64k of data after it. 
The crash occurs if the sax parser has an ErrorHandler set
where the fatalError() method returns normally instead of
terminating/raising the exception.

As a defensive measure, I suggest that any call to the
fatalError method be followed by a raise of the exception if
fatalError returns.


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

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

From noreply at sourceforge.net  Mon Mar 15 05:26:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 05:26:57 2004
Subject: [ python-Bugs-914148 ] xml.sax segfault on error
Message-ID: <E1B2pJ5-0007Pa-00@sc8-sf-web4.sourceforge.net>

Bugs item #914148, was opened at 2004-03-11 06:14
Message generated for change (Comment added) made by moraes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914148&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Sampson (adamsampson)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax segfault on error

Initial Comment:
While (mistakenly) using Mark Pilgrim&#039;s feedparser
module to parse data from
<http://www.gothamist.com/archives/news_nyc/index.php>,
Python segfaults when it should invoke an error handler
for invalid XML. The attached code demonstrates the
problem; it occurs with Python 2.2.3 and 2.3.3 on my
system. I&#039;ve tried to chop the example data down as far
as possible, but reducing it any further doesn&#039;t
exhibit the problem (it&#039;s currently just above 64k,
which might be a coincidence).

The gdb traceback I get from the example is as follows:

#0  normal_updatePosition (enc=0x404a4fc0, 
    ptr=0x40682000 <Address 0x40682000 out of bounds>, 
    end=0x81e87e0 "a></div>\n\n<div
id=\content\>\n\n<div class=\blog\>\n<!--\n<rdf:RDF
xmlns:rdf=\http://www.w3.org/1999/02/22-rdf-syntax-ns#\\n
       
xmlns:trackback=\http://madskills.com/public/xml/rss/module/trackback/\\n"...,
pos=0x81e7dac)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmltok_impl.c:1745
#1  0x40484288 in XML_GetCurrentLineNumber
(parser=0x81e7c18)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmlparse.c:1605
#2  0x40481fc5 in set_error (self=0x0,
code=XML_ERROR_TAG_MISMATCH)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:124
#3  0x40480ae7 in xmlparse_Parse (self=0x402fddac,
args=0x0)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:888
#4  0x080fc25a in PyCFunction_Call (func=0x402faa0c,
arg=0x402f338c, 
    kw=0xfffffffb) at Objects/methodobject.c:108
#5  0x080aa674 in call_function (pp_stack=0xbffff03c,
oparg=0)
    at Python/ceval.c:3439
#6  0x080a8a2e in eval_frame (f=0x816e45c) at
Python/ceval.c:2116
#7  0x080a95bc in PyEval_EvalCodeEx (co=0x40303de0,
globals=0xfffffffb, 
    locals=0x0, args=0x816e5a8, argcount=2,
kws=0x816a9fc, kwcount=0, 
    defs=0x40321678, defcount=1, closure=0x0) at
Python/ceval.c:2663
#8  0x080aa729 in fast_function (func=0xfffffffb,
pp_stack=0xbffff1bc, n=2, 
    na=0, nk=135703028) at Python/ceval.c:3529
#9  0x080aa56c in call_function (pp_stack=0xbffff1bc,
oparg=0)
    at Python/ceval.c:3458
#10 0x080a8a2e in eval_frame (f=0x816a894) at
Python/ceval.c:2116
#11 0x080a95bc in PyEval_EvalCodeEx (co=0x402fd2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x402f3318, argcount=2, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#12 0x080fbda7 in function_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/funcobject.c:504
#13 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#14 0x08062288 in instancemethod_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/classobject.c:2433
#15 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#16 0x080aa892 in do_call (func=0x4032025c,
pp_stack=0x402f330c, na=0, nk=0)
    at Python/ceval.c:3644
#17 0x080aa4f9 in call_function (pp_stack=0xbffff5fc,
oparg=0)
    at Python/ceval.c:3460
#18 0x080a8a2e in eval_frame (f=0x818b414) at
Python/ceval.c:2116
#19 0x080aa7ad in fast_function (func=0xfffffffb,
pp_stack=0xbffff71c, n=2, 
    na=0, nk=1076865996) at Python/ceval.c:3518
#20 0x080aa56c in call_function (pp_stack=0xbffff71c,
oparg=0)
    at Python/ceval.c:3458
#21 0x080a8a2e in eval_frame (f=0x8183814) at
Python/ceval.c:2116
#22 0x080a95bc in PyEval_EvalCodeEx (co=0x402ed2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#23 0x080abdb9 in PyEval_EvalCode (co=0x0, globals=0x0,
locals=0x0)
    at Python/ceval.c:537
#24 0x080d7d2b in run_node (n=0x402bb79c, filename=0x0,
globals=0x0, 
    locals=0x0, flags=0x0) at Python/pythonrun.c:1265
#25 0x080d74df in PyRun_SimpleFileExFlags (fp=0x8139050, 
    filename=0xbffffa4d "testexpat.py",
closeit=-1073743283, flags=0xbffff878)
    at Python/pythonrun.c:862
#26 0x08054dd5 in Py_Main (argc=1, argv=0xbffff8f4) at
Modules/main.c:415
#27 0x0805492b in main (argc=0, argv=0x0) at
Modules/python.c:23


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

Comment By: Mark Moraes (moraes)
Date: 2004-03-15 02:26

Message:
Logged In: YES 
user_id=390363

#! /usr/bin/env python

dhead = """<?xml version="1.0" encoding="ISO-8859-1" ?>
<item><title>&#187</title></item>
<item><title>
"""
dtail = """</title></item>
"""

import xml.sax
from cStringIO import StringIO as _StringIO

class _StrictFeedParser:
    def _err(self, errtype, exc):
        print errtype, exc.getMessage(),             'line', exc.getLineNumber(),             'column', exc.getColumnNumber()
    def fatalError(self, exc):
        self._err('fatalError', exc)
        # raise exc # avoids the problem
    def error(self, exc):
        self._err('error', exc)
    def warning(self, exc):
        self._err('warning', exc)

def parse(data):
    feedparser = _StrictFeedParser()
    saxparser = xml.sax.make_parser(["drv_libxml2"])
    saxparser.setErrorHandler(feedparser)
    source = xml.sax.xmlreader.InputSource()
    source.setByteStream(_StringIO(data))
    saxparser.parse(source)

if __name__ == '__main__':
    for i in xrange(65427,66000,1):
        print i
        parse(dhead + 'x'*i + dtail)

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

Comment By: Mark Moraes (moraes)
Date: 2004-03-15 02:22

Message:
Logged In: YES 
user_id=390363

I ran into this as well -- turns out that 64k is relevant: I
have a simpler script that reproduces this problem -- create
an unterminated character ref such as "&#171" without the
trailing semi-colon and add roughly 64k of data after it. 
The crash occurs if the sax parser has an ErrorHandler set
where the fatalError() method returns normally instead of
terminating/raising the exception.

As a defensive measure, I suggest that any call to the
fatalError method be followed by a raise of the exception if
fatalError returns.


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

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

From noreply at sourceforge.net  Mon Mar 15 06:48:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 06:48:32 2004
Subject: [ python-Feature Requests-668905 ] logging module documentation
Message-ID: <E1B2qZu-0006Rk-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #668905, was opened at 2003-01-16 05:07
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module documentation

Initial Comment:
I believe the logging module documentation needs to give an 
example of how to simply log to a file. The following example snippet 
could be appropriate: 
 
import logging 
logger = logging.getLogger(&#039;myapp&#039;) 
hdlr = FileHandler(&#039;/var/myapp/debug.log&#039;) 
hdlr.setFormatter(Formatter(&#039;%(asctime)s %(level)s %(message)s&#039;)) 
logger.addHandler(hdlr) 
logger.setLevel(DEBUG) 
 
 

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

>Comment By: Vinay Sajip (vsajip)
Date: 2004-03-15 11:48

Message:
Logged In: YES 
user_id=308438

How about if I modify basicConfig as follows?

def basicConfig(filename=None, fmtstr=None, mode="w"):
    """
    Do basic configuration for the logging system.

    If a filename is specified, create a FileHandler using it, 
otherwise
    create a StreamHandler. The created handler is added to 
the root logger.
    If a format string is specified, it will be used to initialize
    the Formatter - otherwise, a suitable default will be used.
    The mode is only used when a filename is specified, to 
determine how the
    file is to be opened.
    """
    if len(root.handlers) == 0:
        if filename:
            hdlr = FileHandler(filename, mode)
        else:
            hdlr = StreamHandler()
        if not fmtstr:
            fmtstr = BASIC_FORMAT
        fmt = Formatter(fs)
        hdlr.setFormatter(fmt)
        root.addHandler(hdlr)


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

Comment By: Richard Jones (richard)
Date: 2004-03-09 21:21

Message:
Logged In: YES 
user_id=6405

Please consider adding a simpler interface for people who just 
want to log to a file: 
 
  import logging 
  logger = logging.open('/var/log/myapp.log') 
 
which does the equivalent of: 
 
  import logging 
  logger = logging.getLogger('<default>') 
  hdlr = logging.FileHandler('/var/log/myapp.log') 
  formatter = logging.Formatter('%(asctime)s %(levelname)s 
%(message)s') 
  hdlr.setFormatter(formatter) 
  logger.addHandler(hdlr) 
  logger.setLevel(logging.INFO) 
 
which is what I expect most users will want when they first 
see this module. If they then want to mess around with 
additional handers, or different formatting or whatever, then 
they can read the reference doc. 
 
Please make the simplest use-case much simpler! 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-01 07:10

Message:
Logged In: YES 
user_id=80475

I would also like to see a more thorough set of introductory
examples.  The second page of the unittest documentation
could serve as a model -- it attempts to cover the 90% of
what you need to know in a single page of examples.   As it
stands now, the documentation for the logging module is
formidable.  Those wanting to take advantage of the module
face a steep learning curve from rather heavyweight
documentation -- it's complexity exceeds that of almost all
modules except for the email and xml packages.

Assigning to Vinay Sajip to work with Anthony to improve the
docs.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-07-08 06:32

Message:
Logged In: YES 
user_id=29957

Why was this closed? nnorwitz's doc fixes, as seen in CVS or 
http://www.python.org/dev/doc/devel/lib/module-logging.html
have no examples section.  

Running the current logging module docs past a number of 
python coders here produced a consistent "what the heck?"
response - the opening introduction provides no indications of
how to use the package. 
This is a problem for me, right now, so I'm re-opening and
assigning to myself to fix.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 06:37

Message:
Logged In: YES 
user_id=80475

Reviewed.
Closing RFE.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-25 21:36

Message:
Logged In: YES 
user_id=33168

I just updated the logging documentation.  Could you please
review for accuracy and completeness?

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

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

From noreply at sourceforge.net  Mon Mar 15 08:19:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 08:19:26 2004
Subject: [ python-Feature Requests-668905 ] logging module documentation
Message-ID: <E1B2rzr-0004ys-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #668905, was opened at 2003-01-15 20:07
Message generated for change (Comment added) made by drewp
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module documentation

Initial Comment:
I believe the logging module documentation needs to give an 
example of how to simply log to a file. The following example snippet 
could be appropriate: 
 
import logging 
logger = logging.getLogger(&#039;myapp&#039;) 
hdlr = FileHandler(&#039;/var/myapp/debug.log&#039;) 
hdlr.setFormatter(Formatter(&#039;%(asctime)s %(level)s %(message)s&#039;)) 
logger.addHandler(hdlr) 
logger.setLevel(DEBUG) 
 
 

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

Comment By: Drew Perttula (drewp)
Date: 2004-03-15 04:19

Message:
Logged In: YES 
user_id=127598

ITYM "if filename is not None" , "if fmtstr is None", and
"Formatter(fmtstr)". I like the feature a lot, otherwise.

For the record, the next most common things I do to a logger
is to adjust its root's level to DEBUG but set the level of
the channels I -don't- want to see back to INFO. (Therefore,
any new channels will get output as DEBUG until I put them
in the exclusion list.) I doubt this belongs in basicConfig,
but if there became a convenience method to do it, I'd sure
use it :)


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

Comment By: Vinay Sajip (vsajip)
Date: 2004-03-15 02:48

Message:
Logged In: YES 
user_id=308438

How about if I modify basicConfig as follows?

def basicConfig(filename=None, fmtstr=None, mode="w"):
    """
    Do basic configuration for the logging system.

    If a filename is specified, create a FileHandler using it, 
otherwise
    create a StreamHandler. The created handler is added to 
the root logger.
    If a format string is specified, it will be used to initialize
    the Formatter - otherwise, a suitable default will be used.
    The mode is only used when a filename is specified, to 
determine how the
    file is to be opened.
    """
    if len(root.handlers) == 0:
        if filename:
            hdlr = FileHandler(filename, mode)
        else:
            hdlr = StreamHandler()
        if not fmtstr:
            fmtstr = BASIC_FORMAT
        fmt = Formatter(fs)
        hdlr.setFormatter(fmt)
        root.addHandler(hdlr)


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

Comment By: Richard Jones (richard)
Date: 2004-03-09 12:21

Message:
Logged In: YES 
user_id=6405

Please consider adding a simpler interface for people who just 
want to log to a file: 
 
  import logging 
  logger = logging.open('/var/log/myapp.log') 
 
which does the equivalent of: 
 
  import logging 
  logger = logging.getLogger('<default>') 
  hdlr = logging.FileHandler('/var/log/myapp.log') 
  formatter = logging.Formatter('%(asctime)s %(levelname)s 
%(message)s') 
  hdlr.setFormatter(formatter) 
  logger.addHandler(hdlr) 
  logger.setLevel(logging.INFO) 
 
which is what I expect most users will want when they first 
see this module. If they then want to mess around with 
additional handers, or different formatting or whatever, then 
they can read the reference doc. 
 
Please make the simplest use-case much simpler! 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-12-31 22:10

Message:
Logged In: YES 
user_id=80475

I would also like to see a more thorough set of introductory
examples.  The second page of the unittest documentation
could serve as a model -- it attempts to cover the 90% of
what you need to know in a single page of examples.   As it
stands now, the documentation for the logging module is
formidable.  Those wanting to take advantage of the module
face a steep learning curve from rather heavyweight
documentation -- it's complexity exceeds that of almost all
modules except for the email and xml packages.

Assigning to Vinay Sajip to work with Anthony to improve the
docs.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-07-07 22:32

Message:
Logged In: YES 
user_id=29957

Why was this closed? nnorwitz's doc fixes, as seen in CVS or 
http://www.python.org/dev/doc/devel/lib/module-logging.html
have no examples section.  

Running the current logging module docs past a number of 
python coders here produced a consistent "what the heck?"
response - the opening introduction provides no indications of
how to use the package. 
This is a problem for me, right now, so I'm re-opening and
assigning to myself to fix.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-27 22:37

Message:
Logged In: YES 
user_id=80475

Reviewed.
Closing RFE.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-25 12:36

Message:
Logged In: YES 
user_id=33168

I just updated the logging documentation.  Could you please
review for accuracy and completeness?

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

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

From noreply at sourceforge.net  Mon Mar 15 09:47:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 12:03:53 2004
Subject: [ python-Feature Requests-668905 ] logging module documentation
Message-ID: <E1B2tNh-0005ac-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #668905, was opened at 2003-01-16 05:07
Message generated for change (Comment added) made by vsajip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module documentation

Initial Comment:
I believe the logging module documentation needs to give an 
example of how to simply log to a file. The following example snippet 
could be appropriate: 
 
import logging 
logger = logging.getLogger(&#039;myapp&#039;) 
hdlr = FileHandler(&#039;/var/myapp/debug.log&#039;) 
hdlr.setFormatter(Formatter(&#039;%(asctime)s %(level)s %(message)s&#039;)) 
logger.addHandler(hdlr) 
logger.setLevel(DEBUG) 
 
 

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

>Comment By: Vinay Sajip (vsajip)
Date: 2004-03-15 14:47

Message:
Logged In: YES 
user_id=308438

I assume no one would pass an empty for filename or fmtstr, 
as this would make no sense. So I test for both None and the 
empty string at the same time using the "if value:" idiom. I 
have tried to be consistent with the view that wherever 
possible, logging should not generate spurious output (e.g. 
throwing exceptions), even when errors occur.


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

Comment By: Drew Perttula (drewp)
Date: 2004-03-15 13:19

Message:
Logged In: YES 
user_id=127598

ITYM "if filename is not None" , "if fmtstr is None", and
"Formatter(fmtstr)". I like the feature a lot, otherwise.

For the record, the next most common things I do to a logger
is to adjust its root's level to DEBUG but set the level of
the channels I -don't- want to see back to INFO. (Therefore,
any new channels will get output as DEBUG until I put them
in the exclusion list.) I doubt this belongs in basicConfig,
but if there became a convenience method to do it, I'd sure
use it :)


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

Comment By: Vinay Sajip (vsajip)
Date: 2004-03-15 11:48

Message:
Logged In: YES 
user_id=308438

How about if I modify basicConfig as follows?

def basicConfig(filename=None, fmtstr=None, mode="w"):
    """
    Do basic configuration for the logging system.

    If a filename is specified, create a FileHandler using it, 
otherwise
    create a StreamHandler. The created handler is added to 
the root logger.
    If a format string is specified, it will be used to initialize
    the Formatter - otherwise, a suitable default will be used.
    The mode is only used when a filename is specified, to 
determine how the
    file is to be opened.
    """
    if len(root.handlers) == 0:
        if filename:
            hdlr = FileHandler(filename, mode)
        else:
            hdlr = StreamHandler()
        if not fmtstr:
            fmtstr = BASIC_FORMAT
        fmt = Formatter(fs)
        hdlr.setFormatter(fmt)
        root.addHandler(hdlr)


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

Comment By: Richard Jones (richard)
Date: 2004-03-09 21:21

Message:
Logged In: YES 
user_id=6405

Please consider adding a simpler interface for people who just 
want to log to a file: 
 
  import logging 
  logger = logging.open('/var/log/myapp.log') 
 
which does the equivalent of: 
 
  import logging 
  logger = logging.getLogger('<default>') 
  hdlr = logging.FileHandler('/var/log/myapp.log') 
  formatter = logging.Formatter('%(asctime)s %(levelname)s 
%(message)s') 
  hdlr.setFormatter(formatter) 
  logger.addHandler(hdlr) 
  logger.setLevel(logging.INFO) 
 
which is what I expect most users will want when they first 
see this module. If they then want to mess around with 
additional handers, or different formatting or whatever, then 
they can read the reference doc. 
 
Please make the simplest use-case much simpler! 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-01 07:10

Message:
Logged In: YES 
user_id=80475

I would also like to see a more thorough set of introductory
examples.  The second page of the unittest documentation
could serve as a model -- it attempts to cover the 90% of
what you need to know in a single page of examples.   As it
stands now, the documentation for the logging module is
formidable.  Those wanting to take advantage of the module
face a steep learning curve from rather heavyweight
documentation -- it's complexity exceeds that of almost all
modules except for the email and xml packages.

Assigning to Vinay Sajip to work with Anthony to improve the
docs.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-07-08 06:32

Message:
Logged In: YES 
user_id=29957

Why was this closed? nnorwitz's doc fixes, as seen in CVS or 
http://www.python.org/dev/doc/devel/lib/module-logging.html
have no examples section.  

Running the current logging module docs past a number of 
python coders here produced a consistent "what the heck?"
response - the opening introduction provides no indications of
how to use the package. 
This is a problem for me, right now, so I'm re-opening and
assigning to myself to fix.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 06:37

Message:
Logged In: YES 
user_id=80475

Reviewed.
Closing RFE.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-25 21:36

Message:
Logged In: YES 
user_id=33168

I just updated the logging documentation.  Could you please
review for accuracy and completeness?

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

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

From noreply at sourceforge.net  Mon Mar 15 09:54:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 12:24:31 2004
Subject: [ python-Bugs-913698 ] smtplib : module bug with unresolved hostname
Message-ID: <E1B2tUC-0003lG-00@sc8-sf-web2.sourceforge.net>

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

Category: Extension Modules
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Zarro (chaica)
Assigned to: Nobody/Anonymous (nobody)
Summary: smtplib : module bug with unresolved hostname

Initial Comment:
I checked in the last cvs and the bug wasn&#039;t corriged.

if your hostname can&#039;t be resolved, so the module will
panic and raise a socket.gaierror in line 254:

addr = socket.gethostbyname(socket.gethostname())

>>> import socket
>>> socket.gethostname()
&#039;desktop&#039;
>>> socket.gethostbyname(socket.gethostname())
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.gaierror: (-2, &#039;Name or service not known&#039;)

To correct, catch the exception and give a generic
value for self.local_hostname, for example localhost
127.0.0.1

try:
    addr = socket.gethostbyname(socket.gethostname())
    self.local_hostname = &#039;[%s]&#039; % addr
except socket.gaierror, msg:
    self.local_hostname = &#039;[%s]&#039; % &#039;127.0.0.1&#039;

Keep me tuned,
chaica@ohmytux.com


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

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

From noreply at sourceforge.net  Mon Mar 15 13:24:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 13:24:40 2004
Subject: [ python-Bugs-789290 ] Minor FP bug in object.c
Message-ID: <E1B2wlO-0008KW-00@sc8-sf-web3.sourceforge.net>

Bugs item #789290, was opened at 2003-08-15 15:15
Message generated for change (Comment added) made by nmm1
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789290&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Minor FP bug in object.c

Initial Comment:
This is closely related to the one I have reported
in floatobject.c (789159).  VERY closely.  It is
shown up by the following test on a machine with
64-bit longs and floating-point trapping turned on
(though it might show up as bogus results even with
no trapping):

print int( 9223372036854775200.0)
print int( 9223372036854775800.0)
print int(-9223372036854776800.0)
print int(-9223372036854777000.0)

958,959c958,959
<       double intpart, fractpart;
<       int expo;
---
>       double intpart, fractpart, z;
>       int expo, i, j;
978c978,989
<               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
---
>               /* Remember that (double)LONG_MAX can
round either way. */
>               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
>                       z = 0.0;
>               else {
>                       z = (intpart >= 0.0 ? intpart :
-intpart);
>                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
>                               x = LONG_MAX;
>                               for (j = 0; j < i; ++j)
x >>= 16;
>                               z -=
ldexp(x&0xffff,16*i);
>                       }
>               }
>               if (z > 0.0) {


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

>Comment By: Nick Maclaren (nmm1)
Date: 2004-03-15 18:24

Message:
Logged In: YES 
user_id=652073

I think that we are at cross-purposes.  Yes, THIS bug occurs
at compilation time, though it makes no difference whether
Python is being used interactively or as a script.  The
overflow occurs during the conversion of the strings to the
doubles.  The examples show it quite clearly if you run
it with overflow trapping set to SIGFPE, which can be done
under Solaris as well as other systems.  I can deduce the
properties of systems that would give wrong answers, but
don't know of any that actually exist.


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

Comment By: Tim Peters (tim_one)
Date: 2004-03-15 04:27

Message:
Logged In: YES 
user_id=31435

Nick, that helps (thanks!), but I still don't understand the 
connection between your examples and the patch.  The 
patch is indeed to _Py_HashDouble(), but that shouldn't get 
executed when doing, e.g.,

print int(9223372036854775200.0)

Is there a relationship between the examples and the patch, 
or do the examples belong to some other bug report?

Or is another assumption here that you're typing those 
examples in to an interactive Python shell?  *Then* 
_Py_HashDouble() would get called, as part of compilation.

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

Comment By: Nick Maclaren (nmm1)
Date: 2004-03-09 12:20

Message:
Logged In: YES 
user_id=652073

The bug is overflow (i.e. undefined behaviour), and so
the symptoms will vary according to the system.  Under
the conditions I was running, there was no output,
because Python terminated with a SIGFPE.  As I said, it
could as easily show up as erroneous results.

In THIS case, the failure occurs in the input processing,
and the purpose of prefixing it by print and int() is if
you try it on a system where it gives wrong answers.  If
you don't have access to a system where overflow can be
turned on or one that uses unusual arithmetic, you will not
be able to repeat it.  That is why I created a fix.

The reason that I didn't attach is is that attachment was
broken; I don't know why, and have neither the time nor the
inclination to debug a Web interface that I do not manage.
I can trivially send such things by Email, which is far
more reliable.  There doesn't appear to be a mechanism to
try again, so here is a context diff:

*** object.c.org        Wed Feb 19 03:21:21 2003
--- object.c    Fri Aug 15 15:22:50 2003
***************
*** 955,962 ****
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart;
!       int expo;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
--- 955,962 ----
  long
  _Py_HashDouble(double v)
  {
!       double intpart, fractpart, z;
!       int expo, i, j;
        long hipart;
        long x;         /* the final hash value */
        /* This is designed so that Python numbers of
different types
***************
*** 975,981 ****
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               if (intpart > LONG_MAX || -intpart >
LONG_MAX) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))
--- 975,992 ----
  #endif
        if (fractpart == 0.0) {
                /* This must return the same hash as an
equal int or long. */
!               /* Remember that (double)LONG_MAX can round
either way. */
!               if (intpart > LONG_MIN/2 && intpart <
LONG_MAX/2)
!                       z = 0.0;
!               else {
!                       z = (intpart >= 0.0 ? intpart :
-intpart);
!                       for (i =
(sizeof(long)*CHAR_BIT-1)/16; i >= 0; --i) {
!                               x = LONG_MAX;
!                               for (j = 0; j < i; ++j) x
>>= 16;
!                               z -= ldexp(x&0xffff,16*i);
!                       }
!               }
!               if (z > 0.0) {
                        /* Convert to long and use its hash.
*/
                        PyObject *plong;        /* converted
to Python long */
                        if (Py_IS_INFINITY(intpart))


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

Comment By: Tim Peters (tim_one)
Date: 2004-02-17 00:22

Message:
Logged In: YES 
user_id=31435

Sorry, I can't make for this, so unassigned it.

To help the next person,

1. Please say something about what "the bug" is.  You show 4 
lines printing int(big_integer), but don't show any output.  In 
addition, the patch *appears* to be against _Py_HashDouble
(), but that function isn't involved in int() or in printing.

2. Please generate a context diff for patches, and attach the 
patch to the bug report instead of pasting it into the text 
box.  SourceForge destroys the intended line structure and 
indentation in text boxes, and this non-context diff patch is 
very hard to follow in this mangled form.

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

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

From noreply at sourceforge.net  Mon Mar 15 15:54:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 15:54:25 2004
Subject: [ python-Bugs-857297 ] Tarfile and hard-links
Message-ID: <E1B2z6I-0003lq-00@sc8-sf-web3.sourceforge.net>

Bugs item #857297, was opened at 2003-12-10 03:22
Message generated for change (Comment added) made by gustaebel
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=857297&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ricardo Martins (aggression)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tarfile and hard-links

Initial Comment:
The attachment has a tar.gz file which contains a file
and an hard-link to that file. The Python script
unpacks the tar file to 3 locations: the current
directory, the current directory specified by absolute
path and /tmp). In the machines I&#039;ve tested it, when
unpacking to /tmp (or any other directory that does not
belongs to the same branch as the current) the
hard-link is not created. Am I missing something ?

I have tested it with the tarfile module that ships
with Python 2.3.2, and with the CVS tarfile module, the
behavior is the same.

Regards
Ricardo Martins

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

Comment By: Lars Gust?bel (gustaebel)
Date: 2004-03-15 21:54

Message:
Logged In: YES 
user_id=642936

I submitted a patch (#916874) that fixes this.

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

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

From noreply at sourceforge.net  Mon Mar 15 21:46:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 21:47:02 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B34ba-0002ur-00@sc8-sf-web3.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

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

From noreply at sourceforge.net  Mon Mar 15 23:04:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 15 23:04:41 2004
Subject: [ python-Feature Requests-668905 ] logging module documentation
Message-ID: <E1B35oR-0007LR-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #668905, was opened at 2003-01-16 16:07
Message generated for change (Comment added) made by richard
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=668905&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Richard Jones (richard)
Assigned to: Vinay Sajip (vsajip)
Summary: logging module documentation

Initial Comment:
I believe the logging module documentation needs to give an 
example of how to simply log to a file. The following example snippet 
could be appropriate: 
 
import logging 
logger = logging.getLogger(&#039;myapp&#039;) 
hdlr = FileHandler(&#039;/var/myapp/debug.log&#039;) 
hdlr.setFormatter(Formatter(&#039;%(asctime)s %(level)s %(message)s&#039;)) 
logger.addHandler(hdlr) 
logger.setLevel(DEBUG) 
 
 

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

>Comment By: Richard Jones (richard)
Date: 2004-03-16 15:04

Message:
Logged In: YES 
user_id=6405

Accepting any file-like object, as the Twisted logging API does, 
would be nice. I wouldn't object to having to write 
"basicConfig(file('path/to/file'))" 
 
Thanks for looking into this Vinay! 

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

Comment By: Vinay Sajip (vsajip)
Date: 2004-03-16 01:47

Message:
Logged In: YES 
user_id=308438

I assume no one would pass an empty for filename or fmtstr, 
as this would make no sense. So I test for both None and the 
empty string at the same time using the "if value:" idiom. I 
have tried to be consistent with the view that wherever 
possible, logging should not generate spurious output (e.g. 
throwing exceptions), even when errors occur.


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

Comment By: Drew Perttula (drewp)
Date: 2004-03-16 00:19

Message:
Logged In: YES 
user_id=127598

ITYM "if filename is not None" , "if fmtstr is None", and
"Formatter(fmtstr)". I like the feature a lot, otherwise.

For the record, the next most common things I do to a logger
is to adjust its root's level to DEBUG but set the level of
the channels I -don't- want to see back to INFO. (Therefore,
any new channels will get output as DEBUG until I put them
in the exclusion list.) I doubt this belongs in basicConfig,
but if there became a convenience method to do it, I'd sure
use it :)


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

Comment By: Vinay Sajip (vsajip)
Date: 2004-03-15 22:48

Message:
Logged In: YES 
user_id=308438

How about if I modify basicConfig as follows?

def basicConfig(filename=None, fmtstr=None, mode="w"):
    """
    Do basic configuration for the logging system.

    If a filename is specified, create a FileHandler using it, 
otherwise
    create a StreamHandler. The created handler is added to 
the root logger.
    If a format string is specified, it will be used to initialize
    the Formatter - otherwise, a suitable default will be used.
    The mode is only used when a filename is specified, to 
determine how the
    file is to be opened.
    """
    if len(root.handlers) == 0:
        if filename:
            hdlr = FileHandler(filename, mode)
        else:
            hdlr = StreamHandler()
        if not fmtstr:
            fmtstr = BASIC_FORMAT
        fmt = Formatter(fs)
        hdlr.setFormatter(fmt)
        root.addHandler(hdlr)


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

Comment By: Richard Jones (richard)
Date: 2004-03-10 08:21

Message:
Logged In: YES 
user_id=6405

Please consider adding a simpler interface for people who just 
want to log to a file: 
 
  import logging 
  logger = logging.open('/var/log/myapp.log') 
 
which does the equivalent of: 
 
  import logging 
  logger = logging.getLogger('<default>') 
  hdlr = logging.FileHandler('/var/log/myapp.log') 
  formatter = logging.Formatter('%(asctime)s %(levelname)s 
%(message)s') 
  hdlr.setFormatter(formatter) 
  logger.addHandler(hdlr) 
  logger.setLevel(logging.INFO) 
 
which is what I expect most users will want when they first 
see this module. If they then want to mess around with 
additional handers, or different formatting or whatever, then 
they can read the reference doc. 
 
Please make the simplest use-case much simpler! 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-01-01 18:10

Message:
Logged In: YES 
user_id=80475

I would also like to see a more thorough set of introductory
examples.  The second page of the unittest documentation
could serve as a model -- it attempts to cover the 90% of
what you need to know in a single page of examples.   As it
stands now, the documentation for the logging module is
formidable.  Those wanting to take advantage of the module
face a steep learning curve from rather heavyweight
documentation -- it's complexity exceeds that of almost all
modules except for the email and xml packages.

Assigning to Vinay Sajip to work with Anthony to improve the
docs.

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

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-07-08 16:32

Message:
Logged In: YES 
user_id=29957

Why was this closed? nnorwitz's doc fixes, as seen in CVS or 
http://www.python.org/dev/doc/devel/lib/module-logging.html
have no examples section.  

Running the current logging module docs past a number of 
python coders here produced a consistent "what the heck?"
response - the opening introduction provides no indications of
how to use the package. 
This is a problem for me, right now, so I'm re-opening and
assigning to myself to fix.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-06-28 16:37

Message:
Logged In: YES 
user_id=80475

Reviewed.
Closing RFE.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-26 08:36

Message:
Logged In: YES 
user_id=33168

I just updated the logging documentation.  Could you please
review for accuracy and completeness?

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

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

From noreply at sourceforge.net  Tue Mar 16 00:51:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 00:51:48 2004
Subject: [ python-Feature Requests-904770 ] http://doc.python.org
Message-ID: <E1B37UM-0004fu-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #904770, was opened at 2004-02-25 18:55
Message generated for change (Settings changed) made by aahz
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=904770&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Skip Montanaro (montanaro)
Summary: http://doc.python.org

Initial Comment:
If http://python.org/doc/ were mirrored at http://doc.python.org/ it 
would be much easier to search, especially via google.

f.ex. "datetime site:doc.python.org"

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 13:42

Message:
Logged In: YES 
user_id=80475

This use case seems pluasable enough to warrant
consideration.  Aahz, what do you think?

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

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

From noreply at sourceforge.net  Tue Mar 16 00:59:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 00:59:48 2004
Subject: [ python-Bugs-917108 ] warnings.py does not define _test()
Message-ID: <E1B37c9-00057L-00@sc8-sf-web3.sourceforge.net>

Bugs item #917108, was opened at 2004-03-15 21:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917108&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Aahz (aahz)
Assigned to: Nobody/Anonymous (nobody)
Summary: warnings.py does not define _test()

Initial Comment:
At the bottom of warnings.py, there&#039;s a call to _test() if run as a
script.  However, _test() is neither defined nor imported.


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

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

From noreply at sourceforge.net  Tue Mar 16 01:03:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 01:04:04 2004
Subject: [ python-Feature Requests-904770 ] http://doc.python.org
Message-ID: <E1B37g9-00037y-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #904770, was opened at 2004-02-25 21:55
Message generated for change (Comment added) made by bwarsaw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=904770&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
>Assigned to: Thomas Wouters (twouters)
Summary: http://doc.python.org

Initial Comment:
If http://python.org/doc/ were mirrored at http://doc.python.org/ it 
would be much easier to search, especially via google.

f.ex. "datetime site:doc.python.org"

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

>Comment By: Barry A. Warsaw (bwarsaw)
Date: 2004-03-16 01:03

Message:
Logged In: YES 
user_id=12800

+1

I believe Thomas Wouters has effective control over DNS now,
so if he adds the host I'll set up Apache.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-13 16:42

Message:
Logged In: YES 
user_id=80475

This use case seems pluasable enough to warrant
consideration.  Aahz, what do you think?

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

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

From noreply at sourceforge.net  Tue Mar 16 01:36:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 01:37:02 2004
Subject: [ python-Bugs-917120 ] imaplib: incorrect quoting in commands
Message-ID: <E1B38CA-0007Rd-00@sc8-sf-web3.sourceforge.net>

Bugs item #917120, was opened at 2004-03-16 19:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917120&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib: incorrect quoting in commands

Initial Comment:
imaplib incorrectly chooses to quote some arguments.

In particular, doing "UID FETCH # BODY.PEEK[]" results
in the BODY.PEEK[] being quoted, and it should not
(according to the RFC), which means the command fails.
 This is demonstrated below.  It&#039;s possible (and
likely) that other UID FETCH arguments are incorrectly
quoted.

This occurs with anon cvs python of 16/3/04, and 2.3.3.
 Windows XP SP1.

I&#039;m happy to provide more info if required, just let me
know.  I could try and work up a patch, but it would be
better from someone really familiar with imaplib so
that I don&#039;t screw up legitimate quoting.

>>> import imaplib
>>> i = imaplib.IMAP4("server")
>>> i.login("username", "password")
(&#039;OK&#039;, [&#039;LOGIN Ok.&#039;])
>>> i.select()
(&#039;OK&#039;, [&#039;38&#039;])
>>> i.debug = 4
>>> i.uid("FETCH", "96", "BODY")
  29:14.23 > GKGP7 UID FETCH 96 BODY
  29:14.40 < * 31 FETCH (UID 96 BODY (("text" "plain"
("charset" "iso-8859-1") NIL NIL "quoted-printable" 32
0)("text" "html" ("charset" "iso-8859-1") NIL NIL
"quoted-printable" 368 10) "alternative"))
  29:14.40 < GKGP7 OK FETCH completed.
(&#039;OK&#039;, [&#039;31 (UID 96 BODY (("text" "plain" ("charset"
"iso-8859-1") NIL NIL "quoted-printable" 32 0)("text"
"html" ("charset" "iso-8859-1") NIL NIL
"quoted-printable" 368 10) "alternative"))&#039;])
>>> i.uid("FETCH", "96", "BODY.PEEK[]")
  29:17.04 > GKGP8 UID FETCH 96 "BODY.PEEK[]"
  29:17.21 < GKGP8 NO Error in IMAP command received by
server.
  29:17.21 NO response: Error in IMAP command received
by server.
(&#039;NO&#039;, [&#039;Error in IMAP command received by server.&#039;])
>>> i.logout()
  29:31.26 > GKGP9 LOGOUT
  29:31.42 < * BYE Courier-IMAP server shutting down
  29:31.42 BYE response: Courier-IMAP server shutting down
  29:31.42 < GKGP9 OK LOGOUT completed
(&#039;BYE&#039;, [&#039;Courier-IMAP server shutting down&#039;])
>>> 

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

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

From noreply at sourceforge.net  Tue Mar 16 01:48:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 01:48:58 2004
Subject: [ python-Bugs-917120 ] imaplib: incorrect quoting in commands
Message-ID: <E1B38Ng-0005Mk-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 1
Submitted By: Tony Meyer (anadelonbrin)
Assigned to: Nobody/Anonymous (nobody)
Summary: imaplib: incorrect quoting in commands

Initial Comment:
imaplib incorrectly chooses to quote some arguments.

In particular, doing "UID FETCH # BODY.PEEK[]" results
in the BODY.PEEK[] being quoted, and it should not
(according to the RFC), which means the command fails.
 This is demonstrated below.  It&#039;s possible (and
likely) that other UID FETCH arguments are incorrectly
quoted.

This occurs with anon cvs python of 16/3/04, and 2.3.3.
 Windows XP SP1.

I&#039;m happy to provide more info if required, just let me
know.  I could try and work up a patch, but it would be
better from someone really familiar with imaplib so
that I don&#039;t screw up legitimate quoting.

>>> import imaplib
>>> i = imaplib.IMAP4("server")
>>> i.login("username", "password")
(&#039;OK&#039;, [&#039;LOGIN Ok.&#039;])
>>> i.select()
(&#039;OK&#039;, [&#039;38&#039;])
>>> i.debug = 4
>>> i.uid("FETCH", "96", "BODY")
  29:14.23 > GKGP7 UID FETCH 96 BODY
  29:14.40 < * 31 FETCH (UID 96 BODY (("text" "plain"
("charset" "iso-8859-1") NIL NIL "quoted-printable" 32
0)("text" "html" ("charset" "iso-8859-1") NIL NIL
"quoted-printable" 368 10) "alternative"))
  29:14.40 < GKGP7 OK FETCH completed.
(&#039;OK&#039;, [&#039;31 (UID 96 BODY (("text" "plain" ("charset"
"iso-8859-1") NIL NIL "quoted-printable" 32 0)("text"
"html" ("charset" "iso-8859-1") NIL NIL
"quoted-printable" 368 10) "alternative"))&#039;])
>>> i.uid("FETCH", "96", "BODY.PEEK[]")
  29:17.04 > GKGP8 UID FETCH 96 "BODY.PEEK[]"
  29:17.21 < GKGP8 NO Error in IMAP command received by
server.
  29:17.21 NO response: Error in IMAP command received
by server.
(&#039;NO&#039;, [&#039;Error in IMAP command received by server.&#039;])
>>> i.logout()
  29:31.26 > GKGP9 LOGOUT
  29:31.42 < * BYE Courier-IMAP server shutting down
  29:31.42 BYE response: Courier-IMAP server shutting down
  29:31.42 < GKGP9 OK LOGOUT completed
(&#039;BYE&#039;, [&#039;Courier-IMAP server shutting down&#039;])
>>> 

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

>Comment By: Tony Meyer (anadelonbrin)
Date: 2004-03-16 19:48

Message:
Logged In: YES 
user_id=552329

Sorry, I missed the bit in the docs that points out that
stuff is always quoted and that using () avoids it.  Still,
it does seem that imaplib would be doing it's job better if
it followed correct quoting, rather than always quoting.  It
would certainly be easier to use for people familiar with
IMAP, but unfamiliar with imaplib.

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

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

From noreply at sourceforge.net  Tue Mar 16 02:59:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 02:59:46 2004
Subject: [ python-Bugs-788421 ] bsddb btree set_location() semantics changed
Message-ID: <E1B39U5-0002oK-00@sc8-sf-web4.sourceforge.net>

Bugs item #788421, was opened at 2003-08-13 16:21
Message generated for change (Comment added) made by greg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=788421&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Gregory P. Smith (greg)
Assigned to: Gregory P. Smith (greg)
Summary: bsddb btree set_location() semantics changed

Initial Comment:
In the old bsddb module a bsddb.btopen(..) database
would return the next available key+value on a
set_location(key) call when key did not exist in the
database.  In python 2.3 (pybsddb) it raises an
exception and leaves the cursor at an unknown position
in the database.

[reported by Anthony McDonaly on comp.lang.python]

>>> import os
>>> import bsddb
>>> os.chdir(&#039;/tmp&#039;)
>>> my_data = bsddb.btopen(&#039;testing&#039;, &#039;c&#039;)
>>> for i in range(10):
...   if i == 5:
...     pass
...   else:
...     my_data[&#039;%d&#039;%i] = &#039;%d&#039;%(i*i)
...
>>> my_data.keys()
[&#039;0&#039;, &#039;1&#039;, &#039;2&#039;, &#039;3&#039;, &#039;4&#039;, &#039;6&#039;, &#039;7&#039;, &#039;8&#039;, &#039;9&#039;]
>>> my_data.sync()
>>> my_data.set_location(&#039;5&#039;)
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File
"/space/python-2.3/lib/python2.3/bsddb/__init__.py",
line 117, in set_location
    return self.dbc.set(key)
_bsddb.DBNotFoundError: (-30991, &#039;DB_NOTFOUND: No
matching key/data pair found&#039;)

Correct behaviour would have been to return (&#039;6&#039;, &#039;36&#039;)


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

>Comment By: Gregory P. Smith (greg)
Date: 2004-03-15 23:59

Message:
Logged In: YES 
user_id=413

committed fix to head and release23-maint along with an associated fix for set_range where it could free() memory that it doesn't own on non B-Tree databases.

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

Comment By: Gregory P. Smith (greg)
Date: 2004-02-26 02:11

Message:
Logged In: YES 
user_id=413

Yes this is a bug.  The set_location() method should have been calling set_range() rather than set() internally.

Fixing that exposed another bug: set_range() would crash when looking up a key that exists in hash or rn databases.

Both bugs have been fixed to fix this one in python 2.4 & pybsddb CVS.

This bugfix should go into python 2.3.4.

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

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

From noreply at sourceforge.net  Tue Mar 16 04:53:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 04:53:25 2004
Subject: [ python-Bugs-736428 ] allow HTMLParser error recovery
Message-ID: <E1B3BG7-0003Ku-00@sc8-sf-web1.sourceforge.net>

Bugs item #736428, was opened at 2003-05-12 12:37
Message generated for change (Comment added) made by kingswood
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736428&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Rosenthal (smroid)
Assigned to: Nobody/Anonymous (nobody)
Summary: allow HTMLParser error recovery

Initial Comment:
I&#039;m using 2.3a2.

HTMLParser correctly raises a "malformed start tag"
error on:

<meta NAME=DESCRIPTION Content=Lands&#039; End quality...
outerwear and more.> 

because my application is imprecise by nature (web
scraping), I want to be able to continue after such errors.

I can override the error() method to not raise an
exception. To make this work, I also needed to alter
HTMLParser.py, near line 316, to read as:

            self.updatepos(i, j)
            self.error("malformed start tag")
            return j                    #  ADDED THIS LINE
        raise AssertionError("we should not get here!")

My enhancement request is for every place where
self.error() is called, to ensure that the "override
error() to not raise an exception" continuation
strategy works as well as can be hoped.

Thanks,

Steve


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

Comment By: Frank Vorstenbosch (kingswood)
Date: 2004-03-16 09:53

Message:
Logged In: YES 
user_id=555155

Fixed by my patch against 2.3.3.
The patch adds recovery to ensure progress and tries to not
miss any data in the input.
The error() method is now commented as being overridable,
just def error(): pass to ignore any parsing errors.


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

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

From noreply at sourceforge.net  Tue Mar 16 04:59:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 04:59:56 2004
Subject: [ python-Bugs-917188 ] Allow HTMLParser to continue after a parse
	error
Message-ID: <E1B3BMV-0003vv-00@sc8-sf-web1.sourceforge.net>

Bugs item #917188, was opened at 2004-03-16 09:59
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917188&group_id=5470

Category: Python Library
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Frank Vorstenbosch (kingswood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow HTMLParser to continue after a parse error

Initial Comment:
Allows HTMLParser to continue after invoking error().
Normally, error() raises an HTMLParseError, but a user
might want to override that behaviour and continue parsing.
Places following calls to self.error() need some
recovery code.

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

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

From noreply at sourceforge.net  Tue Mar 16 05:44:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 05:44:33 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B3C3d-0008PC-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

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

From noreply at sourceforge.net  Tue Mar 16 06:49:39 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 06:49:48 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B3D4l-0005O3-00@sc8-sf-web4.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

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

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

From noreply at sourceforge.net  Tue Mar 16 06:52:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 06:52:47 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B3D7i-00069b-00@sc8-sf-web2.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

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

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

From noreply at sourceforge.net  Tue Mar 16 16:03:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 16 16:03:57 2004
Subject: [ python-Bugs-649962 ] All URL funcs mishandle file://localhost
Message-ID: <E1B3Lj7-0007It-00@sc8-sf-web4.sourceforge.net>

Bugs item #649962, was opened at 2002-12-07 08:28
Message generated for change (Comment added) made by troy_melhase
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=649962&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: All URL funcs mishandle file://localhost

Initial Comment:
Per RFC 1738 section 3.10: "A file URL takes the form: 
file://<host>/<path> ... As a special case, <host> can 
be the string "localhost" or the empty string; this is 
interpreted as `the machine from which the URL is being 
interpreted".

In other words, regardless of what DNS or NetBIOS say 
about "localhost", it is always the local machine.

Therefore, functions like urllib.url2pathname() and 
urllib.urlopen() and anything else that takes a URL 
argument should treat &#039;///path/to/file&#039; 
and &#039;//localhost/path/to/file&#039; identically, 
returning &#039;/path/to/file&#039; on Unix or &#039;\path\to\file&#039; on 
Windows, for example.

(note separate bug report filed for url2pathname() 
mishandling &#039;///path/to/file&#039; on Windows)


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

Comment By: troy melhase (troy_melhase)
Date: 2004-03-16 21:03

Message:
Logged In: YES 
user_id=548370

Should be closed; duplicate of bug #607789, now closed.

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

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

From noreply at sourceforge.net  Wed Mar 17 04:05:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 17 04:05:28 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B3Wz4-0002bV-00@sc8-sf-web3.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

>Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

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

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

From noreply at sourceforge.net  Wed Mar 17 06:27:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 17 06:28:07 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B3ZDJ-000179-00@sc8-sf-web4.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 06:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

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

Comment By: paul rubin (phr)
Date: 2004-03-17 04:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

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

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

From noreply at sourceforge.net  Wed Mar 17 14:48:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 17 14:48:08 2004
Subject: [ python-Bugs-649962 ] All URL funcs mishandle file://localhost
Message-ID: <E1B3h1G-0005Pg-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: All URL funcs mishandle file://localhost

Initial Comment:
Per RFC 1738 section 3.10: "A file URL takes the form: 
file://<host>/<path> ... As a special case, <host> can 
be the string "localhost" or the empty string; this is 
interpreted as `the machine from which the URL is being 
interpreted".

In other words, regardless of what DNS or NetBIOS say 
about "localhost", it is always the local machine.

Therefore, functions like urllib.url2pathname() and 
urllib.urlopen() and anything else that takes a URL 
argument should treat &#039;///path/to/file&#039; 
and &#039;//localhost/path/to/file&#039; identically, 
returning &#039;/path/to/file&#039; on Unix or &#039;\path\to\file&#039; on 
Windows, for example.

(note separate bug report filed for url2pathname() 
mishandling &#039;///path/to/file&#039; on Windows)


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

>Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-17 12:48

Message:
Logged In: YES 
user_id=371366

I didn't realize it was a duplicate. I'm OK with the resolution 
of #607789. So I am changing this one to Closed / Duplicate.

In hindsight, I feel there are so many little conformance bugs 
in urllib that are so entrenched, there's no reason to assume 
that true RFC conformance was ever the intent or that it is a 
reasonable goal. Much code out there, within core Python libs 
and without, is written to match urllib's current behavior, or 
vice-versa.

If anyone's curious, I have implemented some urllib 
workarounds and RFC 2396bis (new version of RFC 2396, the 
URI spec) compliant features in 4Suite's Ft.Lib.Uri module, 
which can be reviewed at http://cvs.4suite.org/cgi-
bin/viewcvs.cgi/~checkout~/4Suite/Ft/Lib/Uri.py?
rev=HEAD&content-type=text/plain  ... it's always a work in 
progress, but is getting close to having a fork stuck in it for 
our upcoming 1.0 release.

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

Comment By: troy melhase (troy_melhase)
Date: 2004-03-16 14:03

Message:
Logged In: YES 
user_id=548370

Should be closed; duplicate of bug #607789, now closed.

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

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

From noreply at sourceforge.net  Wed Mar 17 17:24:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 17 17:24:41 2004
Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http
Message-ID: <E1B3jSd-0002kj-00@sc8-sf-web2.sourceforge.net>

Bugs item #767111, was opened at 2003-07-07 13:52
Message generated for change (Comment added) made by robzed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Stuart Bishop (zenzen)
Assigned to: A.M. Kuchling (akuchling)
Summary: AttributeError thrown by urllib.open_http

Initial Comment:
In 2.3b2, looks like an error condition isn&#039;t being picked up 
on line 300 or 301 of urllib.py.

The code that triggered this traceback was simply:
        url = urllib.urlopen(action, data)


Traceback (most recent call last):
  File "autospamrep.py", line 170, in ?
    current_page = handle_spamcop_page(current_page)
  File "autospamrep.py", line 140, in handle_spamcop_page
    url = urllib.urlopen(action, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 78, in urlopen
    return opener.open(url, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 183, in open
    return getattr(self, name)(url, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 308, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers, 
data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 551, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 837, in __init__
    addbase.__init__(self, fp)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 787, in __init__
    self.read = self.fp.read
AttributeError: &#039;NoneType&#039; object has no attribute &#039;read&#039;

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

Comment By: Rob Probin (robzed)
Date: 2004-03-17 22:24

Message:
Logged In: YES 
user_id=1000470

""" 
This comment is program to reproduce the problem. Sorry it's not an 
attachment - as a relative Sourceforge newbie I have no idea how to 
attach to an existing bug. More notes available via email if required - 
including all local variables for each function from post mortem.

As said before, seems to be fp = None. Although the exception is caused 
by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside 
open_http()

This is repeatable, but you may have to run this more than once. 
(Apologies to noaa.gov).

*** PLEASE: Run only where absolutely necessary for reproduction of 
bug!!! ***

"""

""" Attribute Error test case  - Python 2.3 """

import urllib

url = "http://adds.aviationweather.noaa.gov/metars/index.php"

params = urllib.urlencode({ "station_ids" : "KJFK", 
				"hoursStr" : "most recent only", 
				"std_trans" : "standard", 
				"chk_metars" : "on",
				"submit":"Submit"})

print "test"

for i in range(1, 1000):
	x = urllib.urlopen(url, params)
	string = x.read()
	print i

"""
Local variables for middle level routine...

	classURLopener
	open_http(self, url, data=None)
		args	('User-agent', 'Python-urllib/1.15')
		auth	None
		data	
'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub
mit=Submit&chk_metars=on'
		errcode	-1
		errmsg	''
		fp	None
		h	<httplib.HTTP instance at 0x507df30>
		headers	None
		host	'adds.aviationweather.noaa.gov'
		httplib	<module 'httplib' from '/System/Library/Frameworks/
Python.framework/Versions/2.3/lib/python2.3/httplib.pyc'>
		realhost	'adds.aviationweather.noaa.gov'
		selector	'/metars/index.php'
		self	<urllib.FancyURLopener instance at 0x465f3c8>
		url	'//adds.aviationweather.noaa.gov/metars/index.php'
		user_passwd	None
"""


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-07-29 04:23

Message:
Logged In: YES 
user_id=12800

Please provide a self-contained, complete example that we
can use to reproduce this problem.  Without enough
information, I can't see us fixing this for Python 2.3, and
time for that is rapidly running out.

Lowering to priority 6.

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-07-17 05:34

Message:
Logged In: YES 
user_id=46639

I've finally managed to get another traceback with some more 
information, using an assert I inserted into urllib.py a while ago to 
catch .fp == None:

Traceback (most recent call last):
  File "/Users/zen/bin/autospamrep.py", line 168, in ?
    current_page = urllib.urlopen(start_url).read()
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py", line 76, in urlopen
    return opener.open(url)
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py", line 305, in open_http
    assert fp is not None, 'errcode %r, errmsg %r, headers %r' % 
(errcode, errmsg, headers)
AssertionError: errcode -1, errmsg '', headers None


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

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

Message:
Logged In: YES 
user_id=261020

HTTPResponse.read returns '' if its .fp is None, but the 
backwards-compat HTTP class' .getfile() just returns self.file, 
which it previously grabbed from HTTPResponse in .getreply(). 
 
Wild guess: maybe HTTP.getreply should just do 
 
self.file = response 
 
rather than 
 
self.file = response.fp 
 
The object returned by HTTP.getfile() was documented as 
returning an object supporting .readline() and .readlines(), 
while HTTPResponse only supports .read(), so that's obviously 
not the whole solution. 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 06:50

Message:
Logged In: YES 
user_id=80475

What were the values of 'action' and 'data' when the call was 
made?

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

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

From noreply at sourceforge.net  Wed Mar 17 17:41:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 17 17:41:42 2004
Subject: [ python-Bugs-918368 ] urllib doesn't correct server returned urls
Message-ID: <E1B3jjF-00045f-00@sc8-sf-web2.sourceforge.net>

Bugs item #918368, was opened at 2004-03-17 22:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918368&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Probin (robzed)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib doesn't correct server returned urls

Initial Comment:
On a URL request where the server returns a URL with spaces in, 
urllib doesn&#039;t correct it before requesting the new page.

I think this is technically a server error, however, it does work 
from web browsers (Mozilla, Safari) but not from Python urllib.

I would suggest that when urllib is following "moved temporarily" 
links (or similar) from a server it translates spaces to %20.

See example program file for more including detailed server/client 
transactions text.




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

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

From noreply at sourceforge.net  Wed Mar 17 17:42:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 17 17:42:53 2004
Subject: [ python-Bugs-918371 ] hasattr()'s return type
Message-ID: <E1B3jkQ-0004vq-00@sc8-sf-web1.sourceforge.net>

Bugs item #918371, was opened at 2004-03-18 07:42
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918371&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: [N/A] (ymasuda)
Assigned to: Nobody/Anonymous (nobody)
Summary: hasattr()'s return type

Initial Comment:
>From Python 2.3, hasattr() has been changed to return 
boolean instead of integer:1 or 0. But libfunc.tex still 
describes older specification. Please fix it.

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

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

From noreply at sourceforge.net  Thu Mar 18 01:27:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 01:28:11 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B3r0Q-0001bM-00@sc8-sf-web3.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

>Comment By: paul rubin (phr)
Date: 2004-03-18 06:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 11:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

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

Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

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

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

From noreply at sourceforge.net  Thu Mar 18 03:51:29 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 03:51:51 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B3tFR-0006Ys-00@sc8-sf-web2.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

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

>Comment By: paul rubin (phr)
Date: 2004-03-18 08:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

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

Comment By: paul rubin (phr)
Date: 2004-03-18 06:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 11:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

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

Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

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

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

From noreply at sourceforge.net  Thu Mar 18 07:44:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 07:44:42 2004
Subject: [ python-Bugs-918710 ] popen2 returns (out, in) not (in, out)
Message-ID: <E1B3wt4-0008I8-00@sc8-sf-web2.sourceforge.net>

Bugs item #918710, was opened at 2004-03-18 14:44
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918710&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Yotam Medini (yotam)
Assigned to: Nobody/Anonymous (nobody)
Summary: popen2 returns (out, in) not (in, out)

Initial Comment:
http://python.org/doc/current/lib/os-newstreams.html#l2h-1379
says:

popen2(  	cmd[, mode[, bufsize]])
    Executes cmd as a sub-process.
    Returns the file objects (child_stdin, child_stdout). 

But for me it actually returns (child-output, child-input).
Or... is it a semantci issue?  that is 
  child_stdin - is "the input _from_ child?"
Anyway - it is confusing.


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

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

From noreply at sourceforge.net  Thu Mar 18 09:18:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 09:18:25 2004
Subject: [ python-Bugs-917188 ] Allow HTMLParser to continue after a parse
	error
Message-ID: <E1B3yLj-0003Yo-00@sc8-sf-web4.sourceforge.net>

Bugs item #917188, was opened at 2004-03-16 10:59
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917188&group_id=5470

Category: Python Library
Group: Python 2.2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: Frank Vorstenbosch (kingswood)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow HTMLParser to continue after a parse error

Initial Comment:
Allows HTMLParser to continue after invoking error().
Normally, error() raises an HTMLParseError, but a user
might want to override that behaviour and continue parsing.
Places following calls to self.error() need some
recovery code.

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

>Comment By: Walter D?rwald (doerwalter)
Date: 2004-03-18 15:18

Message:
Logged In: YES 
user_id=89016

This is a duplicate of #736428. Closed.

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

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

From noreply at sourceforge.net  Thu Mar 18 14:29:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 14:29:07 2004
Subject: [ python-Bugs-919012 ] shutil.move can destroy files 
Message-ID: <E1B43CR-0000nj-00@sc8-sf-web2.sourceforge.net>

Bugs item #919012, was opened at 2004-03-18 13:29
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919012&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Epler (jepler)
Assigned to: Nobody/Anonymous (nobody)
Summary: shutil.move can destroy files 

Initial Comment:
$ mkdir a; touch a/b; python2.3 -c &#039;import shutil;
shutil.move("a", "a/c")
$ ls -l a
ls: a: no such file or directory

The same problem exists on Windows, as reported by one
"shagshag".

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

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

From noreply at sourceforge.net  Thu Mar 18 14:33:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 14:33:29 2004
Subject: [ python-Bugs-919014 ] Error with random module
Message-ID: <E1B43Gf-0001Ie-00@sc8-sf-web2.sourceforge.net>

Bugs item #919014, was opened at 2004-03-18 20:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919014&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ga?tan (herlockg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Error with random module

Initial Comment:
Hello,

I&#039;m on a Intel Pentium4 3ghz running on Linux (2.4.22)
I have an error when i use the random module

Just with these following lines:
import random
print random.randint(1,10)

I have this error:
Traceback (most recent call last):
  File "plf", line 1, in ?
    import random
  File "/usr/lib/python2.3/random.py", line 4, in ?
    --------
AttributeError: &#039;module&#039; object has no attribute &#039;randint&#039;


I don&#039;t know what to do, i already recompiled python
with different cflags...

Do you know something about it?

(I&#039;m so sorry for my bad english. I hoop you&#039;ve
understood me)

Thank you.

Ga?tan.




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

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

From noreply at sourceforge.net  Thu Mar 18 17:06:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 17:06:16 2004
Subject: [ python-Bugs-919099 ] Update docs on Reload()
Message-ID: <E1B45eW-00084I-00@sc8-sf-web2.sourceforge.net>

Bugs item #919099, was opened at 2004-03-18 15:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919099&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Update docs on Reload()

Initial Comment:
The current description of the reload() function in the 
Library Reference Manual, Release 2.3.3, Section 2.1 
provides lots of detail, but not enough basic 
explanation.  As a result, there is lots of confusion on 
the use of reload, in the mailing lists, and even in texts 
on Python.  The attached PDF file shows the text from 
the manual, with my suggested edits highlighted in 
yellow.

The main change is to add a much more detailed 
description of what happens when a module is reloaded.  
Reloads were always a mystery to me, until I started 
thinking about what is happening to the namespaces.

A minor edit:  I replaced "re-parse and re-initialize" 
with "re-compile and reload", since I think many users 
won&#039;t know exactly what the former terms mean in this 
context.  I&#039;m not very familiar with the documentation, 
so I don&#039;t know if the former terms might be preferred, 
so as to be consistent with other documents.

See 
http://ece.arizona.edu/~edatools/Python/Reload.htm for 
an introductory description of reload, with examples and 
exercises and a few paragraphs on why reload can never 
work the way many users expect it to.

-- Dave


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

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

From noreply at sourceforge.net  Thu Mar 18 17:38:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 17:38:28 2004
Subject: [ python-Bugs-918368 ] urllib doesn't correct server returned urls
Message-ID: <E1B469e-00052l-00@sc8-sf-web4.sourceforge.net>

Bugs item #918368, was opened at 2004-03-17 22:41
Message generated for change (Comment added) made by robzed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918368&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Probin (robzed)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib doesn't correct server returned urls

Initial Comment:
On a URL request where the server returns a URL with spaces in, 
urllib doesn&#039;t correct it before requesting the new page.

I think this is technically a server error, however, it does work 
from web browsers (Mozilla, Safari) but not from Python urllib.

I would suggest that when urllib is following "moved temporarily" 
links (or similar) from a server it translates spaces to %20.

See example program file for more including detailed server/client 
transactions text.




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

>Comment By: Rob Probin (robzed)
Date: 2004-03-18 22:38

Message:
Logged In: YES 
user_id=1000470

I've tested a change to "redirect_internal(self, url, fp, errcode, errmsg, 
headers, data)" in "urllib.py" that adds a single line newurl = 
newurl.replace(" ","%20") after the basejoin() function call that appears 
to fix the problem.

This information is placed in the public domain.


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

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

From noreply at sourceforge.net  Thu Mar 18 18:43:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 18 18:43:51 2004
Subject: [ python-Bugs-767111 ] AttributeError thrown by urllib.open_http
Message-ID: <E1B47An-0001EY-00@sc8-sf-web4.sourceforge.net>

Bugs item #767111, was opened at 2003-07-07 13:52
Message generated for change (Comment added) made by robzed
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=767111&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Stuart Bishop (zenzen)
Assigned to: A.M. Kuchling (akuchling)
Summary: AttributeError thrown by urllib.open_http

Initial Comment:
In 2.3b2, looks like an error condition isn&#039;t being picked up 
on line 300 or 301 of urllib.py.

The code that triggered this traceback was simply:
        url = urllib.urlopen(action, data)


Traceback (most recent call last):
  File "autospamrep.py", line 170, in ?
    current_page = handle_spamcop_page(current_page)
  File "autospamrep.py", line 140, in handle_spamcop_page
    url = urllib.urlopen(action, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 78, in urlopen
    return opener.open(url, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 183, in open
    return getattr(self, name)(url, data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 308, in open_http
    return self.http_error(url, fp, errcode, errmsg, headers, 
data)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 323, in http_error
    return self.http_error_default(url, fp, errcode, errmsg, 
headers)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 551, in http_error_default
    return addinfourl(fp, headers, "http:" + url)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 837, in __init__
    addbase.__init__(self, fp)
  File "/Library/Frameworks/Python.framework/Versions/2.3/
lib/python2.3/urllib.py", line 787, in __init__
    self.read = self.fp.read
AttributeError: &#039;NoneType&#039; object has no attribute &#039;read&#039;

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

Comment By: Rob Probin (robzed)
Date: 2004-03-18 23:43

Message:
Logged In: YES 
user_id=1000470

The file pointer (fp) is None (inside urllib) from httplib. This appears to 
be caused by a BadStatusLine exception in getreply() (line1016 httplib). 

This sets self.file to self._conn.sock.makefile('rb', 0) then does a 
self.close() which sets self.file to None. 

Being new to this peice of code, I'm not sure whether it's urllib assuming 
the file isn't going to be closed, or the BadStatusLine exception clearing 
the file. Certainly it looks like the error -1 is not being trapped by 
open_http() in urllib upon calling h.getreply() and assuming that the file 
still exists even in an error condition?

It maybe a coincidence but it appears to occur more when a web browser 
on the same machine is refreshing. 

Regards
Rob


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

Comment By: Rob Probin (robzed)
Date: 2004-03-17 22:24

Message:
Logged In: YES 
user_id=1000470

""" 
This comment is program to reproduce the problem. Sorry it's not an 
attachment - as a relative Sourceforge newbie I have no idea how to 
attach to an existing bug. More notes available via email if required - 
including all local variables for each function from post mortem.

As said before, seems to be fp = None. Although the exception is caused 
by the 'self.read = self.fp.read', it looks like 'fp = h.getfile()' inside 
open_http()

This is repeatable, but you may have to run this more than once. 
(Apologies to noaa.gov).

*** PLEASE: Run only where absolutely necessary for reproduction of 
bug!!! ***

"""

""" Attribute Error test case  - Python 2.3 """

import urllib

url = "http://adds.aviationweather.noaa.gov/metars/index.php"

params = urllib.urlencode({ "station_ids" : "KJFK", 
				"hoursStr" : "most recent only", 
				"std_trans" : "standard", 
				"chk_metars" : "on",
				"submit":"Submit"})

print "test"

for i in range(1, 1000):
	x = urllib.urlopen(url, params)
	string = x.read()
	print i

"""
Local variables for middle level routine...

	classURLopener
	open_http(self, url, data=None)
		args	('User-agent', 'Python-urllib/1.15')
		auth	None
		data	
'hoursStr=most+recent+only&station_ids=KJFK&std_trans=standard&sub
mit=Submit&chk_metars=on'
		errcode	-1
		errmsg	''
		fp	None
		h	<httplib.HTTP instance at 0x507df30>
		headers	None
		host	'adds.aviationweather.noaa.gov'
		httplib	<module 'httplib' from '/System/Library/Frameworks/
Python.framework/Versions/2.3/lib/python2.3/httplib.pyc'>
		realhost	'adds.aviationweather.noaa.gov'
		selector	'/metars/index.php'
		self	<urllib.FancyURLopener instance at 0x465f3c8>
		url	'//adds.aviationweather.noaa.gov/metars/index.php'
		user_passwd	None
"""


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

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-07-29 04:23

Message:
Logged In: YES 
user_id=12800

Please provide a self-contained, complete example that we
can use to reproduce this problem.  Without enough
information, I can't see us fixing this for Python 2.3, and
time for that is rapidly running out.

Lowering to priority 6.

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

Comment By: Stuart Bishop (zenzen)
Date: 2003-07-17 05:34

Message:
Logged In: YES 
user_id=46639

I've finally managed to get another traceback with some more 
information, using an assert I inserted into urllib.py a while ago to 
catch .fp == None:

Traceback (most recent call last):
  File "/Users/zen/bin/autospamrep.py", line 168, in ?
    current_page = urllib.urlopen(start_url).read()
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py", line 76, in urlopen
    return opener.open(url)
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py", line 181, in open
    return getattr(self, name)(url)
  File "/Library/Frameworks/Python.framework/Versions/2.3/lib/
python2.3/urllib.py", line 305, in open_http
    assert fp is not None, 'errcode %r, errmsg %r, headers %r' % 
(errcode, errmsg, headers)
AssertionError: errcode -1, errmsg '', headers None


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

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

Message:
Logged In: YES 
user_id=261020

HTTPResponse.read returns '' if its .fp is None, but the 
backwards-compat HTTP class' .getfile() just returns self.file, 
which it previously grabbed from HTTPResponse in .getreply(). 
 
Wild guess: maybe HTTP.getreply should just do 
 
self.file = response 
 
rather than 
 
self.file = response.fp 
 
The object returned by HTTP.getfile() was documented as 
returning an object supporting .readline() and .readlines(), 
while HTTPResponse only supports .read(), so that's obviously 
not the whole solution. 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 06:50

Message:
Logged In: YES 
user_id=80475

What were the values of 'action' and 'data' when the call was 
made?

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

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

From noreply at sourceforge.net  Fri Mar 19 01:45:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 01:45:27 2004
Subject: [ python-Bugs-919014 ] Error with random module
Message-ID: <E1B4Dkr-0007Vu-00@sc8-sf-web4.sourceforge.net>

Bugs item #919014, was opened at 2004-03-18 14:33
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919014&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Ga?tan (herlockg)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: Error with random module

Initial Comment:
Hello,

I&#039;m on a Intel Pentium4 3ghz running on Linux (2.4.22)
I have an error when i use the random module

Just with these following lines:
import random
print random.randint(1,10)

I have this error:
Traceback (most recent call last):
  File "plf", line 1, in ?
    import random
  File "/usr/lib/python2.3/random.py", line 4, in ?
    --------
AttributeError: &#039;module&#039; object has no attribute &#039;randint&#039;


I don&#039;t know what to do, i already recompiled python
with different cflags...

Do you know something about it?

(I&#039;m so sorry for my bad english. I hoop you&#039;ve
understood me)

Thank you.

Ga?tan.




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

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

From noreply at sourceforge.net  Fri Mar 19 01:54:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 01:54:14 2004
Subject: [ python-Bugs-919014 ] Error with random module
Message-ID: <E1B4DtR-0000kb-00@sc8-sf-web1.sourceforge.net>

Bugs item #919014, was opened at 2004-03-18 14:33
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919014&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Ga?tan (herlockg)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Error with random module

Initial Comment:
Hello,

I&#039;m on a Intel Pentium4 3ghz running on Linux (2.4.22)
I have an error when i use the random module

Just with these following lines:
import random
print random.randint(1,10)

I have this error:
Traceback (most recent call last):
  File "plf", line 1, in ?
    import random
  File "/usr/lib/python2.3/random.py", line 4, in ?
    --------
AttributeError: &#039;module&#039; object has no attribute &#039;randint&#039;


I don&#039;t know what to do, i already recompiled python
with different cflags...

Do you know something about it?

(I&#039;m so sorry for my bad english. I hoop you&#039;ve
understood me)

Thank you.

Ga?tan.




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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-19 01:54

Message:
Logged In: YES 
user_id=80475

Your Lib/random.py file is likely damaged.

First, check to see if there is another file named random.py
on your 
search path.  If so, rename it.  If not, get a refreshed
copy of random.py from SF:

http://cvs.sourceforge.net/viewcvs.py/*checkout*/python/python/dist/src/Lib/random.py?content-type=text%2Fplain&rev=1.60

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

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

From noreply at sourceforge.net  Fri Mar 19 08:20:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 09:02:47 2004
Subject: [ python-Bugs-919498 ] Math Division Problem?
Message-ID: <E1B4JvH-0002tW-00@sc8-sf-web2.sourceforge.net>

Bugs item #919498, was opened at 2004-03-19 16:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919498&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: GrASP (grasp81)
Assigned to: Nobody/Anonymous (nobody)
Summary: Math Division Problem?

Initial Comment:
Using
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32

A mere real division resulted in this:
>>> 7.0/3
2.3333333333333335

Mind the trailing &#039;5&#039;. Did I miss my University classes too 
much? ;)

Amazingly,
>>> 4.0/3
1.3333333333333333
- works OK.


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

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

From noreply at sourceforge.net  Fri Mar 19 09:23:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 09:23:11 2004
Subject: [ python-Bugs-919498 ] Math Division Problem?
Message-ID: <E1B4Ktt-0001Bd-00@sc8-sf-web2.sourceforge.net>

Bugs item #919498, was opened at 2004-03-19 14:20
Message generated for change (Comment added) made by sjoerd
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919498&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: GrASP (grasp81)
Assigned to: Nobody/Anonymous (nobody)
Summary: Math Division Problem?

Initial Comment:
Using
Python 2.3.3 (#51, Dec 18 2003, 20:22:39) [MSC 
v.1200 32 bit (Intel)] on win32

A mere real division resulted in this:
>>> 7.0/3
2.3333333333333335

Mind the trailing &#039;5&#039;. Did I miss my University classes too 
much? ;)

Amazingly,
>>> 4.0/3
1.3333333333333333
- works OK.


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

Comment By: Sjoerd Mullender (sjoerd)
Date: 2004-03-19 15:23

Message:
Logged In: YES 
user_id=43607

This is not a bug.

Binary floating point cannot represent decimal fractions exactly,
so some rounding always occurs (even in Python 1.5.2).

What changed is that Python 2.0 shows more precision than before
in certain circumstances (repr() and the interactive prompt). 

You can use str() or print to get the old, rounded output: 

>>> print 0.1+0.1
0.2
>>>

Follow the link for more information:

http://www.python.org/doc/2.2.1/tut/node14.html

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

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

From noreply at sourceforge.net  Fri Mar 19 10:30:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 10:30:33 2004
Subject: [ python-Bugs-919099 ] Update docs on Reload()
Message-ID: <E1B4Lx3-0000nG-00@sc8-sf-web3.sourceforge.net>

Bugs item #919099, was opened at 2004-03-18 16:06
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919099&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: David MacQuigg (macquigg)
Assigned to: Skip Montanaro (montanaro)
Summary: Update docs on Reload()

Initial Comment:
The current description of the reload() function in the 
Library Reference Manual, Release 2.3.3, Section 2.1 
provides lots of detail, but not enough basic 
explanation.  As a result, there is lots of confusion on 
the use of reload, in the mailing lists, and even in texts 
on Python.  The attached PDF file shows the text from 
the manual, with my suggested edits highlighted in 
yellow.

The main change is to add a much more detailed 
description of what happens when a module is reloaded.  
Reloads were always a mystery to me, until I started 
thinking about what is happening to the namespaces.

A minor edit:  I replaced "re-parse and re-initialize" 
with "re-compile and reload", since I think many users 
won&#039;t know exactly what the former terms mean in this 
context.  I&#039;m not very familiar with the documentation, 
so I don&#039;t know if the former terms might be preferred, 
so as to be consistent with other documents.

See 
http://ece.arizona.edu/~edatools/Python/Reload.htm for 
an introductory description of reload, with examples and 
exercises and a few paragraphs on why reload can never 
work the way many users expect it to.

-- Dave


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

>Comment By: Skip Montanaro (montanaro)
Date: 2004-03-19 09:30

Message:
Logged In: YES 
user_id=44345

Accepted with a few changes.


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

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

From noreply at sourceforge.net  Fri Mar 19 09:45:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 10:31:24 2004
Subject: [ python-Bugs-919099 ] Update docs on Reload()
Message-ID: <E1B4LFC-0002k3-00@sc8-sf-web4.sourceforge.net>

Bugs item #919099, was opened at 2004-03-18 16:06
Message generated for change (Settings changed) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919099&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: David MacQuigg (macquigg)
>Assigned to: Skip Montanaro (montanaro)
Summary: Update docs on Reload()

Initial Comment:
The current description of the reload() function in the 
Library Reference Manual, Release 2.3.3, Section 2.1 
provides lots of detail, but not enough basic 
explanation.  As a result, there is lots of confusion on 
the use of reload, in the mailing lists, and even in texts 
on Python.  The attached PDF file shows the text from 
the manual, with my suggested edits highlighted in 
yellow.

The main change is to add a much more detailed 
description of what happens when a module is reloaded.  
Reloads were always a mystery to me, until I started 
thinking about what is happening to the namespaces.

A minor edit:  I replaced "re-parse and re-initialize" 
with "re-compile and reload", since I think many users 
won&#039;t know exactly what the former terms mean in this 
context.  I&#039;m not very familiar with the documentation, 
so I don&#039;t know if the former terms might be preferred, 
so as to be consistent with other documents.

See 
http://ece.arizona.edu/~edatools/Python/Reload.htm for 
an introductory description of reload, with examples and 
exercises and a few paragraphs on why reload can never 
work the way many users expect it to.

-- Dave


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

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

From noreply at sourceforge.net  Fri Mar 19 11:23:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 11:23:19 2004
Subject: [ python-Bugs-919614 ] Python configured with --disable-unicode
	fails tests, more
Message-ID: <E1B4MmB-0003jQ-00@sc8-sf-web4.sourceforge.net>

Bugs item #919614, was opened at 2004-03-19 11:23
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919614&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python configured with --disable-unicode fails tests, more

Initial Comment:
When building Python with:

    ./configure --disable-unicode

the test suite has many spurious failures because
modules and tests assume that unicode support is available.

Installing this Python (using "make install") fails at
the end of the first run of compileall.py, since that
script detects and reports failures; the output
contains many lines with the message

    Sorry: ValueError: (&#039;Unicode escapes not legal when
Unicode disabled&#039;,)

This should be fixed, or --disable-unicode should be
removed.


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

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

From noreply at sourceforge.net  Fri Mar 19 11:11:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 12:02:49 2004
Subject: [ python-Bugs-919605 ] os.rename() silently overwrites files
Message-ID: <E1B4Mav-0003rW-00@sc8-sf-web2.sourceforge.net>

Bugs item #919605, was opened at 2004-03-19 17:11
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919605&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Jozef Behran (jojoworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.rename() silently overwrites files

Initial Comment:
Python 2.2.2 from Mandrake GNU/Linux 9.0

os.rename() should throw an exception when the program
tries to rename file to an existing filename. Such a
situation is namely usually caused by a bug in the
calling program. The current behavior (silently
replacing old file content with the new one) is
dangerous to programmer&#039;s data.

If the program wants to overwrite files, it can use

try:
  os.rename(old,new)
except IOError:
  os.unlink(new)
  os.rename(old,new)

or something similar to do so.

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

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

From noreply at sourceforge.net  Fri Mar 19 15:36:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 15:36:57 2004
Subject: [ python-Bugs-919776 ] Can't create Carbon.File.FSSpec for
	non-existent file
Message-ID: <E1B4QjZ-0007ov-00@sc8-sf-web1.sourceforge.net>

Bugs item #919776, was opened at 2004-03-19 20:36
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919776&group_id=5470

Category: Macintosh
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: has (hhas)
Assigned to: Jack Jansen (jackjansen)
Summary: Can't create Carbon.File.FSSpec for non-existent file

Initial Comment:
MacPython 2.3 can&#039;t create a Carbon.File.FSSpec for a non-
existent file. 

Example (where &#039;NEWFILE&#039; is name of a file still to be created):

from Carbon.File import *

f = FSSpec(u&#039;/Users/has/NEWFILE&#039;)

--> MacOS.Error: (-43, &#039;File not found&#039;)

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

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

From noreply at sourceforge.net  Fri Mar 19 17:45:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 19 17:45:48 2004
Subject: [ python-Bugs-914148 ] xml.sax segfault on error
Message-ID: <E1B4SkE-000814-00@sc8-sf-web2.sourceforge.net>

Bugs item #914148, was opened at 2004-03-11 15:14
Message generated for change (Comment added) made by jojoworks
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=914148&group_id=5470

Category: XML
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Adam Sampson (adamsampson)
Assigned to: Nobody/Anonymous (nobody)
Summary: xml.sax segfault on error

Initial Comment:
While (mistakenly) using Mark Pilgrim&#039;s feedparser
module to parse data from
<http://www.gothamist.com/archives/news_nyc/index.php>,
Python segfaults when it should invoke an error handler
for invalid XML. The attached code demonstrates the
problem; it occurs with Python 2.2.3 and 2.3.3 on my
system. I&#039;ve tried to chop the example data down as far
as possible, but reducing it any further doesn&#039;t
exhibit the problem (it&#039;s currently just above 64k,
which might be a coincidence).

The gdb traceback I get from the example is as follows:

#0  normal_updatePosition (enc=0x404a4fc0, 
    ptr=0x40682000 <Address 0x40682000 out of bounds>, 
    end=0x81e87e0 "a></div>\n\n<div
id=\content\>\n\n<div class=\blog\>\n<!--\n<rdf:RDF
xmlns:rdf=\http://www.w3.org/1999/02/22-rdf-syntax-ns#\\n
       
xmlns:trackback=\http://madskills.com/public/xml/rss/module/trackback/\\n"...,
pos=0x81e7dac)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmltok_impl.c:1745
#1  0x40484288 in XML_GetCurrentLineNumber
(parser=0x81e7c18)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/expat/xmlparse.c:1605
#2  0x40481fc5 in set_error (self=0x0,
code=XML_ERROR_TAG_MISMATCH)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:124
#3  0x40480ae7 in xmlparse_Parse (self=0x402fddac,
args=0x0)
    at
/120g/gar/python/python23/work/Python-2.3.3/Modules/pyexpat.c:888
#4  0x080fc25a in PyCFunction_Call (func=0x402faa0c,
arg=0x402f338c, 
    kw=0xfffffffb) at Objects/methodobject.c:108
#5  0x080aa674 in call_function (pp_stack=0xbffff03c,
oparg=0)
    at Python/ceval.c:3439
#6  0x080a8a2e in eval_frame (f=0x816e45c) at
Python/ceval.c:2116
#7  0x080a95bc in PyEval_EvalCodeEx (co=0x40303de0,
globals=0xfffffffb, 
    locals=0x0, args=0x816e5a8, argcount=2,
kws=0x816a9fc, kwcount=0, 
    defs=0x40321678, defcount=1, closure=0x0) at
Python/ceval.c:2663
#8  0x080aa729 in fast_function (func=0xfffffffb,
pp_stack=0xbffff1bc, n=2, 
    na=0, nk=135703028) at Python/ceval.c:3529
#9  0x080aa56c in call_function (pp_stack=0xbffff1bc,
oparg=0)
    at Python/ceval.c:3458
#10 0x080a8a2e in eval_frame (f=0x816a894) at
Python/ceval.c:2116
#11 0x080a95bc in PyEval_EvalCodeEx (co=0x402fd2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x402f3318, argcount=2, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#12 0x080fbda7 in function_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/funcobject.c:504
#13 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#14 0x08062288 in instancemethod_call (func=0x4030617c,
arg=0x402f330c, kw=0x0)
    at Objects/classobject.c:2433
#15 0x0805b899 in PyObject_Call (func=0x40682000,
arg=0x0, kw=0x0)
    at Objects/abstract.c:1755
#16 0x080aa892 in do_call (func=0x4032025c,
pp_stack=0x402f330c, na=0, nk=0)
    at Python/ceval.c:3644
#17 0x080aa4f9 in call_function (pp_stack=0xbffff5fc,
oparg=0)
    at Python/ceval.c:3460
#18 0x080a8a2e in eval_frame (f=0x818b414) at
Python/ceval.c:2116
#19 0x080aa7ad in fast_function (func=0xfffffffb,
pp_stack=0xbffff71c, n=2, 
    na=0, nk=1076865996) at Python/ceval.c:3518
#20 0x080aa56c in call_function (pp_stack=0xbffff71c,
oparg=0)
    at Python/ceval.c:3458
#21 0x080a8a2e in eval_frame (f=0x8183814) at
Python/ceval.c:2116
#22 0x080a95bc in PyEval_EvalCodeEx (co=0x402ed2a0,
globals=0xfffffffb, 
    locals=0x0, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
    defcount=0, closure=0x0) at Python/ceval.c:2663
#23 0x080abdb9 in PyEval_EvalCode (co=0x0, globals=0x0,
locals=0x0)
    at Python/ceval.c:537
#24 0x080d7d2b in run_node (n=0x402bb79c, filename=0x0,
globals=0x0, 
    locals=0x0, flags=0x0) at Python/pythonrun.c:1265
#25 0x080d74df in PyRun_SimpleFileExFlags (fp=0x8139050, 
    filename=0xbffffa4d "testexpat.py",
closeit=-1073743283, flags=0xbffff878)
    at Python/pythonrun.c:862
#26 0x08054dd5 in Py_Main (argc=1, argv=0xbffff8f4) at
Modules/main.c:415
#27 0x0805492b in main (argc=0, argv=0x0) at
Modules/python.c:23


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

Comment By: Jozef Behran (jojoworks)
Date: 2004-03-19 23:45

Message:
Logged In: YES 
user_id=688090

Result of a brief scan:

When the exceptional situation happens, the pyexpat.c module
trashes parser->m_positionPtr (aliased as positionPtr) (see
modules/expat/xmlparse.c, function
XML_GetCurrentLineNumber() and similar). When the
errorhandler forgets to raises an exception or exit, the
module tries to access memory through the garbage pointer
and segfaults.

It seems to be buffer overrun bug: the pointer gets thrashed
when some sort of input (the erroneous entity) is large
enough to reach it (or variable from which the pointer is
fetched).

It is impossible for me to do further investigations because
gdb/Mangrake GNU/Linux refuses to trace dlopen()ed shared
object and I don't understand it's code enough to "debug" it
by hand.

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

Comment By: Mark Moraes (moraes)
Date: 2004-03-15 11:26

Message:
Logged In: YES 
user_id=390363

#! /usr/bin/env python

dhead = """<?xml version="1.0" encoding="ISO-8859-1" ?>
<item><title>&#187</title></item>
<item><title>
"""
dtail = """</title></item>
"""

import xml.sax
from cStringIO import StringIO as _StringIO

class _StrictFeedParser:
    def _err(self, errtype, exc):
        print errtype, exc.getMessage(),             'line', exc.getLineNumber(),             'column', exc.getColumnNumber()
    def fatalError(self, exc):
        self._err('fatalError', exc)
        # raise exc # avoids the problem
    def error(self, exc):
        self._err('error', exc)
    def warning(self, exc):
        self._err('warning', exc)

def parse(data):
    feedparser = _StrictFeedParser()
    saxparser = xml.sax.make_parser(["drv_libxml2"])
    saxparser.setErrorHandler(feedparser)
    source = xml.sax.xmlreader.InputSource()
    source.setByteStream(_StringIO(data))
    saxparser.parse(source)

if __name__ == '__main__':
    for i in xrange(65427,66000,1):
        print i
        parse(dhead + 'x'*i + dtail)

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

Comment By: Mark Moraes (moraes)
Date: 2004-03-15 11:22

Message:
Logged In: YES 
user_id=390363

I ran into this as well -- turns out that 64k is relevant: I
have a simpler script that reproduces this problem -- create
an unterminated character ref such as "&#171" without the
trailing semi-colon and add roughly 64k of data after it. 
The crash occurs if the sax parser has an ErrorHandler set
where the fatalError() method returns normally instead of
terminating/raising the exception.

As a defensive measure, I suggest that any call to the
fatalError method be followed by a raise of the exception if
fatalError returns.


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

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

From noreply at sourceforge.net  Sat Mar 20 11:14:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 11:15:01 2004
Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in
	issubclass
Message-ID: <E1B4j7e-00086M-00@sc8-sf-web1.sourceforge.net>

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

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Eric M. Hopper (omnifarious)
Assigned to: Brett Cannon (bcannon)
Summary: Pathological case segmentation fault in issubclass

Initial Comment:
This works for the PowerPC Python compiled with gcc 3.3
on OS X using fink.  I suspect it&#039;s broader based than
that, but I don&#039;t have the ability to check properly.

Here&#039;s how to make it segment fault:

x = (basestring,)
for i in xrange(0, 1000000):
   x = (x,)
issubclass(str, x)

At least, it segment faults at the interactive prompt
this way.  I don&#039;t know if it does when it&#039;s executed
from a file.


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 08:14

Message:
Logged In: YES 
user_id=357491

Have a patch for Python 2.3 that limits the depth of the tuples to the 
recursion limit of the interpreter.  That will definitely be used for 2.3  
Question is which solution to use for 2.4 .

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

Comment By: Tim Peters (tim_one)
Date: 2004-02-16 15:44

Message:
Logged In: YES 
user_id=31435

Well, that wasn't as much fun for you as I hoped -- the 
report just sat there until I got a free holiday <wink>.  Marked 
Accepted and back to you -- looks good!

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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-18 21:24

Message:
Logged In: YES 
user_id=357491

OK, Tim, start hopping.  =)

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

Comment By: Tim Peters (tim_one)
Date: 2003-12-18 13:48

Message:
Logged In: YES 
user_id=31435

Oh, Brett, you're missing a chance for some fun here!  A bug 
should always be assigned to the next person who should "do 
something" about it.  Think of it as a hot potato.  You should 
assign the bug to who you *want* to review this, and then 
sit back and watch the fun, as each person in turn tries to 
unload the potato onto someone else.  That's one way to get 
a comforting illusion of activity here <wink>.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-18 13:39

Message:
Logged In: YES 
user_id=357491

I have appended a file that adds a basic test to make sure that 
when the items of a tuple are used to call isinstance or issubclass 
that only classes or types are used; everything else raises 
TypeError.  Also tried to clarify the wording of the doc strings.  
Changed the docs for isinstance since it allowed nested tupling 
while issubclass' didn't.

Have a look and if someone will sign off on it I will apply the patch 
and then start working on a 2.3 solution that doesn't break 
semantics.

And I just realized I left out a Misc/NEWS in the patch; it will be 
there when it gets applied.

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

Comment By: Tim Peters (tim_one)
Date: 2003-12-14 13:09

Message:
Logged In: YES 
user_id=31435

I'm afraid that changing semantics needs to be run through 
the python-dev wringer first -- "shouldn't break very much 
code" isn't "shouldn't break any code".  The *comments* in 
these functions make it appear that they never intended to 
support the OP's original code snippet, but the docs don't 
match.  This leaves the intent a mystery, so it needs to be 
discussed.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-14 12:55

Message:
Logged In: YES 
user_id=357491

OK, consider my worldview fixed.  =)

I will add a check in the tuple unpacking 'for' loop to make sure it 
is only passing issubclass classes and not more tuples.  Simple 
and shouldn't break very much code.  Otherwise the code would 
have to keep a count and extra bookkeeping and it would get 
messy quickly.

And I will take a look at isinstance, although this tuple feature was 
added in 2.3 for issubclass so it might not be an issue.

And I will backport it.

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

Comment By: Tim Peters (tim_one)
Date: 2003-12-13 17:08

Message:
Logged In: YES 
user_id=31435

Yes, this needs to be fixed if it *can* be fixed without heroic 
effort or insane slowdown.  Looks like it can be.

Brett, the missing piece of your worldview <wink> here is that 
anywhere Python can be tricked into segfaulting is a kind 
of "security hole" -- it's not just mistakes we want to protect 
programmers from, we also want to bulletproof against hostile 
users, to the extent sanely possible.

BTW, if issubclass() has this insecurity, I bet isinstance() 
does too (they were introduced & coded at the same time).

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

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-11 09:54

Message:
Logged In: YES 
user_id=313

Well, I think any case where the system segment faults
unexpectedly is bad, regardless of how pathological it is.

Personally, I think that issubclass should either have a
recursion limit after which it throws an exception, or it
shouldn't go into sub-tuples at all.

The reason I made this test is that I read the description
of the behavior of issublcass and found it rather strange,
so I decided to push it to see how far it would go.


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

Comment By: Brett Cannon (bcannon)
Date: 2003-12-10 20:28

Message:
Logged In: YES 
user_id=357491

If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you 
will notice that PyObject_IsSubclass goes into a 'for' loop for each 
item in the tuple passed in and calls PyObject_IsSubclass .  
Unfortunately it makes no check for whether the argument it is 
passing is a class itself or not.  This allows it to keep making calls 
as long as the second argument is either a class or a tuple.  This 
is what is leads to the stack being blown and the subsequent 
segfault.

Obvious solution is to put in a check that the argument about to be 
passed is a class itself so as to not have such a deep call chain.  
But since ``help(issubclass)`` actually makes the above use legit 
(it says using a tuple as a second argument is equivalent as 
passing each item to issubclass which is what it is doing, albeit in 
a rather uncommon and pointless way), is it worth putting the 
check in?  Since this is such an obvious mis-use, I say no.  But if 
someone else on python-dev steps in and says otherwise I will 
patch it.

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

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-10 19:16

Message:
Logged In: YES 
user_id=313

I forgot this:

Python 2.3.2 (#1, Dec  4 2003, 09:13:58) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.


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

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

From noreply at sourceforge.net  Sat Mar 20 12:32:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 12:32:47 2004
Subject: [ python-Bugs-883604 ] locale specific problem in test_strftime.py
Message-ID: <E1B4kKm-0004qN-00@sc8-sf-web3.sourceforge.net>

Bugs item #883604, was opened at 2004-01-24 05:21
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883604&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 3
Submitted By: George Yoshida (quiver)
Assigned to: Brett Cannon (bcannon)
Summary: locale specific problem in test_strftime.py

Initial Comment:
test/test_strftime.py compares an expectation and a 
result by regular expressions, but the pattern isn&#039;t 
escaped. So if the expectation includes a metacharacter,
  expectation == result
and
  re.match(expectation, result)
do not always return the same value.

In my case on Japanese Windows, time.tzname returns
  (&#039;\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;, &#039;\x93
\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;)
The output contains parentheses. 
This resuls in a message:
  Conflict for nonstandard &#039;%Z&#039; format (time zone name):
    Expected ???? (?W????), but got ???? (?W????)
re.match(foo, bar) != (foo == bar)

One workaround I can think of is changing re.match(e
[1], result) back to result == e[1].


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 09:32

Message:
Logged In: YES 
user_id=357491

George, can you apply the attached  patch and let me know if it solves 
the problem?

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

Comment By: Brett Cannon (bcannon)
Date: 2004-01-29 18:23

Message:
Logged In: YES 
user_id=357491

That's not what I meant by the comment; sorry for not being 
clearer.  I meant is whether test_strftime's existence is because of 
Jython.

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

Comment By: George Yoshida (quiver)
Date: 2004-01-29 03:54

Message:
Logged In: YES 
user_id=671362

> Is  this for Jython or something?
No, it's Python 2.3.3 on Windows 2000.

time zone is classified as non standard(unpredictable) so it 
might be difficult to make test_stftime.py to support all 
locales. There are so many issues.

FYI, I checked time.tzname on other platforms.

# Jython
Jython 2.1 on java1.4.2 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname
('JST', 'JST')  # Japanese Standard Time

# Linux
On RHL 9.0(Python 2.2/2.3), time.tzname returns ('JST', 'JST').

They pass the test.


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

Comment By: Brett Cannon (bcannon)
Date: 2004-01-27 00:28

Message:
Logged In: YES 
user_id=357491

Does anyone know why we even have test_strftime?  It isn't like 
we have our own implementation and there are basic tests in 
test_time to make sure the wrapper around the C function works.  
I know the test module says it is for sanity checks, but if it fails 
legitimately on a platform there is not much we can do about it.  
Is this for Jython or something?

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

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

From noreply at sourceforge.net  Sat Mar 20 13:28:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 13:28:21 2004
Subject: [ python-Bugs-918371 ] hasattr()'s return type
Message-ID: <E1B4lCh-0001d7-00@sc8-sf-web4.sourceforge.net>

Bugs item #918371, was opened at 2004-03-17 17:42
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918371&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: [N/A] (ymasuda)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: hasattr()'s return type

Initial Comment:
>From Python 2.3, hasattr() has been changed to return 
boolean instead of integer:1 or 0. But libfunc.tex still 
describes older specification. Please fix it.

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

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

From noreply at sourceforge.net  Sat Mar 20 13:37:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 13:37:09 2004
Subject: [ python-Bugs-918371 ] hasattr()'s return type
Message-ID: <E1B4lLF-00027A-00@sc8-sf-web3.sourceforge.net>

Bugs item #918371, was opened at 2004-03-17 17:42
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918371&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: [N/A] (ymasuda)
Assigned to: Raymond Hettinger (rhettinger)
Summary: hasattr()'s return type

Initial Comment:
>From Python 2.3, hasattr() has been changed to return 
boolean instead of integer:1 or 0. But libfunc.tex still 
describes older specification. Please fix it.

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

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-20 13:37

Message:
Logged In: YES 
user_id=80475

Okay, fixed.

Thanks for the report.

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

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

From noreply at sourceforge.net  Sat Mar 20 13:52:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 13:52:25 2004
Subject: [ python-Bugs-839585 ] String formatting operator % badly documented
Message-ID: <E1B4lZx-0003cM-00@sc8-sf-web4.sourceforge.net>

Bugs item #839585, was opened at 2003-11-10 17:11
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Siemer (siemer)
Assigned to: Nobody/Anonymous (nobody)
Summary: String formatting operator % badly documented

Initial Comment:
Hello everyone!

The % operator works with strings, but this is hard to
find in the documentation (Library Reference 2.2.6.2).

Really bad is, that an operator should be documented in
the Language Reference, where it isn&#039;t.

Lang-Ref "5.6 Binary arithmetic operations" is labeled
wrong, as it also describes the non-arithmetic
operations of + and * but seems to know nothing about %
under that aspect...
It is actually indirectly saying that there is no
further non-arithmetic operation - but there is: %.


Rob

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

Comment By: Michael Chermside (mcherm)
Date: 2004-03-20 13:52

Message:
Logged In: YES 
user_id=99874

Good point, this has long bothered me too.

I'm attaching a patch. Fred, can you review (make sure I
didn't introduce broken tex syntax) and check in?

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

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

From noreply at sourceforge.net  Sat Mar 20 13:58:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 13:59:02 2004
Subject: [ python-Bugs-839585 ] String formatting operator % badly documented
Message-ID: <E1B4lgO-0000UD-00@sc8-sf-web2.sourceforge.net>

Bugs item #839585, was opened at 2003-11-10 17:11
Message generated for change (Settings changed) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Siemer (siemer)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: String formatting operator % badly documented

Initial Comment:
Hello everyone!

The % operator works with strings, but this is hard to
find in the documentation (Library Reference 2.2.6.2).

Really bad is, that an operator should be documented in
the Language Reference, where it isn&#039;t.

Lang-Ref "5.6 Binary arithmetic operations" is labeled
wrong, as it also describes the non-arithmetic
operations of + and * but seems to know nothing about %
under that aspect...
It is actually indirectly saying that there is no
further non-arithmetic operation - but there is: %.


Rob

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

Comment By: Michael Chermside (mcherm)
Date: 2004-03-20 13:52

Message:
Logged In: YES 
user_id=99874

Good point, this has long bothered me too.

I'm attaching a patch. Fred, can you review (make sure I
didn't introduce broken tex syntax) and check in?

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

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

From noreply at sourceforge.net  Sat Mar 20 14:00:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 14:00:57 2004
Subject: [ python-Bugs-839585 ] String formatting operator % badly documented
Message-ID: <E1B4liG-0000fP-00@sc8-sf-web2.sourceforge.net>

Bugs item #839585, was opened at 2003-11-10 17:11
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Siemer (siemer)
>Assigned to: Nobody/Anonymous (nobody)
Summary: String formatting operator % badly documented

Initial Comment:
Hello everyone!

The % operator works with strings, but this is hard to
find in the documentation (Library Reference 2.2.6.2).

Really bad is, that an operator should be documented in
the Language Reference, where it isn&#039;t.

Lang-Ref "5.6 Binary arithmetic operations" is labeled
wrong, as it also describes the non-arithmetic
operations of + and * but seems to know nothing about %
under that aspect...
It is actually indirectly saying that there is no
further non-arithmetic operation - but there is: %.


Rob

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

>Comment By: Michael Chermside (mcherm)
Date: 2004-03-20 14:00

Message:
Logged In: YES 
user_id=99874

Two thoughts I had after attaching that patch.
(1) If there's a way to create inter-document links, that
would be a good idea. I don't know of one.
(2) If the format of this patch is a pain, let me know. All
I'm doing is adding one paragraph.

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

Comment By: Michael Chermside (mcherm)
Date: 2004-03-20 13:52

Message:
Logged In: YES 
user_id=99874

Good point, this has long bothered me too.

I'm attaching a patch. Fred, can you review (make sure I
didn't introduce broken tex syntax) and check in?

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

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

From noreply at sourceforge.net  Sat Mar 20 14:01:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 14:01:52 2004
Subject: [ python-Bugs-839585 ] String formatting operator % badly documented
Message-ID: <E1B4lj2-0006ho-00@sc8-sf-web1.sourceforge.net>

Bugs item #839585, was opened at 2003-11-10 17:11
Message generated for change (Settings changed) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=839585&group_id=5470

Category: Documentation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Robert Siemer (siemer)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: String formatting operator % badly documented

Initial Comment:
Hello everyone!

The % operator works with strings, but this is hard to
find in the documentation (Library Reference 2.2.6.2).

Really bad is, that an operator should be documented in
the Language Reference, where it isn&#039;t.

Lang-Ref "5.6 Binary arithmetic operations" is labeled
wrong, as it also describes the non-arithmetic
operations of + and * but seems to know nothing about %
under that aspect...
It is actually indirectly saying that there is no
further non-arithmetic operation - but there is: %.


Rob

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

Comment By: Michael Chermside (mcherm)
Date: 2004-03-20 14:00

Message:
Logged In: YES 
user_id=99874

Two thoughts I had after attaching that patch.
(1) If there's a way to create inter-document links, that
would be a good idea. I don't know of one.
(2) If the format of this patch is a pain, let me know. All
I'm doing is adding one paragraph.

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

Comment By: Michael Chermside (mcherm)
Date: 2004-03-20 13:52

Message:
Logged In: YES 
user_id=99874

Good point, this has long bothered me too.

I'm attaching a patch. Fred, can you review (make sure I
didn't introduce broken tex syntax) and check in?

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

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

From noreply at sourceforge.net  Sat Mar 20 16:10:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 16:10:30 2004
Subject: [ python-Bugs-625698 ] Errors with recursive objects
Message-ID: <E1B4njU-0004mo-00@sc8-sf-web3.sourceforge.net>

Bugs item #625698, was opened at 2002-10-19 15:27
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=625698&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Erik Anders?n (erik_andersen)
Assigned to: Jeremy Hylton (jhylton)
Summary: Errors with recursive objects

Initial Comment:
List and dictionaries put Python into an infinite loop if they contain 
more than one reference to itself

>>> d = {}
>>> d[1] = 
d
>>> d == d  # OK Python can handle one 
recursion
1
>>> d[2] = d 
>>> d == d  # Crash with 
two

Lists are similar

>>> l=[]
>>> 
l.append(l)
>>> l==l  # OK
1
>>> l.append(l)
>>> 
l==l # Crash

>>> l>l  # Also crash

Tested with 
ActivePython 2.2.1 under Windows 98
and (the first part) 
Python 2.2.2 under Linux


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

>Comment By: Tim Peters (tim_one)
Date: 2004-03-20 16:10

Message:
Logged In: YES 
user_id=31435

Python 2.4 was changed so that all these examples yield

RuntimeError: maximum recursion depth exceeded in cmp

so closing this as Fixed.

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

Comment By: Michael Stone (mbrierst)
Date: 2003-02-25 17:03

Message:
Logged In: YES 
user_id=670441

I have posted patch 693221 which I believe will
quickly evaluate all examples given on this page.
There's some discussion there.
Feel free to argue with it.

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

Comment By: Armin Rigo (arigo)
Date: 2003-01-29 09:11

Message:
Logged In: YES 
user_id=4771

Bisimulation is a cool tool that only works in
"monotonic" settings, i.e. when the set of pairs of
objects known to be equal is always growing and
objects cannot become different when other objects
are discovered to be equal.  So the whole
bisimulation thing is inconsistent with user-defined
comparisons because these can use negations
(there is no negation in the standard list and dict
compares).

I think the language definition should stick to the
simple recursive definition of comparison, and
thus be allowed to enter an infinite recursion.
The interpreter should be Ctrl-C interruptible and
raise a "RuntimeError: maximum recursion depth
exceeded".  This is similar to instance_call() in
classobject.c.

In particular I think the interpreter should not try
to detect loops explicitely.  Consider the case
of someone who really wants to implement a
bisimulation thing:

>>> class X:
...   def __eq__(self, other):
...      if (self, other) in already_comparing:
...         return True
...      else:
...         ...

We must allow the same object's __eq__()
method to be entered twice without raising
any exception.  I would say that the problem
is similar to:

>>> def f():
...    f()

It is not the interpreter's role to detect the loop
and raise an exception, but only to crash nicely
when the recursion depth becomes critically large.


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-23 13:57

Message:
Logged In: YES 
user_id=31435

I'll attach a patch with a simple recursion latch.  It handles 
the small examples fine.  Make them bigger and sloth 
returns, though; e.g., this one takes more than 20 seconds 
after the patch (but longer than the lifetime of the universe 
without the patch):

N = 1000

print "building a"
a = []
for i in range(N): a.append(a)

print "building b"
b = []
for i in range(N): b.append(b)

print "comparing"
print a == b

So long as inprogress entries don't outlive the comparison 
call that created them, it still leaves exponentially-
compounding overhead to keep on recreating the entries that 
used to exist.  But if an inprogress entry does outlive the 
comparison that created it, then the cached addresses may 
end up attached to objects other than the original 
comparands, and how to get each thread to eventually clear 
its inprogress dict becomes a puzzle and/or an expense.

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

Comment By: Jeremy Hylton (jhylton)
Date: 2003-01-23 13:15

Message:
Logged In: YES 
user_id=31392

Maybe I need to read the code again, but IIRC the code
doesn't assume that id(a) == id(b) implies a == b.  Rather
it uses id(a) and id(b) to look for recursive calls to
compare.  It assumes that a == b will always produce the
same result when invoked recursively within a comparison.

I think a decent solution is to create a latch for the
nesting limit.  If a comparison ever exceeds the recursion
limit, the check is done until the comparison is finished.


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-21 22:09

Message:
Logged In: YES 
user_id=31435

llit, you should study the current code before suggesting an 
algorithm.  The current code would be blazing fast if it were 
looking for recursion from the start too.  But the very 
process of building that dict with the ids of the objects as 
keys (which the current algorithm also does) costs more 
than most comparisons cost in real life.  That's why the 
current code doesn't even try to catch recursion until the 
comparison level exceeds 20, and that's where the sloth 
comes from.  Stick a gimmick like that in your algorithm, 
and you'll have similar speed problems.

Also note that id(a)  == id(b) doesn't imply a == b (see 
the other note about NaN for an example).

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

Comment By: Till Plewe (llit)
Date: 2003-01-21 01:01

Message:
Logged In: YES 
user_id=540660

How about checking for equality by trying to build a
bisimulation
which "proves" equality. 

Time complexity is O(nodes(a) x nodes(b))  

SAMPLE PYTHON CODE
===============================
#! /usr/bin/env python

from types import *
SeqType=[ListType,DictType,TupleType]

def isequal(a,b):
    if id(a)==id(b): return True
    compare={(id(a),id(b)):(a,b)}
    bisimilar={}
    
    while compare:
        (ida,idb),(oba,obb)=compare.popitem()
        if ida==idb:
            continue
        elif type(oba)==type(obb):
            if type(oba) not in SeqType:
                if oba!=obb:
                    return False
                else:
                    continue
            elif len(oba)!=len(obb):
                return False
            elif (ida,idb) not in bisimilar:
                bisimilar[(ida,idb)]=1
                if type(oba)==DictType:
                    for x in oba: #oba and obb have the same
number of keys
                        if x not in obb:
                            return False
                        else:
                           
compare[(id(oba[x]),id(obb[x]))]=(oba[x],obb[x])
                else:
                    for x,y in zip(oba,obb):
                        compare[(id(x),id(y))]=(x,y)
        else:
            return False
    return bisimilar


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

Comment By: Tim Peters (tim_one)
Date: 2003-01-20 15:44

Message:
Logged In: YES 
user_id=31435

Cool.  He's right that they can take a horrendously long time.  
The 2-element list example takes c*2**20 units of time, for 
some suitable constant c, and if it were extended to 3 
elements, it would take c*3**20 units of time, thousands of 
times longer.

As Erik's latest example shows, the outcome isn't always 
particularly well defined either.  An alternative to speeding this 
silliness is to raise an exception instead when recursive 
objects are detected.  There was some hack value in doing 
the graph isomorphism bit, but no real practical value I can 
see.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-20 15:20

Message:
Logged In: YES 
user_id=33168

Sorry Tim, I was going to reply to one of your first msgs
and forgot.  Erik sent me mail which said there wasn't a
crash, just that "the statements take horrendously long time
to execute."

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-20 15:09

Message:
Logged In: YES 
user_id=31435

BTW, Erik, what did you mean by "crash"?  Nobody else has 
seen a crash here.  You started the report by saying "infinite 
loop", which isn't the same thing as a crash.  There isn't an 
infinite loop here either, although the algorithm can take 
astronomical amounts of time to finish (so may appear to be 
in an infinite loop).

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-20 14:50

Message:
Logged In: YES 
user_id=31435

Equailty for self-consistent recursive objects does a graph 
isomorphism computation.

In your self-inconsistent example, it so happens that False is 
returned, although True would be returned if the compile-time 
constant (in object.c) NESTING_LIMIT were odd instead of 
even.

But if you worry about this, you need to get out more <wink>.

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

Comment By: Erik Anders?n (erik_andersen)
Date: 2003-01-20 14:24

Message:
Logged In: YES 
user_id=364358

Excuse me for interupting the efficiency discussion, but what is the 
definition of equality for recursive containers.  I am particularly worrided 
about cases like 

>>> class A:
... 	def __eq__(self,other): 
return not self.u==other.u
... 	
>>> a=A()
>>> l=[a]
>>> 
a.u=l
>>> l==l # ????

If l==l then a!=a and l[0]!=l[0], so 
l!=l.
If l!=l then a==a and l[0]==l[0], so l==l !!!!!!!

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-20 11:12

Message:
Logged In: YES 
user_id=31435

I deleted my patch -- it didn't make sense.

Martin, AFAIK the docs say nothing about the relationship (if 
any) between "is" and "==".  It was deliberate intent that "is" 
not imply "==" for rich comparisons, though, in part so that 
IEEE-754 rules for NaN could be implemented by users.

>>> class NaN:
...     def __eq__(self, other): return False
...
>>> n = NaN()
>>> n is n
True
>>> n == n
False
>>>

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-01-20 03:20

Message:
Logged In: YES 
user_id=21627

Where does the documentation say that "is" may not imply ==?
The check for recursion assumes this implication, anyway: if
we meet the very same object, we infer that they are equal.

What is the purpose of clear_inprogress_dict in your patch?

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

Comment By: Tim Peters (tim_one)
Date: 2003-01-19 23:28

Message:
Logged In: YES 
user_id=31435

The patch assumes "is" implies "==", which isn't necessarily 
so for rich comparisons.

The attached patch cuts the time about in half, via:

1. Getting rid of the per-thread inprogress dicts, in favor of 
a shared inprogress dict.

2. Restoring the intent of the code that tuples be exempted 
(tuples can't be recursive).  Rev 2.65 of tupleobject.c gave 
tuples a tp_as_mapping slot, breaking the intent of the 
code.

3. Changing the inprogress dict to map a tuple to the 
smallest value of compare_nesting at which the tuple was 
seen.  delete_token() was changed to leave the token alone 
if the current compare_nesting value is greater than that.  
This allows tuples to stay in the dict longer.

4. Cutting NESTING_LIMIT from 20 to 19.  This has a huge 
effect, because the algorithm is still basically exponential-
time.

The problem remaining is that the inprogress dict is still 
useless (and empty) so long as compare_nesting is less 
than NESTING_LIMIT.  This can leave an exponential 
amount of work to be done to fight back up to 
NESTING_LIMIT.

Leaving stuff in inprogress longer, and consulting inprogress 
regardless of the value of compare_nesting (provided that's 
gone over NESTING_LIMIT at least once) slashes the time 
to triviality.  However, it isn't safe:  we can't know that the 
addresses in the dict keys refer to the same objects then.  
We could if started storing into inprogress from the very 
start, but that would be a big speed hit for usual-case 
comparisons.  I'd be happy to knock NESTING_LIMIT down 
more, though.

Assigned to Jeremy, as IIRC this was his code originally.

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

Comment By: Martin v. L?wis (loewis)
Date: 2003-01-19 12:30

Message:
Logged In: YES 
user_id=21627

The patch is fine, except that a comment needs to be added
explaining what this does and why it does that.

It should be understood that this can't fix the very similar
case

a = []
a.append(a)
a.append(a)

b = []
b.append(b)
b.append(b)

a==b

This would still take a long time, right?

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-19 11:05

Message:
Logged In: YES 
user_id=33168

Attached is a patch which fixes the problem for me.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-07 19:59

Message:
Logged In: YES 
user_id=33168

Erik, do you still have this problem with 2.2.2?  I can't
reproduce your problem under Linux.  mly can't reproduce the
problems with 2.2.1 on Windows (2000).  Do you only have the
problem on Windows?  

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

Comment By: Magnus Lyck? (mly)
Date: 2002-10-26 19:12

Message:
Logged In: YES 
user_id=95217

I tried the above under 

Python 2.2.1 (#34, Sep 27 2002, 18:37:42) [MSC 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
(ActiveState on Win 2000)

and 

Python 2.1.1 (#1, Aug 20 2001, 20:23:29)
[GCC 2.96 20000731 (Mandrake Linux 8.1 2.96-0.60mdk)] on
linux-i386

In both cases it works correctly. No crash.
It takes a lot of time though, Several seconds
on Duron 700 w/ Win2k, and tens of seconds 
on K6-233 w/ Linux.



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

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

From noreply at sourceforge.net  Sat Mar 20 16:25:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 16:26:17 2004
Subject: [ python-Bugs-919605 ] os.rename() silently overwrites files
Message-ID: <E1B4nyX-000430-00@sc8-sf-web2.sourceforge.net>

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

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Jozef Behran (jojoworks)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.rename() silently overwrites files

Initial Comment:
Python 2.2.2 from Mandrake GNU/Linux 9.0

os.rename() should throw an exception when the program
tries to rename file to an existing filename. Such a
situation is namely usually caused by a bug in the
calling program. The current behavior (silently
replacing old file content with the new one) is
dangerous to programmer&#039;s data.

If the program wants to overwrite files, it can use

try:
  os.rename(old,new)
except IOError:
  os.unlink(new)
  os.rename(old,new)

or something similar to do so.

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

>Comment By: Phillip J. Eby (pje)
Date: 2004-03-20 21:25

Message:
Logged In: YES 
user_id=56214

This behavior is as documented.  See:

http://www.python.org/doc/2.2/lib/os-file-dir.html

under 'rename' for details.

Note that 'os.rename' is specifically *intended* to expose
the underlying platform's rename behavior.  On Unix-like
operating systems, this means overwriting the destination,
if present.

Unfortunately, neither Unix nor Windows can safely emulate
the other OS's behavior here, without causing potential race
conditions in a multi-user or multi-process environment. 
Note, for instance, that your example code does not
correctly emulate os.rename()'s current Unix behavior,
because other processes could change the filesystem state
between the various lines of code.

Thus, Python chooses to expose the underlying OS' semantics,
rather than trying to provide a "one-size-fits-all" behavior
which may not be what you want.  For example, in most
applications that I write, I would rather be able to have
the behavior that you are objecting to, because it allows
atomic modifications to files.  But, Windows does not
support this, which means I must use a different approach
there.  In the same way, Unix does not support Windows'
approach (disallowing overwrite).


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

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

From noreply at sourceforge.net  Sat Mar 20 16:28:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 16:28:57 2004
Subject: [ python-Bugs-700055 ] site.py should ignore trailing CRs in .pth
	files
Message-ID: <E1B4o1T-0007PI-00@sc8-sf-web4.sourceforge.net>

Bugs item #700055, was opened at 2003-03-08 11:39
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=700055&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Dan Everhart (d_everhart)
Assigned to: Nobody/Anonymous (nobody)
Summary: site.py should ignore trailing CRs in .pth files

Initial Comment:
When site.addpackage(), running on a posix (e.g. 
cygwin or linux) system, reads lines from a .pth file that 
have &#039;\r\n&#039; line terminators, the carriage return character 
interferes with both the import operation and the 
directory appending operation.

The situation can arise, for example, when .pth files 
reside on a network directory that is shared between 
Windows and Posix installations and accessed by 
python interpreters running in both environments.

Suggested change:
replace site.py line 146:
        dir = f.readline()
with
        dir = f.readline().rstrip()
This change also eliminates the need for removing the 
newline at lines 154-155




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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 13:28

Message:
Logged In: YES 
user_id=357491

Fixed Lib/site.py as rev. 1.58 in Python 2.4 and rev. 1.53.6.5 in Python 
2.3 .

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

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 14:26

Message:
Logged In: YES 
user_id=357491

Would opening the file with universal newlines solve the issue?

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

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

From noreply at sourceforge.net  Sat Mar 20 16:42:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 16:42:18 2004
Subject: [ python-Bugs-693255 ] 2.3a2 site.py non-existing dirs
Message-ID: <E1B4oEJ-0008Np-00@sc8-sf-web4.sourceforge.net>

Bugs item #693255, was opened at 2003-02-25 14:44
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470

Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: James P Rutledge (jrut)
Assigned to: Just van Rossum (jvr)
Summary: 2.3a2 site.py non-existing dirs

Initial Comment:
In Python 2.3a2 the site.py leaves non-existing
directories in sys.path.

On my Debian Linux system, using Python 2.3a2,
the sys.path, after site.py is executed during
interpreter initialization, includes the entry

   /usr/local/lib/python23.zip

although no such directory currently exists on
my system.

The module documentation contained in site.py does
state

  "Non-existing directories (or non-directories)
  are never added to sys.path"


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

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 13:42

Message:
Logged In: YES 
user_id=357491

In Python 2.4, rev. 1.59 has site.py remove non-existing paths.

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

Comment By: Brett Cannon (bcannon)
Date: 2003-07-07 21:11

Message:
Logged In: YES 
user_id=357491

Can someone with more experience with the "official" policy of of 
site.py say whether or not the docs should be changed or site.py 
itself?

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

Comment By: James P Rutledge (jrut)
Date: 2003-05-29 12:20

Message:
Logged In: YES 
user_id=720847

I do not know what policy is desired for the condition of
the path after executing site.py.

I found the problem when I switched to try 2.3 and used an
application I wrote which searches the path to obtain
information about installed  modules.  During
troubleshooting, the change in site.py from 2.2 to 2.3, to
stop removing non-existent directories in the path, became
evident as the reason for the application finding a
non-existent directory in the path.

The application was, of course, easily changed to skip
non-existent directories.  The question is whether removing
of non-existent directories in the path _should_ be done by
site.py


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

Comment By: Brett Cannon (bcannon)
Date: 2003-05-28 18:33

Message:
Logged In: YES 
user_id=357491

I take it the docs are what needs to change and not site.py?

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

Comment By: Just van Rossum (jvr)
Date: 2003-02-26 00:43

Message:
Logged In: YES 
user_id=92689

The docs are indeed wrong.

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-25 19:08

Message:
Logged In: YES 
user_id=33168

Just, does the doc still need to be updated?

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

Comment By: James P Rutledge (jrut)
Date: 2003-02-25 18:56

Message:
Logged In: YES 
user_id=720847

Additional info -- the site.py used in
Python 2.2.2 explicitly removes non-existing
and non-directory files from sys.path.

The Python 2.3 site.py does not have that
feature.


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

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

From noreply at sourceforge.net  Sat Mar 20 17:29:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 17:29:15 2004
Subject: [ python-Bugs-777848 ] CGIHTTPServer and urls
Message-ID: <E1B4oxq-0000CH-00@sc8-sf-web2.sourceforge.net>

Bugs item #777848, was opened at 2003-07-25 18:41
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=777848&group_id=5470

Category: Python Library
Group: Python 2.2
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: vincent delft (vincent_delft)
Assigned to: Guido van Rossum (gvanrossum)
Summary: CGIHTTPServer and urls

Initial Comment:
If you have 2 differents CGI.  
On the both you ask to print the content of cgi.FieldStorage. 
 
You will see that URL paramters (after ? in the url) remains. 
 
For our example : 
1) http://localhost:8080/cgi-bin/script1.py?action=test 
Will display the parameter name &#039;action&#039; and his value &#039;test&#039; 
BUT, now you ask the second url 
2) http://localhost:8080/cgi-bin/script2.py 
you still see the previous parameter &#039;action&#039; with the previous 
value &#039;test&#039; 
 
I&#039;ve resolve the problem by removing a test in the 
CGIHTTPServer.py script. 
line +- 149 
-        if query: 
-            env[&#039;QUERY_STRING&#039;] = query 
+       env[&#039;QUERY_STRING&#039;] = query 
 
 
Indeed, the os.environ.update(env) does not modify 
&#039;QUERY_STRING&#039; if you are not givin a new value.   
But in this case empty is a new value, and must be take in 
account. 
 
I don&#039;t know if my resolution is the best one.  But now it works 
like it should be. 
 
 

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:29

Message:
Logged In: YES 
user_id=6380

Fixed in CVS for 2.4; will also for for 2.3.

I think I just had a black-out when I added the "if not
have_fork" test.

Note to vincent_delft: setdefault() only changes the value
if no value is already set, so it does exactly what we want.


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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-17 13:09

Message:
Logged In: YES 
user_id=80475

Guido, is there a reason that you had excluded default 
setting when have_fork is true?

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

Comment By: vincent delft (vincent_delft)
Date: 2003-07-27 07:53

Message:
Logged In: YES 
user_id=106404

I don't see the for-loop ?  
If you are talking about the following :  
        if not self.have_fork: 
            # Since we're setting the env in the parent, provide empty 
            # values to override previously set values 
            for k in ('QUERY_STRING', 'REMOTE_HOST', 
'CONTENT_LENGTH', 
                      'HTTP_USER_AGENT', 'HTTP_COOKIE'): 
                env.setdefault(k, "") 
 
 
It's normal that he not used because I'm on Linux machine. So, I have 
fork capabilities. 
Honestly I don't understand this loop. Indeed, You set to default values 
that was defined just before.  In general we set the default before. 
 
 
 
 
 

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-27 01:01

Message:
Logged In: YES 
user_id=80475

Will take a closer look at this one.  Initially, I was concerned 
that some CGI scripts check for the existence rather than the 
nullity of the QUERY_STRING key.  Now, I'm perplexed by 
why this isn't being handled by the for-loop (a few lines 
down from the part you patched) which "provides empty 
values to override previously set values".




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

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

From noreply at sourceforge.net  Sat Mar 20 17:45:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 17:45:48 2004
Subject: [ python-Bugs-780407 ] cast from pointer to integer of different
	size
Message-ID: <E1B4pDB-0004Oz-00@sc8-sf-web4.sourceforge.net>

Bugs item #780407, was opened at 2003-07-30 14:36
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=780407&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Guido van Rossum (gvanrossum)
Summary: cast from pointer to integer of different size

Initial Comment:
this warning (gcc-3.2 or gcc-3.3) was introduced betwen
20030321 and 20030505, when compiling on 64bit targets

gcc -c  -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -I.
-I../Include  -DPy_BUILD_CORE -o Parser/grammar.o
../Parser/grammar.c
../Parser/grammar.c: In function `_Py_addlabel&#039;:
../Parser/grammar.c:107: warning: cast from pointer to
integer of different size

                printf("Label @ %08x, %d: %s\n",
(unsigned)ll,  ...

this should be casted to an unsigned long, and %lx format.



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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:45

Message:
Logged In: YES 
user_id=6380

No, it should be %8p.  I've done that in CVS.

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

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-02 04:58

Message:
Logged In: YES 
user_id=80475

Guido, this was your code addition in April 2003.


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

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

From noreply at sourceforge.net  Sat Mar 20 17:49:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 17:49:06 2004
Subject: [ python-Bugs-796219 ] ntpath.expanduser() is still wrong
Message-ID: <E1B4pH4-0007OJ-00@sc8-sf-web1.sourceforge.net>

Bugs item #796219, was opened at 2003-08-27 16:11
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: ntpath.expanduser() is still wrong

Initial Comment:
I found a system with the following setup:

- os.getenv("HOME") returns "%USERPROFILE%"
- os.getenv("USERPROFILE") returns the home directory

Currently, ntpath.py doesn&#039;t expand ~ correctly in this
case.
The fix is pretty simple, I&#039;ll try to submit it if I
have time.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:49

Message:
Logged In: YES 
user_id=6380

Unclear what I'm asked to do here. Josiah, could you produce
an actual patch against CVS rather than random example code?

If you have forward slashes, you should use
os.path.normpath(). Why doesn't that work?

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

Comment By: Tim Peters (tim_one)
Date: 2003-09-30 10:00

Message:
Logged In: YES 
user_id=31435

Assigned back to Guido.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-09-30 02:33

Message:
Logged In: YES 
user_id=341410

I just noticed that I've got some forward slashes in various
paths on my windows machines...here's some updated code:

    def expandfull(var, rem=3):
        if not rem:
            return os.path.expandvars(var)
        a = os.path.expandvars(var)
        b = []
        d = [b.extend(i.split('\')) for i in a.split('/')]
        c = []
        for i in b:
            if '%' in i:
                c.append(expandfull(i), rem-1)
            else:
                c.append(i)
        return '\'.join(c)


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

Comment By: Christos Georgiou (tzot)
Date: 2003-08-30 05:55

Message:
Logged In: YES 
user_id=539787

I stand corrected; multiple backslashes inside a path are not 
merged into one on Windows.  Thank you.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 14:48

Message:
Logged In: YES 
user_id=341410

Sourceforge ate my double-backslashes.
All '\' should be '\\'.

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

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 14:20

Message:
Logged In: YES 
user_id=341410

The code you offered won't work correctly for all
environment variable returns.  An example that would kill
your code:
%SYSTEMROOT%\System32

def expandfull(var, rem=3):
    if not rem:
        return expandvars(var)
    a = expandvars(var)
    b = a.split('\')
    c = []
    for i in b:
        if '%' in i:
            c.append(expandfull(i), rem-1)
        else:
            c.append(i)
    return '\'.join(c)

The above would work properly for all environment variables.

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

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 04:38

Message:
Logged In: YES 
user_id=539787

If expandvars worked for nt variable syntax too, then just 
before the expanduser final return, the following code would 
suffice, right?

max_recursion = 3
while '%' in userhome and max_recursion > 0:
    userhome = expandvars(userhome)
    max_recursion -= 1

ignoring the fact that path[1:] could contain variables too.

Shouldn't expandvars be made to work with %var% format 
too?  If yes, I'll offer code.

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

Comment By: Jarek Zgoda (zgoda)
Date: 2003-08-28 03:47

Message:
Logged In: YES 
user_id=92222

This is very common setting on Windows2000 Professional.

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

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

From noreply at sourceforge.net  Sat Mar 20 17:52:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 17:53:06 2004
Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more
	strict checking
Message-ID: <E1B4pKt-0007d7-00@sc8-sf-web1.sourceforge.net>

Bugs item #847019, was opened at 2003-11-21 21:19
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Dubner (dubnerm)
>Assigned to: Tim Peters (tim_one)
Summary: datetime.datetime initialization needs more strict checking

Initial Comment:
Friend of mine wrote following program:
---------------------------------
import datetime
t=datetime.datetime(&#039;1995-03-25&#039;)
print t.ctime()
---------------------------------
This is obviously wrong code, but instead of reporting
this at second line python crashes on third line (with
ctime).

Info:
Using Python 2.3.2 on Windows 2000


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:52

Message:
Logged In: YES 
user_id=6380

Not sure why this is assigned to me.

One suggestion: we could do a superficial check that would
catch the above honest mistake without claiming to prevent
all malicious attacks -- malicious pickles aren't something
we try to defend against in general (alas).

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

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-24 20:17

Message:
Logged In: YES 
user_id=39274

Can we add dummy fields to change size of backdoor string so
it will not be same as commonly used formats?

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

Comment By: Tim Peters (tim_one)
Date: 2003-11-24 18:50

Message:
Logged In: YES 
user_id=31435

Na, it's not that simple.  Blazing-fast pickling and unpickling 
was a design goal for datetime.  "Sanity checks" require two-
tailed comparisons on 7 distinct fields, and checking of the 
day field requires month-specific comparison, and may even 
require determing whether it's a leap year.  Doing all that 
would make sucking datetimes out of pickles enormously 
slower than it is now (it's merely a 10-byte string copy now).

If we were willing to do all the checks we do on things coming 
through the front door, we wouldn't call it a back door <wink>.

OTOH, we shouldn't allow a hostile user the ability to crash 
the system via constructing a damaged datetime pickle 
either, so maybe the whole "fast back door" idea is impossible 
to rehabilitate.

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

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-23 20:36

Message:
Logged In: YES 
user_id=39274

Of cause i've seen that backdoor, but from my point of view
constructor is not so time-critical that insertion of sanity
chechs will slow down in most (sane) scenarios.

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

Comment By: Tim Peters (tim_one)
Date: 2003-11-21 22:16

Message:
Logged In: YES 
user_id=31435

LOL!  Assigned to Guido for his amusement.  One string 
argument of exactly size 10 triggers the "secret" backdoor to 
construct a datetime.datetime from a pickle.  The datetime 
constructed here is insane, and provokes Microsoft's library 
into crashing.  In a debug build, it triggers an assertion error 
in the datetime module:

>>> import datetime
[16122 refs]
>>> datetime.datetime('1995-03-25')
datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973)
[16124 refs]
>>> _.ctime()
Assertion failed: month <= 12, file 
C:\Code\python\Modules\datetimemodule.c, line 189

Boosted priority since it's a way to crash the interpreter on 
Windows.

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

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

From noreply at sourceforge.net  Sat Mar 20 17:54:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 17:54:44 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1B4pMN-0007jI-00@sc8-sf-web1.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 14:00
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
>Assigned to: Phillip J. Eby (pje)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:54

Message:
Logged In: YES 
user_id=6380

Phillip, now that you have CVS perms, please check this in
yourself (and backport).

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

Comment By: Phillip J. Eby (pje)
Date: 2004-03-06 07:35

Message:
Logged In: YES 
user_id=56214

Here's a patch against the CVS head to add a test for the
problem, and fix it.  Please backport to the 2.3 branch as
well.  Thanks!

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

Comment By: Michael Hudson (mwh)
Date: 2004-02-25 14:09

Message:
Logged In: YES 
user_id=6656

I don't think you'll find any difference between the trunk
and release23-maint in this area, so it doesn't make much
difference.

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

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 14:06

Message:
Logged In: YES 
user_id=56214

super().descriptor example:

class Base(object):
    aProp = property(lambda self: "foo")

class Sub(Base):
    def test(klass):
        print super(Sub,klass).aProp
    test = classmethod(test)

Sub.test()

This prints "foo", when it should print "<property object at
0x4024f84c>" instead.

To be precise, the issue is that accessing any descriptor
that behaves differently when retrieved on the class vs. the
instance, will behave incorrectly when accessed via super()
from a classmethod in a subclass.  Classmethods themselves
work correctly because they behave the same way no matter
how you retrieve them.

At present I think the patch should simply change the
descr_get call in super_getattro so that it checks whether
su->obj==su->obj_type, and if so, pass in NULL instead of
su->obj as the second argument to descr_get.

Should I create this patch against the 2.3 maintenance
branch, or against the head?  I'd like to make sure it gets
into the next 2.3.x bugfix release.  (I didn't realize this
bug was still open until I stumbled across it the other day,
and I'm not expecting to upgrade to 2.3 production use for a
few months yet.  I've been using a pure-Python
reimplementation of super() as a workaround.)


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

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 10:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

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

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 02:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

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

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

From noreply at sourceforge.net  Sat Mar 20 17:56:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 17:56:58 2004
Subject: [ python-Bugs-805304 ] super instances don't support item assignment
Message-ID: <E1B4pOd-0003my-00@sc8-sf-web3.sourceforge.net>

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

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 5
Submitted By: Fred L. Drake, Jr. (fdrake)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: super instances don't support item assignment

Initial Comment:
This snippet produces a TypeError in Python 2.2.3, 2.3,
and CVS:

class C(object):
    def __setitem__(self, name, value):
        print (name, value)

class D(C):
    def __setitem__(self, name, value):
        super(D, self)[name] = value

d = D()
d[&#039;foo&#039;] = &#039;bar&#039;

Here&#039;s the traceback:

Traceback (most recent call last):
  File "/home/fdrake/tmp/setitem.py", line 10, in ?
    d[&#039;foo&#039;] = &#039;bar&#039;
  File "/home/fdrake/tmp/setitem.py", line 7, in
__setitem__
    super(D, self)[name] = value
TypeError: object does not support item assignment

The problem appears to be that the item assignment
isn&#039;t getting mapped to the __setitem__ of the base
class, so this is probably somewhere deep in
Objects/typeobject.c.

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

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:56

Message:
Logged In: YES 
user_id=6380

This should be coded as Raymond originally recommended:
super(D, self).__setitem__(name, value).

Raymond, can you update the docs?

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-16 00:48

Message:
Logged In: YES 
user_id=80475

Referring to Guido for pronouncement.

I've been thinking that this one could be left alone and just 
document that super objects only do their magic upon 
explicit attribute lookup.

Otherwise, fixing it completely involves combing Python for 
every place that directly calls functions from the slots table, 
and then adding a followup call using attribute lookup if the 
slot is empty.

When it comes to functions like repr(obj), I think we want 
the super object to identify itself rather than forwarding the 
call to the target object's __repr__() method.

The downside of leaving it alone is that it breaks the 
symmetry between obj[k] and obj.__getitem__[k].



----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 19:19

Message:
Logged In: YES 
user_id=80475

Okay, let's apply the two-step problem solving approach.  
First, declare the problem impossible to solve.  Then, propose 
a solution ;-)

The attached patch is a proof-of-concept.  It teaches 
PyObject_SetItem to use an attribute lookup for super 
objects whenever a direct table lookup fails.

If the approach is approved, the final version of the patch 
should also address PyObject_GetItem and other ways that 
the attribute lookup mechanism can be bypassed. Also, the 
test for super can be improved by adding PySuper_Check() 
to the typeobject.c API.

Of course, there is also the question as to whether fixing this 
is a bug or a feature.  It does enable a whole set of programs 
to run under Py2.3.1 and Py2.2.4 that would not run under 
Py2.3.0 and Py2.2.3.


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-13 02:50

Message:
Logged In: YES 
user_id=80475

This one is tough.  

All of super's magic happens with descriptors upon attribute 
lookup.  The example above will work fine if the call were 
written as:  "super(D, self).__setitem__(name)".

However, when written as "super(D, self)[name]", ceval.c 
triggers a STORE_SUBSCR opcode which calls 
PyObject_SetItem which in turns looks directly at the super 
object's type table (and finding nothing).  Nowhere in this 
process is an attribute lookup called or a descriptor invoked.

The current implementation waits until attribute binding time 
to search the bases.  Hence, at the time the super object is 
created, it doesn't know enough information to fill out its 
table about which methods will be available.  Consequently, 
direct table probes will fail.

To make a general purpose fix would be a mess and involves 
changing the semantics of super to do its base search at the 
time the super object is created and to fillout its table with 
the appropriate methods.  Unfortunately, any dynamic 
changes to the methods in the base object would *not* get 
reflected at lookup.

There may be a reasonable special purpose fix.  Fill-out the 
entire superobject table with custom methods that trigger an 
attribute lookup.  For instance, fillout the sq_ass_item slot 
with a function that calls self.__setitem__ which will trigger 
the attribute search.  Even this approach has problems 
because the super object has no way of knowing in advance 
whether sq_ass_item or mp_ass_subscript is the appropriate 
method for the object being referred to (is it a mapping or a 
sequence?).

I recommend punting on this one and documenting that 
direct syntax manipulation of super objects is not defined 
and the super().__special_method__ format be used instead.
Perhaps, all of super's unfilled slots can be filled with a 
placeholder method that emits an explanatory error message.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=805304&group_id=5470

From noreply at sourceforge.net  Sat Mar 20 18:01:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 18:01:13 2004
Subject: [ python-Bugs-716587 ] profile.run makes assumption regarding
	namespace
Message-ID: <E1B4pSl-0005QE-00@sc8-sf-web4.sourceforge.net>

Bugs item #716587, was opened at 2003-04-07 02:56
Message generated for change (Comment added) made by gvanrossum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 1
Submitted By: Greg Fortune (gregfortune)
Assigned to: Guido van Rossum (gvanrossum)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 18:01

Message:
Logged In: YES 
user_id=6380

I don't see the issue. Why can't you use

  prof = profile.Profile()
  prof.runctx(cmd, mydict, mydict)

???


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 02:18

Message:
Logged In: YES 
user_id=80475

This seems like a reasonable request.  The use case is 
uncommon but I don't like having __main__ hardwired in 
the code.  What do you think?

If you want the change, should it be put into Py2.3?

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2003-04-07 10:36

Message:
Logged In: YES 
user_id=155459

Doh, sorry about that.  Guess I should actually check it after I 
submit...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-07 08:31

Message:
Logged In: YES 
user_id=6656

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

From noreply at sourceforge.net  Sat Mar 20 18:02:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 18:02:56 2004
Subject: [ python-Bugs-858016 ] Pathological case segmentation fault in
	issubclass
Message-ID: <E1B4pUM-0004Bm-00@sc8-sf-web3.sourceforge.net>

Bugs item #858016, was opened at 2003-12-10 19:13
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Eric M. Hopper (omnifarious)
Assigned to: Brett Cannon (bcannon)
Summary: Pathological case segmentation fault in issubclass

Initial Comment:
This works for the PowerPC Python compiled with gcc 3.3
on OS X using fink.  I suspect it&#039;s broader based than
that, but I don&#039;t have the ability to check properly.

Here&#039;s how to make it segment fault:

x = (basestring,)
for i in xrange(0, 1000000):
   x = (x,)
issubclass(str, x)

At least, it segment faults at the interactive prompt
this way.  I don&#039;t know if it does when it&#039;s executed
from a file.


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 15:02

Message:
Logged In: YES 
user_id=357491

Fixed in both Python 2.3 and 2.4 so that the depth of the tuple cannot 
exceed the the recursion limit of the interpreter.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 08:14

Message:
Logged In: YES 
user_id=357491

Have a patch for Python 2.3 that limits the depth of the tuples to the 
recursion limit of the interpreter.  That will definitely be used for 2.3  
Question is which solution to use for 2.4 .

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-02-16 15:44

Message:
Logged In: YES 
user_id=31435

Well, that wasn't as much fun for you as I hoped -- the 
report just sat there until I got a free holiday <wink>.  Marked 
Accepted and back to you -- looks good!

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-12-18 21:24

Message:
Logged In: YES 
user_id=357491

OK, Tim, start hopping.  =)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-12-18 13:48

Message:
Logged In: YES 
user_id=31435

Oh, Brett, you're missing a chance for some fun here!  A bug 
should always be assigned to the next person who should "do 
something" about it.  Think of it as a hot potato.  You should 
assign the bug to who you *want* to review this, and then 
sit back and watch the fun, as each person in turn tries to 
unload the potato onto someone else.  That's one way to get 
a comforting illusion of activity here <wink>.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-12-18 13:39

Message:
Logged In: YES 
user_id=357491

I have appended a file that adds a basic test to make sure that 
when the items of a tuple are used to call isinstance or issubclass 
that only classes or types are used; everything else raises 
TypeError.  Also tried to clarify the wording of the doc strings.  
Changed the docs for isinstance since it allowed nested tupling 
while issubclass' didn't.

Have a look and if someone will sign off on it I will apply the patch 
and then start working on a 2.3 solution that doesn't break 
semantics.

And I just realized I left out a Misc/NEWS in the patch; it will be 
there when it gets applied.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-12-14 13:09

Message:
Logged In: YES 
user_id=31435

I'm afraid that changing semantics needs to be run through 
the python-dev wringer first -- "shouldn't break very much 
code" isn't "shouldn't break any code".  The *comments* in 
these functions make it appear that they never intended to 
support the OP's original code snippet, but the docs don't 
match.  This leaves the intent a mystery, so it needs to be 
discussed.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-12-14 12:55

Message:
Logged In: YES 
user_id=357491

OK, consider my worldview fixed.  =)

I will add a check in the tuple unpacking 'for' loop to make sure it 
is only passing issubclass classes and not more tuples.  Simple 
and shouldn't break very much code.  Otherwise the code would 
have to keep a count and extra bookkeeping and it would get 
messy quickly.

And I will take a look at isinstance, although this tuple feature was 
added in 2.3 for issubclass so it might not be an issue.

And I will backport it.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-12-13 17:08

Message:
Logged In: YES 
user_id=31435

Yes, this needs to be fixed if it *can* be fixed without heroic 
effort or insane slowdown.  Looks like it can be.

Brett, the missing piece of your worldview <wink> here is that 
anywhere Python can be tricked into segfaulting is a kind 
of "security hole" -- it's not just mistakes we want to protect 
programmers from, we also want to bulletproof against hostile 
users, to the extent sanely possible.

BTW, if issubclass() has this insecurity, I bet isinstance() 
does too (they were introduced & coded at the same time).

----------------------------------------------------------------------

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-11 09:54

Message:
Logged In: YES 
user_id=313

Well, I think any case where the system segment faults
unexpectedly is bad, regardless of how pathological it is.

Personally, I think that issubclass should either have a
recursion limit after which it throws an exception, or it
shouldn't go into sub-tuples at all.

The reason I made this test is that I read the description
of the behavior of issublcass and found it rather strange,
so I decided to push it to see how far it would go.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-12-10 20:28

Message:
Logged In: YES 
user_id=357491

If you look at Object/abstract.c (line 2119 or so) for 2.4 CVS you 
will notice that PyObject_IsSubclass goes into a 'for' loop for each 
item in the tuple passed in and calls PyObject_IsSubclass .  
Unfortunately it makes no check for whether the argument it is 
passing is a class itself or not.  This allows it to keep making calls 
as long as the second argument is either a class or a tuple.  This 
is what is leads to the stack being blown and the subsequent 
segfault.

Obvious solution is to put in a check that the argument about to be 
passed is a class itself so as to not have such a deep call chain.  
But since ``help(issubclass)`` actually makes the above use legit 
(it says using a tuple as a second argument is equivalent as 
passing each item to issubclass which is what it is doing, albeit in 
a rather uncommon and pointless way), is it worth putting the 
check in?  Since this is such an obvious mis-use, I say no.  But if 
someone else on python-dev steps in and says otherwise I will 
patch it.

----------------------------------------------------------------------

Comment By: Eric M. Hopper (omnifarious)
Date: 2003-12-10 19:16

Message:
Logged In: YES 
user_id=313

I forgot this:

Python 2.3.2 (#1, Dec  4 2003, 09:13:58) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=858016&group_id=5470

From noreply at sourceforge.net  Sat Mar 20 18:24:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 18:24:37 2004
Subject: [ python-Bugs-883604 ] locale specific problem in test_strftime.py
Message-ID: <E1B4ppM-0003pt-00@sc8-sf-web2.sourceforge.net>

Bugs item #883604, was opened at 2004-01-24 05:21
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883604&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: George Yoshida (quiver)
Assigned to: Brett Cannon (bcannon)
Summary: locale specific problem in test_strftime.py

Initial Comment:
test/test_strftime.py compares an expectation and a 
result by regular expressions, but the pattern isn&#039;t 
escaped. So if the expectation includes a metacharacter,
  expectation == result
and
  re.match(expectation, result)
do not always return the same value.

In my case on Japanese Windows, time.tzname returns
  (&#039;\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;, &#039;\x93
\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;)
The output contains parentheses. 
This resuls in a message:
  Conflict for nonstandard &#039;%Z&#039; format (time zone name):
    Expected ???? (?W????), but got ???? (?W????)
re.match(foo, bar) != (foo == bar)

One workaround I can think of is changing re.match(e
[1], result) back to result == e[1].


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 15:24

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.29 of Lib/test/test_strftime.py in Python 2.4 and rev. 
1.27.16.1 for Python 2.3 .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 09:32

Message:
Logged In: YES 
user_id=357491

George, can you apply the attached  patch and let me know if it solves 
the problem?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-01-29 18:23

Message:
Logged In: YES 
user_id=357491

That's not what I meant by the comment; sorry for not being 
clearer.  I meant is whether test_strftime's existence is because of 
Jython.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-01-29 03:54

Message:
Logged In: YES 
user_id=671362

> Is  this for Jython or something?
No, it's Python 2.3.3 on Windows 2000.

time zone is classified as non standard(unpredictable) so it 
might be difficult to make test_stftime.py to support all 
locales. There are so many issues.

FYI, I checked time.tzname on other platforms.

# Jython
Jython 2.1 on java1.4.2 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname
('JST', 'JST')  # Japanese Standard Time

# Linux
On RHL 9.0(Python 2.2/2.3), time.tzname returns ('JST', 'JST').

They pass the test.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-01-27 00:28

Message:
Logged In: YES 
user_id=357491

Does anyone know why we even have test_strftime?  It isn't like 
we have our own implementation and there are basic tests in 
test_time to make sure the wrapper around the C function works.  
I know the test module says it is for sanity checks, but if it fails 
legitimately on a platform there is not much we can do about it.  
Is this for Jython or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883604&group_id=5470

From noreply at sourceforge.net  Sat Mar 20 18:40:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 18:40:22 2004
Subject: [ python-Bugs-716587 ] profile.run makes assumption regarding
	namespace
Message-ID: <E1B4q4Y-0007ny-00@sc8-sf-web4.sourceforge.net>

Bugs item #716587, was opened at 2003-04-07 00:56
Message generated for change (Comment added) made by gregfortune
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 1
Submitted By: Greg Fortune (gregfortune)
Assigned to: Guido van Rossum (gvanrossum)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


----------------------------------------------------------------------

>Comment By: Greg Fortune (gregfortune)
Date: 2004-03-20 16:40

Message:
Logged In: YES 
user_id=155459

Partially because the only entry point to the profiler mentioned in the 
documentation is profile.run.  If the Profile class were documented, it 
would be a little more obvious how one would work around the 
limitation. 
 
Secondly, the assumption that __main__ is always the desired 
namespace seems limiting and arbitrary.  Anybody wanting to profile 
inside an embedded interpreter is going to have to dig through the 
code the same way I did to identify the problem. 
 
Could the namespace be magically determined based on the function 
that is being profiled?  If so, that is probably an even better solution as 
it becomes a none issue.  At the very least, profile.run should grab the 
namespace from the current interpreter rather than __main__ and 
that's probably better than my initial proposal anyway. 
 
So, it's not a matter of being impossible to work around...  It's just not 
an ideal interface yet. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 16:01

Message:
Logged In: YES 
user_id=6380

I don't see the issue. Why can't you use

  prof = profile.Profile()
  prof.runctx(cmd, mydict, mydict)

???


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 00:18

Message:
Logged In: YES 
user_id=80475

This seems like a reasonable request.  The use case is 
uncommon but I don't like having __main__ hardwired in 
the code.  What do you think?

If you want the change, should it be put into Py2.3?

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2003-04-07 08:36

Message:
Logged In: YES 
user_id=155459

Doh, sorry about that.  Guess I should actually check it after I 
submit...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-07 06:31

Message:
Logged In: YES 
user_id=6656

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

From noreply at sourceforge.net  Sat Mar 20 21:19:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 20 21:19:27 2004
Subject: [ python-Bugs-883604 ] locale specific problem in test_strftime.py
Message-ID: <E1B4sYW-0006Ar-00@sc8-sf-web3.sourceforge.net>

Bugs item #883604, was opened at 2004-01-24 22:21
Message generated for change (Comment added) made by quiver
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883604&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 3
Submitted By: George Yoshida (quiver)
Assigned to: Brett Cannon (bcannon)
Summary: locale specific problem in test_strftime.py

Initial Comment:
test/test_strftime.py compares an expectation and a 
result by regular expressions, but the pattern isn&#039;t 
escaped. So if the expectation includes a metacharacter,
  expectation == result
and
  re.match(expectation, result)
do not always return the same value.

In my case on Japanese Windows, time.tzname returns
  (&#039;\x93\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;, &#039;\x93
\x8c\x8b\x9e (\x95W\x8f\x80\x8e\x9e)&#039;)
The output contains parentheses. 
This resuls in a message:
  Conflict for nonstandard &#039;%Z&#039; format (time zone name):
    Expected ???? (?W????), but got ???? (?W????)
re.match(foo, bar) != (foo == bar)

One workaround I can think of is changing re.match(e
[1], result) back to result == e[1].


----------------------------------------------------------------------

>Comment By: George Yoshida (quiver)
Date: 2004-03-21 11:19

Message:
Logged In: YES 
user_id=671362

Thanks, Brett.
The problem has been solved.

I uploaded the output of test_strftime.py just for 
confirmation. 

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-21 08:24

Message:
Logged In: YES 
user_id=357491

Fixed in rev. 1.29 of Lib/test/test_strftime.py in Python 2.4 and rev. 
1.27.16.1 for Python 2.3 .

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-21 02:32

Message:
Logged In: YES 
user_id=357491

George, can you apply the attached  patch and let me know if it solves 
the problem?

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-01-30 11:23

Message:
Logged In: YES 
user_id=357491

That's not what I meant by the comment; sorry for not being 
clearer.  I meant is whether test_strftime's existence is because of 
Jython.

----------------------------------------------------------------------

Comment By: George Yoshida (quiver)
Date: 2004-01-29 20:54

Message:
Logged In: YES 
user_id=671362

> Is  this for Jython or something?
No, it's Python 2.3.3 on Windows 2000.

time zone is classified as non standard(unpredictable) so it 
might be difficult to make test_stftime.py to support all 
locales. There are so many issues.

FYI, I checked time.tzname on other platforms.

# Jython
Jython 2.1 on java1.4.2 (JIT: null)
Type "copyright", "credits" or "license" for more information.
>>> import time
>>> time.tzname
('JST', 'JST')  # Japanese Standard Time

# Linux
On RHL 9.0(Python 2.2/2.3), time.tzname returns ('JST', 'JST').

They pass the test.


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-01-27 17:28

Message:
Logged In: YES 
user_id=357491

Does anyone know why we even have test_strftime?  It isn't like 
we have our own implementation and there are basic tests in 
test_time to make sure the wrapper around the C function works.  
I know the test module says it is for sanity checks, but if it fails 
legitimately on a platform there is not much we can do about it.  
Is this for Jython or something?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=883604&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 02:49:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 02:49:49 2004
Subject: [ python-Bugs-693255 ] 2.3a2 site.py non-existing dirs
Message-ID: <E1B4xiK-0001kj-00@sc8-sf-web1.sourceforge.net>

Bugs item #693255, was opened at 2003-02-25 23:44
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470

Category: None
Group: None
>Status: Open
Resolution: Fixed
Priority: 5
Submitted By: James P Rutledge (jrut)
Assigned to: Just van Rossum (jvr)
Summary: 2.3a2 site.py non-existing dirs

Initial Comment:
In Python 2.3a2 the site.py leaves non-existing
directories in sys.path.

On my Debian Linux system, using Python 2.3a2,
the sys.path, after site.py is executed during
interpreter initialization, includes the entry

   /usr/local/lib/python23.zip

although no such directory currently exists on
my system.

The module documentation contained in site.py does
state

  "Non-existing directories (or non-directories)
  are never added to sys.path"


----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2004-03-21 08:49

Message:
Logged In: YES 
user_id=92689

As I wrote before, the _docs_ are wrong, site.py should NOT 
remove non-existing elements, since they may be non-file 
system items to be handled by a custom importer.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 22:42

Message:
Logged In: YES 
user_id=357491

In Python 2.4, rev. 1.59 has site.py remove non-existing paths.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-08 06:11

Message:
Logged In: YES 
user_id=357491

Can someone with more experience with the "official" policy of of 
site.py say whether or not the docs should be changed or site.py 
itself?

----------------------------------------------------------------------

Comment By: James P Rutledge (jrut)
Date: 2003-05-29 21:20

Message:
Logged In: YES 
user_id=720847

I do not know what policy is desired for the condition of
the path after executing site.py.

I found the problem when I switched to try 2.3 and used an
application I wrote which searches the path to obtain
information about installed  modules.  During
troubleshooting, the change in site.py from 2.2 to 2.3, to
stop removing non-existent directories in the path, became
evident as the reason for the application finding a
non-existent directory in the path.

The application was, of course, easily changed to skip
non-existent directories.  The question is whether removing
of non-existent directories in the path _should_ be done by
site.py


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-29 03:33

Message:
Logged In: YES 
user_id=357491

I take it the docs are what needs to change and not site.py?

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-26 09:43

Message:
Logged In: YES 
user_id=92689

The docs are indeed wrong.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-26 04:08

Message:
Logged In: YES 
user_id=33168

Just, does the doc still need to be updated?

----------------------------------------------------------------------

Comment By: James P Rutledge (jrut)
Date: 2003-02-26 03:56

Message:
Logged In: YES 
user_id=720847

Additional info -- the site.py used in
Python 2.2.2 explicitly removes non-existing
and non-directory files from sys.path.

The Python 2.3 site.py does not have that
feature.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 08:41:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 08:41:23 2004
Subject: [ python-Bugs-716587 ] profile.run makes assumption regarding
	namespace
Message-ID: <E1B53CU-00076D-00@sc8-sf-web4.sourceforge.net>

Bugs item #716587, was opened at 2003-04-07 06:56
Message generated for change (Comment added) made by nascheme
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 1
Submitted By: Greg Fortune (gregfortune)
>Assigned to: Neil Schemenauer (nascheme)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


----------------------------------------------------------------------

>Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-21 13:41

Message:
Logged In: YES 
user_id=35752

I always use 'run_call'.  You can easily make a closure to
capture any bindings you want.  Usually it is not necessary.

run_call should be available as a global function and it
should be documented, IMHO.

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2004-03-20 23:40

Message:
Logged In: YES 
user_id=155459

Partially because the only entry point to the profiler mentioned in the 
documentation is profile.run.  If the Profile class were documented, it 
would be a little more obvious how one would work around the 
limitation. 
 
Secondly, the assumption that __main__ is always the desired 
namespace seems limiting and arbitrary.  Anybody wanting to profile 
inside an embedded interpreter is going to have to dig through the 
code the same way I did to identify the problem. 
 
Could the namespace be magically determined based on the function 
that is being profiled?  If so, that is probably an even better solution as 
it becomes a none issue.  At the very least, profile.run should grab the 
namespace from the current interpreter rather than __main__ and 
that's probably better than my initial proposal anyway. 
 
So, it's not a matter of being impossible to work around...  It's just not 
an ideal interface yet. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 23:01

Message:
Logged In: YES 
user_id=6380

I don't see the issue. Why can't you use

  prof = profile.Profile()
  prof.runctx(cmd, mydict, mydict)

???


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 06:18

Message:
Logged In: YES 
user_id=80475

This seems like a reasonable request.  The use case is 
uncommon but I don't like having __main__ hardwired in 
the code.  What do you think?

If you want the change, should it be put into Py2.3?

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2003-04-07 14:36

Message:
Logged In: YES 
user_id=155459

Doh, sorry about that.  Guess I should actually check it after I 
submit...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-07 12:31

Message:
Logged In: YES 
user_id=6656

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 09:33:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 09:33:26 2004
Subject: [ python-Bugs-693255 ] 2.3a2 site.py non-existing dirs
Message-ID: <E1B540p-0003cL-00@sc8-sf-web4.sourceforge.net>

Bugs item #693255, was opened at 2003-02-25 14:44
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470

Category: None
Group: None
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: James P Rutledge (jrut)
Assigned to: Just van Rossum (jvr)
Summary: 2.3a2 site.py non-existing dirs

Initial Comment:
In Python 2.3a2 the site.py leaves non-existing
directories in sys.path.

On my Debian Linux system, using Python 2.3a2,
the sys.path, after site.py is executed during
interpreter initialization, includes the entry

   /usr/local/lib/python23.zip

although no such directory currently exists on
my system.

The module documentation contained in site.py does
state

  "Non-existing directories (or non-directories)
  are never added to sys.path"


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-21 06:33

Message:
Logged In: YES 
user_id=357491

OK, the change was backed out.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2004-03-20 23:49

Message:
Logged In: YES 
user_id=92689

As I wrote before, the _docs_ are wrong, site.py should NOT 
remove non-existing elements, since they may be non-file 
system items to be handled by a custom importer.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-20 13:42

Message:
Logged In: YES 
user_id=357491

In Python 2.4, rev. 1.59 has site.py remove non-existing paths.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-07-07 21:11

Message:
Logged In: YES 
user_id=357491

Can someone with more experience with the "official" policy of of 
site.py say whether or not the docs should be changed or site.py 
itself?

----------------------------------------------------------------------

Comment By: James P Rutledge (jrut)
Date: 2003-05-29 12:20

Message:
Logged In: YES 
user_id=720847

I do not know what policy is desired for the condition of
the path after executing site.py.

I found the problem when I switched to try 2.3 and used an
application I wrote which searches the path to obtain
information about installed  modules.  During
troubleshooting, the change in site.py from 2.2 to 2.3, to
stop removing non-existent directories in the path, became
evident as the reason for the application finding a
non-existent directory in the path.

The application was, of course, easily changed to skip
non-existent directories.  The question is whether removing
of non-existent directories in the path _should_ be done by
site.py


----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-28 18:33

Message:
Logged In: YES 
user_id=357491

I take it the docs are what needs to change and not site.py?

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2003-02-26 00:43

Message:
Logged In: YES 
user_id=92689

The docs are indeed wrong.

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-02-25 19:08

Message:
Logged In: YES 
user_id=33168

Just, does the doc still need to be updated?

----------------------------------------------------------------------

Comment By: James P Rutledge (jrut)
Date: 2003-02-25 18:56

Message:
Logged In: YES 
user_id=720847

Additional info -- the site.py used in
Python 2.2.2 explicitly removes non-existing
and non-directory files from sys.path.

The Python 2.3 site.py does not have that
feature.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=693255&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 11:46:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 11:47:09 2004
Subject: [ python-Bugs-789294 ] Solaris Forte 7 &8 bug in test_long
Message-ID: <E1B5666-0004OV-00@sc8-sf-web3.sourceforge.net>

Bugs item #789294, was opened at 2003-08-15 08:24
Message generated for change (Settings changed) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789294&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Nick Maclaren (nmm1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Solaris Forte 7 &8 bug in test_long

Initial Comment:
Python 2.2.3

This is for information.  It is a bug in Sun&#039;s Forte 7
and 8 compiler suite, very unlikely to affect most
people, and I am pursuing it at low priority with Sun.
I am reporting it as it will cause the tests to fail
if anyone switches floating-point trapping on.

In PyFloat_FromString in floatobject.c, there is a
call to strtod.  In test_long, this is supplied with
a huge argument.  Sun have misunderstood C99 (puke)
to state that the wording in Annex F requires strtod
to raise an exception if it overflows, and have again
misunderstood C99 to mean that implies SIGFPE if
trapping is on.  I don&#039;t blame them for getting
confused, but their interpretation is wrong - or, at
least that what was stated when C99 was in draft!

Generically, we can expect to see more vendors get
confused by C99, and especially by the horrible
floating-point changes.

Yuck.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=789294&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 12:11:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 12:11:37 2004
Subject: [ python-Bugs-811604 ] "string".split behaviour for empty strings
Message-ID: <E1B56Tf-0006ZW-00@sc8-sf-web1.sourceforge.net>

Bugs item #811604, was opened at 2003-09-24 04:20
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

Category: Python Interpreter Core
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: T.Meyarivan (meyarivan)
Assigned to: Nobody/Anonymous (nobody)
Summary: "string".split behaviour for empty strings

Initial Comment:

"".split() -> []

"".split(&#039; &#039;) -> [&#039;&#039;]

It is not clear from the documentation as to what is
the defined behaviour in the above case. To say the
least, it is 
completely counter-intuitive..(splitting an empty
string should
return the list [&#039;&#039;] in both cases).

>From stringobject.c, the behaviour of split_whitespace
(i.e split called without sep) and string_split (split
called with sep) is different for empty
strings..perhaps the function split_whitespace needs to
be patched.

----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 12:11

Message:
Logged In: YES 
user_id=430343

Fixed in doc/lib/libstring.tex version 1.57

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2003-09-28 19:50

Message:
Logged In: YES 
user_id=593130

Suggestion: find section of Lib Ref discussing str.split, quote 
existing def, and add succinct sentence that you think is 
needed.  Then change category to 'documentation' so 
appropriate person(s) will see proposal.

----------------------------------------------------------------------

Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-26 07:04

Message:
Logged In: YES 
user_id=30470


Thats so counter intuitive.. :-(

At least the documentation should specify the fact that the
behaviour of "string".split for empty strings is so and so....

The reason this probably never came up ( or mostly ignored
by majority ) is that people probably check if the string is
empty before proceeding to process it.. 

I am not closing the bug before the specific behaviour of
"string".split for empty strings gets to the docs..

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-26 00:35

Message:
Logged In: YES 
user_id=80475

And so it is.  The whitespace version (no args) and the
specified separator version work differently -- the second
version can never return an empty list.

This code has been around for a good while and it is likely
that much code relies on the behavior, so I recommend
classifying it as a beauty spot and closing the bug.

"One man's bug is another man's feature"


----------------------------------------------------------------------

Comment By: T.Meyarivan (meyarivan)
Date: 2003-09-24 04:51

Message:
Logged In: YES 
user_id=30470

"".split(None) -> [] 

which is expected because in the case when no sep is
specified and when sep == None, split_whitespace is called..

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811604&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 12:16:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 12:17:07 2004
Subject: [ python-Bugs-917108 ] warnings.py does not define _test()
Message-ID: <E1B56Z8-0007B4-00@sc8-sf-web3.sourceforge.net>

Bugs item #917108, was opened at 2004-03-16 00:59
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917108&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Aahz (aahz)
Assigned to: Nobody/Anonymous (nobody)
Summary: warnings.py does not define _test()

Initial Comment:
At the bottom of warnings.py, there&#039;s a call to _test() if run as a
script.  However, _test() is neither defined nor imported.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-21 12:16

Message:
Logged In: YES 
user_id=31435

Fixed, by removing the entire __name__ == '__main__' block.

Lib/warnings.py; new revision: 1.23

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917108&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 12:33:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 12:33:48 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B56pM-0002iv-00@sc8-sf-web4.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 12:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 03:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 01:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 06:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 04:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 13:16:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 13:16:13 2004
Subject: [ python-Bugs-920573 ] http libraries throw errors internally
Message-ID: <E1B57UX-0006wj-00@sc8-sf-web4.sourceforge.net>

Bugs item #920573, was opened at 2004-03-21 10:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bram Cohen (bram_cohen)
Assigned to: Nobody/Anonymous (nobody)
Summary: http libraries throw errors internally

Initial Comment:
Here&#039;s an error which someone just got running BitTorrent -

Exception in thread Thread-2:
 Traceback (most recent call last):
   File "/usr/lib/python2.3/threading.py", line 436, in
__bootstrap
     self.run()
   File "/usr/lib/python2.3/threading.py", line 416, in run
     self.__target(*self.__args, **self.__kwargs)
   File
"/usr/lib/python2.3/site-packages/BitTorrent/Rerequester.py",
line 72, in rerequest
     h = urlopen(url)
   File "/usr/lib/python2.3/urllib2.py", line 129, in
urlopen
     return _opener.open(url, data)
   File "/usr/lib/python2.3/urllib2.py", line 326, in open
     &#039;_open&#039;, req)
   File "/usr/lib/python2.3/urllib2.py", line 306, in
_call_chain
     result = func(*args)
   File "/usr/lib/python2.3/urllib2.py", line 491, in
<lambda>
     lambda r, proxy=url, type=type,
meth=self.proxy_open:    File "/usr/lib/python2.3/urllib2.py", line 498, in
proxy_open
     if &#039;@&#039; in host:
 TypeError: iterable argument required

And here&#039;s one which people have been getting
*forever*, without it ever having been fixed (I&#039;ve been
simply catching and ignoring it) -

Exception in thread Thread-60:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 414, in
__bootstrap
    self.run()
  File "/usr/lib/python2.2/threading.py", line 402, in run
    apply(self.__target, self.__args, self.__kwargs)
  File "/home/zkessin/bin/BitTorrent/Rerequester.py",
line 85, in
rerequest
    r = h.read()
  File "/usr/lib/python2.2/httplib.py", line 1140, in read
    assert not self._line_consumed and self._line_left
AssertionError

Both of the above were caused by very straightforward
calls to httplib. I&#039;m fairly certain (especially with
the second one) that they&#039;re internal bugs.

I&#039;d like to mention while I&#039;m at it that I&#039;m extremely
unhappy with httplib. It&#039;s buggy, blocking, and doesn&#039;t
even support timeouts. While it&#039;s good to have a
library which supports all the vagaries of http, it
would be far better for it to be a simple object which
you tell when data  was received and it tells you when
there&#039;s data to be sent out. That way it could
integrate easily into other applications&#039;s event loops.
The blocking and buggy nature of httplib has caused me
no end of headaches, and I think I&#039;m not the only one.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920573&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 13:18:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 13:18:52 2004
Subject: [ python-Bugs-920575 ] locale module is segfaulting on locale.ERA
Message-ID: <E1B57X7-0003GR-00@sc8-sf-web3.sourceforge.net>

Bugs item #920575, was opened at 2004-03-21 18:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: locale module is segfaulting on locale.ERA

Initial Comment:
[forwarded from http://bugs.debian.org/239237]

Python2.3 is segfaulting when I&#039;m using the locale
module in this way : 
 
Python 2.3.3 (#2, Feb 24 2004, 09:29:20)  
[GCC 3.3.3 (Debian)] on linux2 
Type "help", "copyright", "credits" or "license" for
more information. 
>>> import locale 
>>> locale.nl_langinfo(locale.CODESET) 
&#039;ANSI_X3.4-1968&#039; 
>>> locale.nl_langinfo(locale.D_T_FMT) 
&#039;%a %b %e %H:%M:%S %Y&#039; 
>>> locale.nl_langinfo(locale.ERA) 
zsh: 27439 segmentation fault  python 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 13:48:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 13:48:53 2004
Subject: [ python-Bugs-497067 ] Allow traceback analysis from C/C++...
Message-ID: <E1B5800-0005dS-00@sc8-sf-web3.sourceforge.net>

Bugs item #497067, was opened at 2001-12-27 11:13
Message generated for change (Settings changed) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=497067&group_id=5470

Category: Python Interpreter Core
Group: Feature Request
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Marcin Kasperski (marcinkasperski)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allow traceback analysis from C/C++...

Initial Comment:
I write C++ applications which embed python 
interpreter as script engine. And I would like to 
perform traceback analysis during error handling 
(imagine for instance that I would like to include 
python traceback info inside some exception which 
will be handled outside library I write, maybe by 
sending error description to log server via network)

What I found? PyErr_Fetch gets traceback object and 
gives it to me. There are methods which print 
traceback to standard error. But if I want to do 
something different ... there is no way 
to analyze traceback  without utilizing some dirty 
tricks. Two main problems:
- struct tracebackobject is not present in python 
headers, it is only in traceback.c
- it is of course not documented at all.

I finally managed to do what I wanted by copying 
tracebackobject definition from traceback.c and by 
copying tb_printinternal and suiting it to my needs. 
But what will happen if you change this structure 
some time in the future?

What exactly do I request? Choose one of the two:

1) Either publish struct tracebackobject inside some 
Python headers (traceback.h?), mention in PyErr_Fetch 
documentation that the last parameter is of this type 
and describe its structure somewhere in python-embed

2) Or keep it secret but add some API which would 
allow to navigate traceback without presenting its 
internals, say the function like 
PyTrace_AnalyzeTraceBack which - given traceback 
object - would return file, line, name and next 
traceback (or the flag telling that there is no more).



----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 13:48

Message:
Logged In: YES 
user_id=430343

Fixed in:
Include/traceback.h 2.21
Python/traceback.c 2.42
Misc/NEWS 1.955


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-12-27 11:35

Message:
Logged In: YES 
user_id=6380

I agree that this API should be published in a header file.

The Python API to the traceback object is documented so you
can always use PyObject_GetAttrString(tb, "tb_frame") and so
on.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=497067&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:03:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:04:05 2004
Subject: [ python-Bugs-661981 ] need to skip some build tests for sunos5
Message-ID: <E1B58Ei-0003fy-00@sc8-sf-web2.sourceforge.net>

Bugs item #661981, was opened at 2003-01-03 23:52
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Ismaeel Abdur-Rasheed (ismaeek)
Assigned to: Nobody/Anonymous (nobody)
Summary: need to skip some build tests for sunos5

Initial Comment:
make test reports the following after completion:

173 tests OK.
20 tests skipped:
    test_al test_bsddb test_cd test_cl test_curses test_dl
    test_email_codecs test_gdbm test_gl test_imgfile
    test_linuxaudiodev test_minidom test_openpty 
test_pyexpat test_sax
    test_socket_ssl test_socketserver test_sunaudiodev 
test_winreg
    test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.

- izzy

----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 14:03

Message:
Logged In: YES 
user_id=430343

Fixed in 2.3

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-21 14:03

Message:
Logged In: YES 
user_id=357491

Fixed in 2.3

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-04 01:11

Message:
Logged In: YES 
user_id=31435

The "someone" you need to ask has to be expert in both 
suos5 and Python.  If such a person existed, and had time 
enough to bother, they already would have done this 
<wink>.  In the meantime, skipping a test is a not a test 
failure, so don't worry about it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:03:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:07:12 2004
Subject: [ python-Bugs-661981 ] need to skip some build tests for sunos5
Message-ID: <E1B58Eh-00065t-00@sc8-sf-web3.sourceforge.net>

Bugs item #661981, was opened at 2003-01-03 20:52
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470

Category: Python Interpreter Core
Group: Python 2.2.2
>Status: Closed
>Resolution: Fixed
Priority: 3
Submitted By: Ismaeel Abdur-Rasheed (ismaeek)
Assigned to: Nobody/Anonymous (nobody)
Summary: need to skip some build tests for sunos5

Initial Comment:
make test reports the following after completion:

173 tests OK.
20 tests skipped:
    test_al test_bsddb test_cd test_cl test_curses test_dl
    test_email_codecs test_gdbm test_gl test_imgfile
    test_linuxaudiodev test_minidom test_openpty 
test_pyexpat test_sax
    test_socket_ssl test_socketserver test_sunaudiodev 
test_winreg
    test_winsound
Ask someone to teach regrtest.py about which tests are
expected to get skipped on sunos5.

- izzy

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-21 11:03

Message:
Logged In: YES 
user_id=357491

Fixed in 2.3

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-01-03 22:11

Message:
Logged In: YES 
user_id=31435

The "someone" you need to ask has to be expert in both 
suos5 and Python.  If such a person existed, and had time 
enough to bother, they already would have done this 
<wink>.  In the meantime, skipping a test is a not a test 
failure, so don't worry about it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=661981&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:34:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:35:00 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B58ic-0006jK-00@sc8-sf-web2.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 18:46
Message generated for change (Comment added) made by bram_cohen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 11:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 09:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 00:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 22:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 03:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 01:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 03:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 03:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:35:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:35:10 2004
Subject: [ python-Bugs-887279 ] asyncore.py poll* missing urgent data
Message-ID: <E1B58iu-0006ky-00@sc8-sf-web2.sourceforge.net>

Bugs item #887279, was opened at 2004-01-29 16:25
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887279&group_id=5470

Category: Python Library
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: A.M. Kuchling (akuchling)
Summary: asyncore.py poll* missing urgent data

Initial Comment:
According to the select.poll documentation, polling flags 
include POLLIN (regular data) and POLLPRI (urgent data).

asyncore poll2 and poll3 check readable objects for 
POLLIN, but do not check for POLLPRI.

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-03-21 14:35

Message:
Logged In: YES 
user_id=11375

The fix from patch #909005 has been commited to CVS HEAD.


----------------------------------------------------------------------

Comment By: Alexey Klimkin (klimkin)
Date: 2004-03-04 03:23

Message:
Logged In: YES 
user_id=410460

Patch #909005 fixes the problem.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=887279&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:40:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:40:57 2004
Subject: [ python-Bugs-920575 ] locale module is segfaulting on locale.ERA
Message-ID: <E1B58oM-0004ox-00@sc8-sf-web1.sourceforge.net>

Bugs item #920575, was opened at 2004-03-22 03:18
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Hye-Shik Chang (perky)
Summary: locale module is segfaulting on locale.ERA

Initial Comment:
[forwarded from http://bugs.debian.org/239237]

Python2.3 is segfaulting when I&#039;m using the locale
module in this way : 
 
Python 2.3.3 (#2, Feb 24 2004, 09:29:20)  
[GCC 3.3.3 (Debian)] on linux2 
Type "help", "copyright", "credits" or "license" for
more information. 
>>> import locale 
>>> locale.nl_langinfo(locale.CODESET) 
&#039;ANSI_X3.4-1968&#039; 
>>> locale.nl_langinfo(locale.D_T_FMT) 
&#039;%a %b %e %H:%M:%S %Y&#039; 
>>> locale.nl_langinfo(locale.ERA) 
zsh: 27439 segmentation fault  python 


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-03-22 04:40

Message:
Logged In: YES 
user_id=55188

glibc is returning NULL for nl_langinfo(ERA). But it must
return "" instead of NULL according to SUSv2.

Quoting it:

RETURN VALUE

In a locale where langinfo data is not defined,
nl_langinfo() returns a pointer to the corresponding string
in the POSIX locale. In all locales, nl_langinfo() returns a
pointer to an empty string if item contains an invalid setting.

This pointer may point to static data that may be
overwritten on the next call.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:45:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:45:19 2004
Subject: [ python-Bugs-900071 ] optparse: usage issues
Message-ID: <E1B58se-0007gE-00@sc8-sf-web2.sourceforge.net>

Bugs item #900071, was opened at 2004-02-19 02:14
Message generated for change (Comment added) made by akuchling
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900071&group_id=5470

Category: None
>Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Simon Dahlbacka (sdahlbac)
Assigned to: Greg Ward (gward)
Summary: optparse: usage issues

Initial Comment:
current documentation states that 

usage = "usage: %prog [options] arg1 arg2"
parser = OptionParser(usage=usage)

would yield

usage: <yourscript> [options] arg1 arg2

however, using python 2.3.2

usage = "Usage: %prog [options] file"

yields:

usage: Usage <yourscript> [options] file"


IMO, it should be possible to replace the whole thing
(think i18n)

----------------------------------------------------------------------

>Comment By: A.M. Kuchling (akuchling)
Date: 2004-03-21 14:45

Message:
Logged In: YES 
user_id=11375

The documentation is correct, but there's a bug in some code 
that removes the 'usage:' prefix to avoid duplication.  It was doing a
case-sensitive match, so your example with 'Usage:'  didn't 
remove the doubled word.  Fixed in CVS head.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=900071&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:45:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:45:42 2004
Subject: [ python-Bugs-920575 ] locale module is segfaulting on locale.ERA
Message-ID: <E1B58t5-0007ij-00@sc8-sf-web2.sourceforge.net>

Bugs item #920575, was opened at 2004-03-22 03:18
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

Category: Extension Modules
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Hye-Shik Chang (perky)
Summary: locale module is segfaulting on locale.ERA

Initial Comment:
[forwarded from http://bugs.debian.org/239237]

Python2.3 is segfaulting when I&#039;m using the locale
module in this way : 
 
Python 2.3.3 (#2, Feb 24 2004, 09:29:20)  
[GCC 3.3.3 (Debian)] on linux2 
Type "help", "copyright", "credits" or "license" for
more information. 
>>> import locale 
>>> locale.nl_langinfo(locale.CODESET) 
&#039;ANSI_X3.4-1968&#039; 
>>> locale.nl_langinfo(locale.D_T_FMT) 
&#039;%a %b %e %H:%M:%S %Y&#039; 
>>> locale.nl_langinfo(locale.ERA) 
zsh: 27439 segmentation fault  python 


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-03-22 04:45

Message:
Logged In: YES 
user_id=55188

A workaround checked in:
Misc/NEWS 1.956
Modules/_localemodule.c 2.45

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-22 04:40

Message:
Logged In: YES 
user_id=55188

glibc is returning NULL for nl_langinfo(ERA). But it must
return "" instead of NULL according to SUSv2.

Quoting it:

RETURN VALUE

In a locale where langinfo data is not defined,
nl_langinfo() returns a pointer to the corresponding string
in the POSIX locale. In all locales, nl_langinfo() returns a
pointer to an empty string if item contains an invalid setting.

This pointer may point to static data that may be
overwritten on the next call.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:50:59 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:51:09 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B58yJ-0005ha-00@sc8-sf-web1.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 14:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 14:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 12:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 03:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 01:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 06:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 04:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 14:51:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 14:51:47 2004
Subject: [ python-Bugs-920575 ] locale module is segfaulting on locale.ERA
Message-ID: <E1B58yt-0007GO-00@sc8-sf-web4.sourceforge.net>

Bugs item #920575, was opened at 2004-03-21 18:18
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Hye-Shik Chang (perky)
Summary: locale module is segfaulting on locale.ERA

Initial Comment:
[forwarded from http://bugs.debian.org/239237]

Python2.3 is segfaulting when I&#039;m using the locale
module in this way : 
 
Python 2.3.3 (#2, Feb 24 2004, 09:29:20)  
[GCC 3.3.3 (Debian)] on linux2 
Type "help", "copyright", "credits" or "license" for
more information. 
>>> import locale 
>>> locale.nl_langinfo(locale.CODESET) 
&#039;ANSI_X3.4-1968&#039; 
>>> locale.nl_langinfo(locale.D_T_FMT) 
&#039;%a %b %e %H:%M:%S %Y&#039; 
>>> locale.nl_langinfo(locale.ERA) 
zsh: 27439 segmentation fault  python 


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2004-03-21 19:51

Message:
Logged In: YES 
user_id=60903

please consider the fix for 2.3 as well.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-21 19:45

Message:
Logged In: YES 
user_id=55188

A workaround checked in:
Misc/NEWS 1.956
Modules/_localemodule.c 2.45

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-21 19:40

Message:
Logged In: YES 
user_id=55188

glibc is returning NULL for nl_langinfo(ERA). But it must
return "" instead of NULL according to SUSv2.

Quoting it:

RETURN VALUE

In a locale where langinfo data is not defined,
nl_langinfo() returns a pointer to the corresponding string
in the POSIX locale. In all locales, nl_langinfo() returns a
pointer to an empty string if item contains an invalid setting.

This pointer may point to static data that may be
overwritten on the next call.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 15:05:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 15:05:47 2004
Subject: [ python-Bugs-920575 ] locale module is segfaulting on locale.ERA
Message-ID: <E1B59CZ-0003PD-00@sc8-sf-web3.sourceforge.net>

Bugs item #920575, was opened at 2004-03-22 03:18
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

Category: Extension Modules
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Hye-Shik Chang (perky)
Summary: locale module is segfaulting on locale.ERA

Initial Comment:
[forwarded from http://bugs.debian.org/239237]

Python2.3 is segfaulting when I&#039;m using the locale
module in this way : 
 
Python 2.3.3 (#2, Feb 24 2004, 09:29:20)  
[GCC 3.3.3 (Debian)] on linux2 
Type "help", "copyright", "credits" or "license" for
more information. 
>>> import locale 
>>> locale.nl_langinfo(locale.CODESET) 
&#039;ANSI_X3.4-1968&#039; 
>>> locale.nl_langinfo(locale.D_T_FMT) 
&#039;%a %b %e %H:%M:%S %Y&#039; 
>>> locale.nl_langinfo(locale.ERA) 
zsh: 27439 segmentation fault  python 


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-03-22 05:05

Message:
Logged In: YES 
user_id=55188

Okay. Checked in 2.3 branch too.
Misc/NEWS 1.831.4.96
Modules/_localemodule.c 2.40.4.3

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2004-03-22 04:51

Message:
Logged In: YES 
user_id=60903

please consider the fix for 2.3 as well.


----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-22 04:45

Message:
Logged In: YES 
user_id=55188

A workaround checked in:
Misc/NEWS 1.956
Modules/_localemodule.c 2.45

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-22 04:40

Message:
Logged In: YES 
user_id=55188

glibc is returning NULL for nl_langinfo(ERA). But it must
return "" instead of NULL according to SUSv2.

Quoting it:

RETURN VALUE

In a locale where langinfo data is not defined,
nl_langinfo() returns a pointer to the corresponding string
in the POSIX locale. In all locales, nl_langinfo() returns a
pointer to an empty string if item contains an invalid setting.

This pointer may point to static data that may be
overwritten on the next call.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=920575&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 15:34:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 15:35:04 2004
Subject: [ python-Bugs-773356 ] posix needs to generate unicode filenames
	where necessary
Message-ID: <E1B59em-0003lS-00@sc8-sf-web2.sourceforge.net>

Bugs item #773356, was opened at 2003-07-17 20:24
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773356&group_id=5470

Category: Python Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: posix needs to generate unicode filenames where necessary

Initial Comment:
Mac OS X supports Unicode filenames.  At the moment this
can&#039;t be enabled because when raising an IOError the
filename embedded in the IOError exception (and perhaps
others) is a plain string.  This attribute should be a
unicode object where necessary.

This can be demonstrated by building on Mac OS X with
the last line of posixpath.py replaced with

if sys.platform == "darwin": 
    supports_unicode_filenames = True
else:
    supports_unicode_filenames = False

and running the interpreter against Lib/test/test_pep277.py.

This needs to be corrected after the 2.3 release.


----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 15:34

Message:
Logged In: YES 
user_id=430343

Fixed in:
NEWS 1.957
fileobject.c 2.189


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-07-19 07:00

Message:
Logged In: YES 
user_id=21627

Python should not generate Unicode strings for the
exceptions at all. Instead, it should return the very same
strings in the exceptions that the user was passing in the
posix operations.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=773356&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 15:53:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 15:53:42 2004
Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more
	strict checking
Message-ID: <E1B59wm-0004F3-00@sc8-sf-web4.sourceforge.net>

Bugs item #847019, was opened at 2003-11-21 21:19
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 7
Submitted By: Michael Dubner (dubnerm)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: datetime.datetime initialization needs more strict checking

Initial Comment:
Friend of mine wrote following program:
---------------------------------
import datetime
t=datetime.datetime(&#039;1995-03-25&#039;)
print t.ctime()
---------------------------------
This is obviously wrong code, but instead of reporting
this at second line python crashes on third line (with
ctime).

Info:
Using Python 2.3.2 on Windows 2000


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-21 15:53

Message:
Logged In: YES 
user_id=31435

Guido, it was assigned to you for (as the comment said) your 
amusement -- we asked each other the odds of anyone 
passing a string here when the backdoor was invented, and 
both thought "na".

What kind of superficial check did you have in mind here?  
The datetime object constructed is insane in 4 of its 7 fields, 
and I have no idea exactly which of those crashes MS's 
library:

>>> import datetime
>>> datetime.datetime('1995-03-25')
datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973)
>>>

Oddly enough, it doesn't appear that the out-of-range year, 
day or microseconds are the problem; forcing the month alone 
into range stops the crash on Windows:

>>> datetime.datetime('19\x0c5-03-25')
datetime.datetime(12601, 12, 53, 45, 48, 51, 2961973)
>>> _.ctime()
'Fri Dec 53 45:48:51 12601'
>>>

So, ya, I could check the month alone, and that would 
prevent this particular crash under MSVC 6.  But there's 
simply no guessing whether other platforms can tolerate the 
insanity remaining, whether this is the only case Windows 
can't tolerate, or whether the kind of crazy datetime object 
constructed just above (which would pass a months-only 
check) could still be used to crash the interpreter after it's 
constructed (the datetime code assumes objects aren't 
insane).


dubnerm:  It's too late to add "dummy fields".  If we did, 
datetime pickles wouldn't be readable across Python releases.

It's unlikely that any by-hand typed string would have a valid 
pickle code for a month in the third byte, so I guess I'll settle 
for that.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:52

Message:
Logged In: YES 
user_id=6380

Not sure why this is assigned to me.

One suggestion: we could do a superficial check that would
catch the above honest mistake without claiming to prevent
all malicious attacks -- malicious pickles aren't something
we try to defend against in general (alas).

----------------------------------------------------------------------

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-24 20:17

Message:
Logged In: YES 
user_id=39274

Can we add dummy fields to change size of backdoor string so
it will not be same as commonly used formats?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-11-24 18:50

Message:
Logged In: YES 
user_id=31435

Na, it's not that simple.  Blazing-fast pickling and unpickling 
was a design goal for datetime.  "Sanity checks" require two-
tailed comparisons on 7 distinct fields, and checking of the 
day field requires month-specific comparison, and may even 
require determing whether it's a leap year.  Doing all that 
would make sucking datetimes out of pickles enormously 
slower than it is now (it's merely a 10-byte string copy now).

If we were willing to do all the checks we do on things coming 
through the front door, we wouldn't call it a back door <wink>.

OTOH, we shouldn't allow a hostile user the ability to crash 
the system via constructing a damaged datetime pickle 
either, so maybe the whole "fast back door" idea is impossible 
to rehabilitate.

----------------------------------------------------------------------

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-23 20:36

Message:
Logged In: YES 
user_id=39274

Of cause i've seen that backdoor, but from my point of view
constructor is not so time-critical that insertion of sanity
chechs will slow down in most (sane) scenarios.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-11-21 22:16

Message:
Logged In: YES 
user_id=31435

LOL!  Assigned to Guido for his amusement.  One string 
argument of exactly size 10 triggers the "secret" backdoor to 
construct a datetime.datetime from a pickle.  The datetime 
constructed here is insane, and provokes Microsoft's library 
into crashing.  In a debug build, it triggers an assertion error 
in the datetime module:

>>> import datetime
[16122 refs]
>>> datetime.datetime('1995-03-25')
datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973)
[16124 refs]
>>> _.ctime()
Assertion failed: month <= 12, file 
C:\Code\python\Modules\datetimemodule.c, line 189

Boosted priority since it's a way to crash the interpreter on 
Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 17:37:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 17:37:21 2004
Subject: [ python-Feature Requests-920680 ] readline not implemented for
	UTF-16
Message-ID: <E1B5BZG-0003zh-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #920680, was opened at 2004-03-21 17:37
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=920680&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline not implemented for UTF-16

Initial Comment:
The StreamReader for UTF-16 (all three of them) doesn&#039;t 
implement readline.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=920680&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 17:44:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 17:44:57 2004
Subject: [ python-Bugs-850981 ] test_poll fails in 2.3.2 on MacOSX(Panther)
Message-ID: <E1B5BgY-0004YX-00@sc8-sf-web4.sourceforge.net>

Bugs item #850981, was opened at 2003-11-28 19:28
Message generated for change (Settings changed) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

>Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Russ Ferriday (russf)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_poll fails in 2.3.2 on MacOSX(Panther)

Initial Comment:
OSX 10.3 (Panther)
Python 2.3.2 source

./configure
make
make test
...
test test_poll crashed -- select.error: (9, &#039;Bad file 
descriptor&#039;)
...
228 tests OK.
1 test failed:
    test_poll
26 tests skipped:
    test_al test_bsddb test_bsddb3 test_cd test_cl test_curses 
test_dl
    test_email_codecs test_gdbm test_gl test_imgfile 
test_largefile
    test_linuxaudiodev test_locale test_mpz test_nis
    test_normalization test_ossaudiodev test_pep277 
test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout 
test_urllibnet
    test_winreg test_winsound
Those skips are all expected on darwin.

Need more info - just ask.
--r





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 17:44:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 17:45:00 2004
Subject: [ python-Feature Requests-920680 ] readline not implemented for
	UTF-16
Message-ID: <E1B5BgZ-0005va-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #920680, was opened at 2004-03-21 23:37
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=920680&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
>Priority: 3
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline not implemented for UTF-16

Initial Comment:
The StreamReader for UTF-16 (all three of them) doesn&#039;t 
implement readline.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-03-21 23:44

Message:
Logged In: YES 
user_id=38388

Patches are welcome :-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=920680&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 17:54:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 17:54:12 2004
Subject: [ python-Feature Requests-920680 ] readline not implemented for
	UTF-16
Message-ID: <E1B5BpW-0000qN-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #920680, was opened at 2004-03-21 17:37
Message generated for change (Comment added) made by etrepum
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=920680&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: readline not implemented for UTF-16

Initial Comment:
The StreamReader for UTF-16 (all three of them) doesn&#039;t 
implement readline.

----------------------------------------------------------------------

>Comment By: Bob Ippolito (etrepum)
Date: 2004-03-21 17:54

Message:
Logged In: YES 
user_id=139309

I don't need it enough to write a patch, but this is what I used instead.. 
and it seems like it might work:

    try:    
        for line in inFile:
            tline = translator(line)
            outFile.write(tline)
    except NotImplementedError:
        BUFFER = 16384
        bytes = inFile.read(BUFFER)
        while bytes:
            lines = bytes.split(u'\n')
            bytes = lines.pop()
            for line in lines:
                tline = translator(line)
                outFile.write(tline)
            newbytes = inFile.read(BUFFER)
            bytes += newbytes
            if not newbytes and bytes:
                bytes += u'\n'

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-03-21 17:44

Message:
Logged In: YES 
user_id=38388

Patches are welcome :-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=920680&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 18:49:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 18:49:48 2004
Subject: [ python-Bugs-847019 ] datetime.datetime initialization needs more
	strict checking
Message-ID: <E1B5ChK-0000J5-00@sc8-sf-web4.sourceforge.net>

Bugs item #847019, was opened at 2003-11-21 21:19
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Michael Dubner (dubnerm)
>Assigned to: Tim Peters (tim_one)
Summary: datetime.datetime initialization needs more strict checking

Initial Comment:
Friend of mine wrote following program:
---------------------------------
import datetime
t=datetime.datetime(&#039;1995-03-25&#039;)
print t.ctime()
---------------------------------
This is obviously wrong code, but instead of reporting
this at second line python crashes on third line (with
ctime).

Info:
Using Python 2.3.2 on Windows 2000


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-21 18:49

Message:
Logged In: YES 
user_id=31435

I added the month sanity check to the date() and datetime() 
constructors.  The original example (or any "like it") raises 
TypeError now.

Lib/test/test_datetime.py; new revision: 1.46
Modules/datetimemodule.c; new revision: 1.71

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-21 15:53

Message:
Logged In: YES 
user_id=31435

Guido, it was assigned to you for (as the comment said) your 
amusement -- we asked each other the odds of anyone 
passing a string here when the backdoor was invented, and 
both thought "na".

What kind of superficial check did you have in mind here?  
The datetime object constructed is insane in 4 of its 7 fields, 
and I have no idea exactly which of those crashes MS's 
library:

>>> import datetime
>>> datetime.datetime('1995-03-25')
datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973)
>>>

Oddly enough, it doesn't appear that the out-of-range year, 
day or microseconds are the problem; forcing the month alone 
into range stops the crash on Windows:

>>> datetime.datetime('19\x0c5-03-25')
datetime.datetime(12601, 12, 53, 45, 48, 51, 2961973)
>>> _.ctime()
'Fri Dec 53 45:48:51 12601'
>>>

So, ya, I could check the month alone, and that would 
prevent this particular crash under MSVC 6.  But there's 
simply no guessing whether other platforms can tolerate the 
insanity remaining, whether this is the only case Windows 
can't tolerate, or whether the kind of crazy datetime object 
constructed just above (which would pass a months-only 
check) could still be used to crash the interpreter after it's 
constructed (the datetime code assumes objects aren't 
insane).


dubnerm:  It's too late to add "dummy fields".  If we did, 
datetime pickles wouldn't be readable across Python releases.

It's unlikely that any by-hand typed string would have a valid 
pickle code for a month in the third byte, so I guess I'll settle 
for that.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 17:52

Message:
Logged In: YES 
user_id=6380

Not sure why this is assigned to me.

One suggestion: we could do a superficial check that would
catch the above honest mistake without claiming to prevent
all malicious attacks -- malicious pickles aren't something
we try to defend against in general (alas).

----------------------------------------------------------------------

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-24 20:17

Message:
Logged In: YES 
user_id=39274

Can we add dummy fields to change size of backdoor string so
it will not be same as commonly used formats?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-11-24 18:50

Message:
Logged In: YES 
user_id=31435

Na, it's not that simple.  Blazing-fast pickling and unpickling 
was a design goal for datetime.  "Sanity checks" require two-
tailed comparisons on 7 distinct fields, and checking of the 
day field requires month-specific comparison, and may even 
require determing whether it's a leap year.  Doing all that 
would make sucking datetimes out of pickles enormously 
slower than it is now (it's merely a 10-byte string copy now).

If we were willing to do all the checks we do on things coming 
through the front door, we wouldn't call it a back door <wink>.

OTOH, we shouldn't allow a hostile user the ability to crash 
the system via constructing a damaged datetime pickle 
either, so maybe the whole "fast back door" idea is impossible 
to rehabilitate.

----------------------------------------------------------------------

Comment By: Michael Dubner (dubnerm)
Date: 2003-11-23 20:36

Message:
Logged In: YES 
user_id=39274

Of cause i've seen that backdoor, but from my point of view
constructor is not so time-critical that insertion of sanity
chechs will slow down in most (sane) scenarios.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-11-21 22:16

Message:
Logged In: YES 
user_id=31435

LOL!  Assigned to Guido for his amusement.  One string 
argument of exactly size 10 triggers the "secret" backdoor to 
construct a datetime.datetime from a pickle.  The datetime 
constructed here is insane, and provokes Microsoft's library 
into crashing.  In a debug build, it triggers an assertion error 
in the datetime module:

>>> import datetime
[16122 refs]
>>> datetime.datetime('1995-03-25')
datetime.datetime(12601, 57, 53, 45, 48, 51, 2961973)
[16124 refs]
>>> _.ctime()
Assertion failed: month <= 12, file 
C:\Code\python\Modules\datetimemodule.c, line 189

Boosted priority since it's a way to crash the interpreter on 
Windows.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=847019&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 19:02:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 19:03:00 2004
Subject: [ python-Bugs-850981 ] test_poll fails in 2.3.2 on MacOSX(Panther)
Message-ID: <E1B5Cu3-0005Kh-00@sc8-sf-web3.sourceforge.net>

Bugs item #850981, was opened at 2003-11-28 19:28
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

Category: Macintosh
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Russ Ferriday (russf)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_poll fails in 2.3.2 on MacOSX(Panther)

Initial Comment:
OSX 10.3 (Panther)
Python 2.3.2 source

./configure
make
make test
...
test test_poll crashed -- select.error: (9, &#039;Bad file 
descriptor&#039;)
...
228 tests OK.
1 test failed:
    test_poll
26 tests skipped:
    test_al test_bsddb test_bsddb3 test_cd test_cl test_curses 
test_dl
    test_email_codecs test_gdbm test_gl test_imgfile 
test_largefile
    test_linuxaudiodev test_locale test_mpz test_nis
    test_normalization test_ossaudiodev test_pep277 
test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout 
test_urllibnet
    test_winreg test_winsound
Those skips are all expected on darwin.

Need more info - just ask.
--r





----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 18:59

Message:
Logged In: YES 
user_id=430343

The poll() function supplied with MacOS 10.3 (panther) is an emulated 
functionality, which is broken for invalid file descriptors (fails to set 
POLLNVAL).  Added check in configure to suppress poll on systems 
where it is broken.

Now test_poll.py is skipped on MacOS X.  When/if poll is fixed, this test 
should be run again.

Fixed in:
configure 1.442
configure.in 1.453
pyconfig.h.in 1.96
selectmodule.c 2.76

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 19:02:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 19:03:05 2004
Subject: [ python-Bugs-850981 ] test_poll fails in 2.3.2 on MacOSX(Panther)
Message-ID: <E1B5Cu8-0005L5-00@sc8-sf-web3.sourceforge.net>

Bugs item #850981, was opened at 2003-11-28 19:28
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Russ Ferriday (russf)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_poll fails in 2.3.2 on MacOSX(Panther)

Initial Comment:
OSX 10.3 (Panther)
Python 2.3.2 source

./configure
make
make test
...
test test_poll crashed -- select.error: (9, &#039;Bad file 
descriptor&#039;)
...
228 tests OK.
1 test failed:
    test_poll
26 tests skipped:
    test_al test_bsddb test_bsddb3 test_cd test_cl test_curses 
test_dl
    test_email_codecs test_gdbm test_gl test_imgfile 
test_largefile
    test_linuxaudiodev test_locale test_mpz test_nis
    test_normalization test_ossaudiodev test_pep277 
test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout 
test_urllibnet
    test_winreg test_winsound
Those skips are all expected on darwin.

Need more info - just ask.
--r





----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 19:02

Message:
Logged In: YES 
user_id=430343

The poll() function supplied with MacOS 10.3 (panther) is an emulated 
functionality, which is broken for invalid file descriptors (fails to set 
POLLNVAL).  Added check in configure to suppress poll on systems 
where it is broken.

Now test_poll.py is skipped on MacOS X.  When/if poll is fixed, this test 
should be run again.

Fixed in:
configure 1.442
configure.in 1.453
pyconfig.h.in 1.96
selectmodule.c 2.76

----------------------------------------------------------------------

Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 18:59

Message:
Logged In: YES 
user_id=430343

The poll() function supplied with MacOS 10.3 (panther) is an emulated 
functionality, which is broken for invalid file descriptors (fails to set 
POLLNVAL).  Added check in configure to suppress poll on systems 
where it is broken.

Now test_poll.py is skipped on MacOS X.  When/if poll is fixed, this test 
should be run again.

Fixed in:
configure 1.442
configure.in 1.453
pyconfig.h.in 1.96
selectmodule.c 2.76

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 19:49:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 19:49:43 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B5Dd8-0003df-00@sc8-sf-web1.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2004-03-22 00:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 19:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 19:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 17:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 08:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 06:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 11:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 19:56:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 19:56:37 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B5DjY-0008H5-00@sc8-sf-web3.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2004-03-22 00:56

Message:
Logged In: YES 
user_id=72053

Two small corrections to below: 1) "in favor of an entropy"
is an editing error--the intended meaning should be obvious.
 2) I meant Bryan Mongeau, not Eric Mongeau.  Bryan's lib is
at <http://eevolved.com/cryptkit/>.  Sorry for any confusion.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-22 00:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 19:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 19:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 17:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 08:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 06:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 11:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 22:39:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 22:39:55 2004
Subject: [ python-Bugs-871026 ] PyOS_snprintf segfaults on missing native
	snprintf
Message-ID: <E1B5GI2-00009O-00@sc8-sf-web3.sourceforge.net>

Bugs item #871026, was opened at 2004-01-05 11:37
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_snprintf segfaults on missing native snprintf

Initial Comment:
On architectures missing a native snprintf (checked on
win32 + Borland), PyOS_snprintf may cause a segfault
when passed a string argument (%s) larger than 512 bytes. 

Btw, allocating an extra 512 bytes and hoping for the
best while calling native vsprintf is also a security
risk (due to buffer overruns.)


----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 22:39

Message:
Logged In: YES 
user_id=430343

Win32 actually *does* have snprintf, but like most functions added to the 
C standard later in life, it's implemented as _snprintf().  Really, it seems 
that the autoconf rule needs to be smarter than just checking for 
snprintf, but rather needs to redefine snprintf as _snprintf on platforms 
that have _snprintf.

Of course, the implementation of PyOS_snprintf still needs fixing.

----------------------------------------------------------------------

Comment By: Federico Di Gregorio (fog)
Date: 2004-01-05 16:12

Message:
Logged In: YES 
user_id=10245

Yes, it causes a segfault when a module using PyOS_snprintf
passes it a string that is bigger than the buffer length +
512. This happens because first vsprintf is called with a
too small buffer and the stack is corrupted and then (too
late!)  there is the check and the fatal error.
Py_FatalError is called (maybe) but the return address is
gone from the stack and all you get is a segfault at the end
of the function.

I know PyOS_snprintf is internal but it can be used by
extension modules and (anyway) growing a buffer 512 bytes
statically is almost the same as using sprintf (without the
'n') directly.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-01-05 12:01

Message:
Logged In: YES 
user_id=31435

Does it really cause a segfault?  This code is trying to cause 
Py_FatalError instead in that case:

else if ((size_t)len >= size + 512)
	Py_FatalError("Buffer overflow in 
PyOS_snprintf/PyOS_vsnprintf");

If that part isn't working, that is indeed a bug.

WRT security, PyOS_snprintf is an internal API function -- 
programs written in Python can't invoke it directly.  If a 
(necessarily) internal use of the function triggers this case, 
that's an error in the coding of the internals, but the *intent* 
is that Py_FatalError() get invoked then anyway, which 
immediately kills the Python process (via C abort()).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470

From noreply at sourceforge.net  Sun Mar 21 23:26:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 21 23:26:25 2004
Subject: [ python-Bugs-871026 ] PyOS_snprintf segfaults on missing native
	snprintf
Message-ID: <E1B5H0p-0006dn-00@sc8-sf-web4.sourceforge.net>

Bugs item #871026, was opened at 2004-01-05 11:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470

Category: Python Interpreter Core
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Federico Di Gregorio (fog)
Assigned to: Nobody/Anonymous (nobody)
Summary: PyOS_snprintf segfaults on missing native snprintf

Initial Comment:
On architectures missing a native snprintf (checked on
win32 + Borland), PyOS_snprintf may cause a segfault
when passed a string argument (%s) larger than 512 bytes. 

Btw, allocating an extra 512 bytes and hoping for the
best while calling native vsprintf is also a security
risk (due to buffer overruns.)


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-21 23:26

Message:
Logged In: YES 
user_id=31435

Nick, Python already uses _snprintf and _vsnprintf under 
MSVC on Windows.  The OP said he tried using Borland on 
Windows, which presumably lacks them (Borland has its own 
runtime libraries, and do note that these things are not part 
of the Win32 API, they're part of the compiler-specific C 
runtime library).

Since snprintf and vsnprintf are required by both POSIX and 
the C99 standard, and are supplied (albeit with a goofy 
spelling, and non-standard endcase behavior) by MSVC, the 
number of platforms they're not available on is both small and 
shrinking.  I doubt any current Python developer uses such a 
platform, so if the OP doesn't care enough to volunteer a 
patch either, we should acknowledge reality and close this as 
WontFix.  (The OP could still ask Borland to modernize their C 
offering, of course -- if Borland is falling behind the times, it's 
not really Python's problem to write a modern C library for 
them.)

----------------------------------------------------------------------

Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 22:39

Message:
Logged In: YES 
user_id=430343

Win32 actually *does* have snprintf, but like most functions added to the 
C standard later in life, it's implemented as _snprintf().  Really, it seems 
that the autoconf rule needs to be smarter than just checking for 
snprintf, but rather needs to redefine snprintf as _snprintf on platforms 
that have _snprintf.

Of course, the implementation of PyOS_snprintf still needs fixing.

----------------------------------------------------------------------

Comment By: Federico Di Gregorio (fog)
Date: 2004-01-05 16:12

Message:
Logged In: YES 
user_id=10245

Yes, it causes a segfault when a module using PyOS_snprintf
passes it a string that is bigger than the buffer length +
512. This happens because first vsprintf is called with a
too small buffer and the stack is corrupted and then (too
late!)  there is the check and the fatal error.
Py_FatalError is called (maybe) but the return address is
gone from the stack and all you get is a segfault at the end
of the function.

I know PyOS_snprintf is internal but it can be used by
extension modules and (anyway) growing a buffer 512 bytes
statically is almost the same as using sprintf (without the
'n') directly.


----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-01-05 12:01

Message:
Logged In: YES 
user_id=31435

Does it really cause a segfault?  This code is trying to cause 
Py_FatalError instead in that case:

else if ((size_t)len >= size + 512)
	Py_FatalError("Buffer overflow in 
PyOS_snprintf/PyOS_vsnprintf");

If that part isn't working, that is indeed a bug.

WRT security, PyOS_snprintf is an internal API function -- 
programs written in Python can't invoke it directly.  If a 
(necessarily) internal use of the function triggers this case, 
that's an error in the coding of the internals, but the *intent* 
is that Py_FatalError() get invoked then anyway, which 
immediately kills the Python process (via C abort()).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=871026&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 06:35:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 06:35:57 2004
Subject: [ python-Bugs-736407 ] Problem With email.MIMEText Package
Message-ID: <E1B5Nij-00066n-00@sc8-sf-web2.sourceforge.net>

Bugs item #736407, was opened at 2003-05-12 09:41
Message generated for change (Comment added) made by judasiscariot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Open
Resolution: None
Priority: 5
Submitted By: John Abel (judasiscariot)
Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Problem With email.MIMEText Package

Initial Comment:
Problem with email.MIMEText.  I created a MIMEText
message (following the example in the documentation). 
The problem occurs when as_string() is called.  This is
the traceback:

  File "/usr/local/lib/python2.3/email/Message.py",
line 113, in as_string
    g.flatten(self, unixfrom=unixfrom)
  File "/usr/local/lib/python2.3/email/Generator.py",
line 102, in flatten
    self._write(msg)
  File "/usr/local/lib/python2.3/email/Generator.py",
line 137, in _write
    self._write_headers(msg)
  File "/usr/local/lib/python2.3/email/Generator.py",
line 183, in _write_headers
    header_name=h, continuation_ws=&#039;\t&#039;).encode()
  File "/usr/local/lib/python2.3/email/Header.py", line
415, in encode
    return self._encode_chunks(newchunks, maxlinelen)
  File "/usr/local/lib/python2.3/email/Header.py", line
375, in _encode_chunks
    _max_append(chunks, s, maxlinelen, extra)
  File "/usr/local/lib/python2.3/email/quopriMIME.py",
line 84, in _max_append
    L.append(s.lstrip())
AttributeError: &#039;list&#039; object has no attribute &#039;lstrip&#039;

I&#039;m using 2.3b1, on RH9.  The same piece of code works
with 2.2.2.


----------------------------------------------------------------------

>Comment By: John Abel (judasiscariot)
Date: 2004-03-22 11:35

Message:
Logged In: YES 
user_id=221478

OK, stripped everything down to a minimum.  I now have a
class, based upon the example from the email docs.  It still
gives the same error, when mailMessage.as_string() is called.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-11-21 20:29

Message:
Logged In: YES 
user_id=12800

There have no follow ups to this message in months, so I'm
moving it to Pending status.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-09-03 12:15

Message:
Logged In: YES 
user_id=12800

Sorry, but you're going to have to work harder at trying to
boil down the buggy code.  When I run ServerMonitor.py, I
get an immediate traceback

Traceback (most recent call last):
  File "ServerMonitor.py", line 18, in ?
    import ThreadUtils, NetMon
ImportError: No module named ThreadUtils

Here's one thing you can try to do: catch the exception in
your code, then pickle the Message object up and post the
pickle.  I can at least reconstitute the pickle and look at
the structure.

Also, I'm guessing the problem is somewhere in ProcessMail()
in PostITControl.py.  Be sure that the mailBody argument is
a string and nothing else.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 08:16

Message:
Logged In: YES 
user_id=221478

The Config.ini will need to modifying to suit your machine
settings.  Run the ServerMonitor.py, and then run
PostITControl.py.  PostITControl.py crashes when trying to
send a mail.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-21 08:13

Message:
Logged In: YES 
user_id=221478

Sorry, been trying to narrow the code down.  If I have a
bare minimum script, it works, yet the original still fails.
 I'll upload the required files (3).

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-19 19:59

Message:
Logged In: YES 
user_id=12800

I'm moving this to Pending since wthout more information I
can't help. This starts the 14 day clock ticking.  After 2
weeks this bug report will be closed, unless someone follows
up with more information.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-15 14:07

Message:
Logged In: YES 
user_id=12800

Sorry, the attached code sample is incomplete.  It is not
sufficient for me to reproduce the problem.

Please boil down your example to a self-contained -- but as
small as possible -- example.

----------------------------------------------------------------------

Comment By: John Abel (judasiscariot)
Date: 2003-05-15 09:32

Message:
Logged In: YES 
user_id=221478

Sorry, forgot the comment.  When running the script using
python2.2 (email 2.4.3), I don't receive any errors, mail
gets sent.  It only seems to happen with 2.3b.

----------------------------------------------------------------------

Comment By: Barry A. Warsaw (bwarsaw)
Date: 2003-05-13 15:45

Message:
Logged In: YES 
user_id=12800

Can you upload the exact code that you wrote that caused
this crash?  Please don't paste it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=736407&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 10:39:12 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 11:02:15 2004
Subject: [ python-Bugs-921077 ] embedding in multi-threaded & multi
	sub-interpreter environ
Message-ID: <E1B5RWC-0002LG-00@sc8-sf-web1.sourceforge.net>

Bugs item #921077, was opened at 2004-03-22 09:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Atul (atulkshirsagar)
Assigned to: Nobody/Anonymous (nobody)
Summary: embedding in multi-threaded & multi sub-interpreter environ

Initial Comment:
I am embedding python in my C++ application. I am 
using Python *2.3.2* with a C++ extention DLL in multi-
threaded environment. I am using SWIG-1.3.19 to 
generate C++ to Python interface.

Now to explain it in details,
1. Python initialization [Py_Initialize()] and finalization 
[Py_Finalize()] is done in the *main* thread.
2. For each new thread I create a separate sub-
interpreter [Py_NewInterpreter()]. 
3. Using PyRun_String("import myModule"...) before 
execution of python script, extention module is imported.
4. Each thread executes *multiple* python script using 
PyEval_EvalCode() using the class objects in my 
extention DLL.
5. Each sub-interpreter is destroyed [Py_EndInterpreter
()] at the end of that particular thread.

I am observing that;
As explained above when multiple threads are running. 
And as one of these threads finishes, in other running 
threads I start getting 
"TypeError: &#039;NoneType&#039; object is not callable" error on 
the methods called on class objects in extention module. 

The same code *works fine* with Python 2.2.2.

I have found these links more or less talking about the 
same problem
migrating from 2.2 to 2.3.
http://mail.python.org/pipermail/python-dev/2003-
September/038237.html
http://mail.python.org/pipermail/python-list/2004-
February/206851.html
http://mail.python.org/pipermail/python-list/2004-
January/204040.html

I *guess* what is happening is global variables are 
zapped to "NoneType"
when one thread finishes and other thread trying to 
access them through the
Python script (step 4.) this error is generated. But it 
*works* sometimes
when(*guess*) the running thread is at step 3. and by 
importing the  module
the global variables are re-initialized for "Type" 
information.

I tried using reload(myModule) to solve the problem but 
that is generating
big memory leak every time it is called.

Is this a know issue with 2.3 (interpreter?) ? Or is there 
a change for 2.3 in the way embedding should be done 
in a multi-threaded and multi-sub-interpreter 
environment ?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 13:31:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 13:31:34 2004
Subject: [ python-Feature Requests-540952 ] Memory Usage Reporting
Message-ID: <E1B5UCr-0003dm-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #540952, was opened at 2002-04-08 05:01
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Usage Reporting

Initial Comment:
I would personally like a way in Python to report how 
many bytes of memory that the interpreter is using 
(perhaps through the sys module)?

If this sort of mechanism is added, then it may allow 
SoftReferences (a la Java) to be introduced, which 
would definitely be useful for memory sensitive 
caches...

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-22 10:31

Message:
Logged In: NO 

What is the minimum worth including?

For instance, objmalloc.c states that it never returns an arena 
to the operating system, so just (narenas * ARENA_SIZE) is an 
upper bound on python-managed generic small object memory. 
Whether that is enough of the used memory (or a tight enough 
bound, in case of good VM), I can't yet judge.

When I have wanted it, it was to ask either "Do I have to 
shrink my cache yet?" or "Is this getting slow because I've 
taken too much memory for the system it is running on".  Both 
probably require more a accurate version.  (Walking the 
individual arenas and pools?)



----------------------------------------------------------------------

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2003-07-28 16:57

Message:
Logged In: YES 
user_id=832557

It would be useful to get some figure(s) about the memory
usage of the current process.

For example, just the 'high water mark' returned by sbrk(0)
on uni* is very helpful in many cases.

I tried the resource.getrusage(resource.RUSAGE_SELF)
function but that does return all zero's in slice [2:6] on
my uni* system.  Not sure whether that is an artifact of the
O/S or Python.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-10 07:03

Message:
Logged In: YES 
user_id=29957

You _can_ do this for most O/Ss, true. The problem is that
it's something that's extremely operating system specific,
and, worse yet, varies significantly between operating 
system releases. Have a look at the source for the system
utility 'top' one day - most of it is in the 'operating 
system specific' section, and there's all sorts of horrible
horrible hoops you have to jump through for different releases.

In addition, the notion of "how much memory is being used"
isn't always that clear in the case of things like shared
libraries.

On the plus side, implementing this would move the HP/UX
threading problem to #2 on the list of "most annoying 
operating-system dependent bugs".

----------------------------------------------------------------------

Comment By: Allan Crooks (amc1)
Date: 2002-04-09 07:45

Message:
Logged In: YES 
user_id=39733

Thanks for the response.

Rather than having an internal way of figuring out how much 
memory is used, is there no external way that we can get 
the OS to return how big the process is?

I know that it is less than elegant, and would have to have 
different platform-dependent code to do this, but it is 
still an idea. I know that Jython can quiz the VM to see 
how much memory is being used, and I'll assume that you can 
do that with different OS's as well...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-08 09:38

Message:
Logged In: YES 
user_id=31435

Allan, this isn't easy, so the cost/benefit ratio is high.  
For the most part, Python gets memory from the system 
malloc, and doesn't even try to keep track of it now; nor 
has it any idea how much overhead (padding, control bytes) 
the system malloc adds; nor is there a portable interface 
to C's malloc for finding out such things.

Still, I agree it would be nice to have such things <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 14:35:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 14:36:18 2004
Subject: [ python-Bugs-765624 ] Cannot step in debugger if line # doesn't
	change
Message-ID: <E1B5VDG-0003N3-00@sc8-sf-web2.sourceforge.net>

Bugs item #765624, was opened at 2003-07-03 17:42
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765624&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot step in debugger if line # doesn't change

Initial Comment:
The debugger trace function is not called with a line
event if the line number executed doesn&#039;t change.  This
happens when an infinite looop containing a single line
is executed, such as:

while 1:
     print 1

A slightly more realistic example would be something
like the following:

        items = range(0, 10)
        try:
                i = 0
                while 1:
                        print items[i]; i += 1
        except IndexError:
                pass


----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-22 14:35

Message:
Logged In: YES 
user_id=430343

Fixed in:

ceval.c 2.386
test_trace.py 1.12

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=765624&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 15:25:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 15:25:58 2004
Subject: [ python-Bugs-716587 ] profile.run makes assumption regarding
	namespace
Message-ID: <E1B5VzN-0004O4-00@sc8-sf-web3.sourceforge.net>

Bugs item #716587, was opened at 2003-04-07 02:56
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 1
Submitted By: Greg Fortune (gregfortune)
Assigned to: Neil Schemenauer (nascheme)
Summary: profile.run makes assumption regarding namespace

Initial Comment:
When profile.run() is executed, it assumes that the local 
and global namespace should be determined from the 
locals and globals for __main__.  In the case of an 
embedded interpreter, this is an annoying assumption.

For instance, I have a PyQt program that has an 
embedded interpreter running as a "debug" console and 
need to profile a little segement of misbehaving code.  
With direct access to all the gui interactively, it seemed 
like a simple task of profiling a function call on one of my 
gui elements, but the namespace in the interpreter is very 
different from that of the main application.

A simple fix is to allow profile.run to be executed with an 
optional dict so the user can give their own namespace.  
A diff -u is attached which accomplishes this.

Note that this problem appears in the current Python CVS 
on sourceforge, but exists at least as early as Python 2.2.


----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-22 15:25

Message:
Logged In: YES 
user_id=430343

Added profile.runctx function which is a simple cover of 
profile.Profile.runctx

Fixed in:
libprofile.tex 1.44
profile.py 1.52
test_profile.py 1.3
test/output/test_profile 1.2
Misc/NEWS 1.958

----------------------------------------------------------------------

Comment By: Neil Schemenauer (nascheme)
Date: 2004-03-21 08:41

Message:
Logged In: YES 
user_id=35752

I always use 'run_call'.  You can easily make a closure to
capture any bindings you want.  Usually it is not necessary.

run_call should be available as a global function and it
should be documented, IMHO.

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2004-03-20 18:40

Message:
Logged In: YES 
user_id=155459

Partially because the only entry point to the profiler mentioned in the 
documentation is profile.run.  If the Profile class were documented, it 
would be a little more obvious how one would work around the 
limitation. 
 
Secondly, the assumption that __main__ is always the desired 
namespace seems limiting and arbitrary.  Anybody wanting to profile 
inside an embedded interpreter is going to have to dig through the 
code the same way I did to identify the problem. 
 
Could the namespace be magically determined based on the function 
that is being profiled?  If so, that is probably an even better solution as 
it becomes a none issue.  At the very least, profile.run should grab the 
namespace from the current interpreter rather than __main__ and 
that's probably better than my initial proposal anyway. 
 
So, it's not a matter of being impossible to work around...  It's just not 
an ideal interface yet. 

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 18:01

Message:
Logged In: YES 
user_id=6380

I don't see the issue. Why can't you use

  prof = profile.Profile()
  prof.runctx(cmd, mydict, mydict)

???


----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-07-09 02:18

Message:
Logged In: YES 
user_id=80475

This seems like a reasonable request.  The use case is 
uncommon but I don't like having __main__ hardwired in 
the code.  What do you think?

If you want the change, should it be put into Py2.3?

----------------------------------------------------------------------

Comment By: Greg Fortune (gregfortune)
Date: 2003-04-07 10:36

Message:
Logged In: YES 
user_id=155459

Doh, sorry about that.  Guess I should actually check it after I 
submit...


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-04-07 08:31

Message:
Logged In: YES 
user_id=6656

There's no uploaded file!  You have to check the
checkbox labeled "Check to Upload & Attach File"
when you upload a file.

Please try again.

(This is a SourceForge annoyance that we can do
nothing about. :-( )

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=716587&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 15:32:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 15:33:02 2004
Subject: [ python-Bugs-850981 ] test_poll fails in 2.3.2 on MacOSX(Panther)
Message-ID: <E1B5W6O-0005YW-00@sc8-sf-web4.sourceforge.net>

Bugs item #850981, was opened at 2003-11-28 19:28
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Russ Ferriday (russf)
Assigned to: Nobody/Anonymous (nobody)
Summary: test_poll fails in 2.3.2 on MacOSX(Panther)

Initial Comment:
OSX 10.3 (Panther)
Python 2.3.2 source

./configure
make
make test
...
test test_poll crashed -- select.error: (9, &#039;Bad file 
descriptor&#039;)
...
228 tests OK.
1 test failed:
    test_poll
26 tests skipped:
    test_al test_bsddb test_bsddb3 test_cd test_cl test_curses 
test_dl
    test_email_codecs test_gdbm test_gl test_imgfile 
test_largefile
    test_linuxaudiodev test_locale test_mpz test_nis
    test_normalization test_ossaudiodev test_pep277 
test_socket_ssl
    test_socketserver test_sunaudiodev test_timeout 
test_urllibnet
    test_winreg test_winsound
Those skips are all expected on darwin.

Need more info - just ask.
--r





----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-22 15:32

Message:
Logged In: YES 
user_id=430343

Back-ported to release23-maint

----------------------------------------------------------------------

Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 19:02

Message:
Logged In: YES 
user_id=430343

The poll() function supplied with MacOS 10.3 (panther) is an emulated 
functionality, which is broken for invalid file descriptors (fails to set 
POLLNVAL).  Added check in configure to suppress poll on systems 
where it is broken.

Now test_poll.py is skipped on MacOS X.  When/if poll is fixed, this test 
should be run again.

Fixed in:
configure 1.442
configure.in 1.453
pyconfig.h.in 1.96
selectmodule.c 2.76

----------------------------------------------------------------------

Comment By: Nick Bastin (mondragon)
Date: 2004-03-21 18:59

Message:
Logged In: YES 
user_id=430343

The poll() function supplied with MacOS 10.3 (panther) is an emulated 
functionality, which is broken for invalid file descriptors (fails to set 
POLLNVAL).  Added check in configure to suppress poll on systems 
where it is broken.

Now test_poll.py is skipped on MacOS X.  When/if poll is fixed, this test 
should be run again.

Fixed in:
configure 1.442
configure.in 1.453
pyconfig.h.in 1.96
selectmodule.c 2.76

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=850981&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 17:26:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 17:27:05 2004
Subject: [ python-Bugs-909230 ] bug in idna-encoding-module
Message-ID: <E1B5Xso-0007vJ-00@sc8-sf-web4.sourceforge.net>

Bugs item #909230, was opened at 2004-03-03 19:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rumpeltux (rumpeltux)
Assigned to: Martin v. L?wis (loewis)
Summary: bug in idna-encoding-module

Initial Comment:
in /usr/lib/python2.3/encodings/idna.py, line 175 it goes:
lables = input.split(&#039;.&#039;)
which causes the interpreter to stop executing the
program, but by changing it to
labels = dots.split(input)
everything&#039;s fine ;)

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-22 23:26

Message:
Logged In: YES 
user_id=21627

I can't see any problem in the code. The invocation of unicode() is 
correct - we just look for the exception that call may raise.

Rumpeltux, can you please report the exact input and exception you get?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-05 20:52

Message:
Logged In: YES 
user_id=33168

Martin, it looks like line 174: unicode(input, "ascii")
should be input = unicode(input, "ascii").
I'm not sure what's supposed to happenning here, but it
looks like the if/else code block may be able to be
rewritten as:

if not isinstance(input, unicode):
    input = unicode(input, "ascii")
labels = dots.split(input)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

From noreply at sourceforge.net  Mon Mar 22 17:59:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 22 18:07:09 2004
Subject: [ python-Bugs-420416 ] Python for BeOS/PPC Build Prob.
Message-ID: <E1B5YOO-0006Wj-00@sc8-sf-web2.sourceforge.net>

Bugs item #420416, was opened at 2001-05-01 06:08
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

Category: Build
Group: Platform-specific
>Status: Closed
>Resolution: Out of Date
Priority: 3
Submitted By: Matthew Schinckel (schinckel)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python for BeOS/PPC Build Prob.

Initial Comment:
When trying to build python(2.1 final) normally under BeOS/PPC 
5, Py_UCS4 does not seem to be defined in 

Includes/unicodeobject.h

(This would seem to indicate that uint and ulong are shorter 
than 4 bits!!!)

I&#039;m guessing this is resultant of a problem elsewhere, but I&#039;m 
too clueless in terms of C(++) to work it out.

----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-22 17:59

Message:
Logged In: YES 
user_id=430343

If you still can't get it to work in 2.1 with a working autoconf, it's fixed in 
2.3.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 12:44

Message:
Logged In: YES 
user_id=6380

Thanks, Jack. I sent a msg to the autoconf list and they
said they would fix it in their CVS. Also they said:

As a workaround (so Python users don't require a CVS or
hacked version of
autoconf), you could strip '-g' from CFLAGS on BeOS (as it
seems to be that
flag that produces the .xSYM file) in configure.in.


----------------------------------------------------------------------

Comment By: Jack Jansen (jackjansen)
Date: 2001-08-08 11:11

Message:
Logged In: YES 
user_id=45365

If I may chime in (but don't you _dare_ assign this item to
me:-): it is the AC_EXEEXT macro that fails, not AC_PROG_CC.
AC_EXEEXT just compiles and links a program, and assumes
that whatever comes out has to be the executable.

But: the Metrowerks compilers/linkers produce 2 files: the
executable (without suffix)
and the debugger symbol table (with .xSYM suffix). AC_EXEEXT
picks the wrong one:-(

Hmm, on my SGI system I can't find the definition of
AC_EXEEXT (??!?) so this is about as much help as I can
give.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-08 10:14

Message:
Logged In: YES 
user_id=6380

OK, thanks for the explanation.  It seems you've hit a snag
in the autoconf AC_PROG_CC macro. I don't know how
successful we'll be in getting this fixed. :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-08-08 01:37

Message:
Logged In: NO 

[Sorry, no https: at work :-(, but it's really Matt.]

Guido, (and anyone else)

The *.xSYM file is created when the -g flag is passed to mwld, the BeOS/PPC linker, in addition to the 
executable file.

The block of the configure script that contains line 1194 is used to determine what the required executable 
extension on the current platform is.  It looks for all files in the current directory that start with conftest, 
and ignores all files that have a .c, .o or .obj extension.  It then (mistakenly, in this case) assumes that the 
file left (conftest.xSYM, and conftest; but conftest.xSYM seems to come first, or take priority) has the 
required extension. 

This is not the required extension for BeOS executables.

Since the ac_link variable has a '-o conftest${ac_exeext}' bit, it expands to -o conftest.xSYM (which, BTW, 
results in conftest.xSYM as the exe, and conftest.xSYM.xSYM as the symbol debugging file when -g is 
passed).

The sizeof(type) programs try to execute said linked program with a simple 'conftest', instead of 
'conftest${ac_exeext}, which would in fact probably work in this case.

Hence, .xSYM is not actually mentioned in the configure script, or in fact in any other file, since it is an 
artifact of the -g flag.

Which leads me to ask, what file is created by (gcc|other c compiler) when -g is passed?

I would try to work out how to fix it in configure.in, but this file still looks like gibberish to me :-)
(At least I have figured out how Makefiles and configures work - sort of)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-06 08:51

Message:
Logged In: YES 
user_id=6380

Matthew, please keep researching deeper.

- The case statement you want to change is inside the
expansion of the AC_PROG_CC macro; it would require a patch
to autoconf to change it the way you want.  This leads to
the following question:

- Why does the configure script use .xSYM?  This must be a
prior mistake; that string doesn't occur at all in the
configure script itself.


----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-08-06 06:52

Message:
Logged In: YES 
user_id=193059

Okay - Finally got it fixed.

change line 1149 of configure from:
      *.c | *.o | *.obj) ;;
to
      *.c | *.o | *.obj | *.xSYM) ;;

(Okay, it was the prompt from GvR that made me really get down to 
it)

Anyway, the -g flag to mwcc causes the debugging info to be put into 
a *.xSYM file, which the configure script seems to think is the 
required extension for an executable (there is none under BeOS).

Since the conftest progs for sizeof(type) have a -o conftest.xSYM, 
and the line that runs them just has a `conftest >...`, the compiled 
programs do not get run, so the size defaults to 0.

Simple.

Now I just need someone to commit this to the cvs tree...:-)

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2001-08-02 15:44

Message:
Logged In: YES 
user_id=6380

I'm afraid it's up to Matthew to figure out why the
configure script calculates zero object sizes.  Sorry... 
(At least try Python 2.1.1, although it may not make a
difference.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-08-02 06:17

Message:
Logged In: YES 
user_id=38388

Assigning the bug report back to None -- someone with more knowledge about autoconf should take a look at this 
one. (It is not Unicode related.)

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-28 06:59

Message:
Logged In: YES 
user_id=193059

Here is the crux of my recent communications with Marc-Andre:

> Okay, I might be guessing a bit here but:
> 
> These programs are supposed to print the sizeof value.
> 
> They are not printing anything.
> 
> The only error being raised is:
> 
> ### mwcc Compiler Warning :
> #       }
> #       ^
> #   return value expected
> #----------------------------------------------------------
>     File "configure"; Line 2245
> #       while compiling "/boot/var/tmp/conftest.c"
> #----------------------------------------------------------
> 

Interesting: the compiler chokes on the missing return statement
in the test program rather than some other error. This is clearly
an autoconf bug and I'm not sure whether it can be fixed in 
Python.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-23 05:20

Message:
Logged In: YES 
user_id=38388

I've uploaded Matthew's config files to SF. Perhaps some
Metroworks wizard could also take a look at these ?!

----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-22 06:12

Message:
Logged In: YES 
user_id=193059

Sorry, I've been on holiday:-)

Donn Cave gave me a patch that allows BeOS to build it, so I'll send 
it along with the config.* files...

(I've zipped them up, but I fear they will not upload with my 
browser.)

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-21 05:46

Message:
Logged In: YES 
user_id=38388

Matthew, if you can not help us here, we won't be able to
resolve the problem.

Please send us the config.* files, so that we can check
where the problem originates.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-07 07:14

Message:
Logged In: YES 
user_id=38388

Hmm, this seems to indicate that the autoconf generated
configure script doesn't work right on BeOS. Could you
attach the config.* files to this bug report ? Perhaps we
can find the cause of configure failing on BeOS.

Thanks.



----------------------------------------------------------------------

Comment By: Matthew Schinckel (schinckel)
Date: 2001-05-07 04:20

Message:
Logged In: YES 
user_id=193059

okay, the config.h file is autogenerated - and all of the SIZEOF_xxx 
constants are set to 0.

That's bad, huh?

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2001-05-02 08:50

Message:
Logged In: YES 
user_id=38388

Looking at unicodeobject.h:

/*
 * Use this typedef when you need to represent a UTF-16
surrogate pair
 * as single unsigned integer.
 */
#if SIZEOF_INT >= 4 
typedef unsigned int Py_UCS4; 
#elif SIZEOF_LONG >= 4
typedef unsigned long Py_UCS4; 
#endif 

it seems that SIZEOF_LONG and/or SIZEOF_INT are not defined
in your config.h file. Does the BeOS-port have its own
special config.h file or is the file generated using
autoconf ? 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=420416&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 05:17:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 05:17:49 2004
Subject: [ python-Bugs-921657 ] HTMLParser ParseError in start tag
Message-ID: <E1B5iyc-0006fr-00@sc8-sf-web2.sourceforge.net>

Bugs item #921657, was opened at 2004-03-23 10:17
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921657&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bernd Zimmermann (bernd_zedv)
Assigned to: Nobody/Anonymous (nobody)
Summary: HTMLParser ParseError in start tag

Initial Comment:
when this - obviously correct html - is parsed:

<a href=mailto:xyz@domain.com>xyz</a>

this exception is raised:
HTMLParseError: junk characters in start 
tag: &#039;@domain.com>&#039;, at line 1, column 1

I work around this by adding &#039;@&#039; to the
allowed character&#039;s class:

import HTMLParser
HTMLParser.attrfind = re.compile(
    r&#039;\s*([a-zA-Z_][-.:a-zA-Z_0-9]*)(\s*=\s*&#039;
    r&#039;(\&#039;[^\&#039;]*\&#039;|"[^"]*"|[-a-zA-Z0-9./,:;+*%?!&$\(\)
_#=~@]*))?&#039;)

myparser = HTMLParser.HTMLParser()
myparser.feed(&#039;<a ... &#039;)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921657&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 11:39:35 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 11:40:06 2004
Subject: [ python-Bugs-876533 ] potential leak in ensure_fromlist (import.c)
Message-ID: <E1B5owB-0002SD-00@sc8-sf-web4.sourceforge.net>

Bugs item #876533, was opened at 2004-01-14 02:15
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876533&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Greg Chapman (glchapman)
Assigned to: Nobody/Anonymous (nobody)
Summary: potential leak in ensure_fromlist (import.c)

Initial Comment:
This may not ever happen, but if the recursive call to 
ensure_fromlist from within ensure_fromlist (line 2106 
in current CVS) returns false, then the function is 
exited without decrefing all.  Attached is a little patch 
for this.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-23 17:39

Message:
Logged In: YES 
user_id=21627

Thanks for the patch. Committed as import.c 2.222.6.2 and 2.227.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876533&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 10:11:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 12:03:46 2004
Subject: [ python-Bugs-893610 ] Segmentation fault running XSV
Message-ID: <E1B5nYz-0008Dc-00@sc8-sf-web2.sourceforge.net>

Bugs item #893610, was opened at 2004-02-09 19:46
Message generated for change (Comment added) made by jbcombes
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893610&group_id=5470

Category: Threads
Group: Python 2.3
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Jean-Baptiste Combes (jbcombes)
Assigned to: Nobody/Anonymous (nobody)
Summary: Segmentation fault running XSV

Initial Comment:
Python 2.3.* segfaults while running XSV. Python 2.2 is OK
I have no clue about what may be the problem.
Here is a backtrace by GDB :

(gdb) run commandLine.py

[New Thread 1024 (LWP 29583)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 29583)]
__pthread_mutex_lock (mutex=0x475) at mutex.c:99
99      mutex.c: No such file or directory.
        in mutex.c
(gdb) bt
#0  __pthread_mutex_lock (mutex=0x475) at mutex.c:99
#1  0x400e2be8 in __libc_free (mem=0x4029d528) at
malloc.c:3152
#2  0x402f0dcf in Item_Dealloc (self=0x4029d528) at
NSLintermodule.c:2641
#3  0x080a7092 in call_function (pp_stack=0xbfffea2c,
oparg=2)
    at Python/ceval.c:3467
#4  0x080a5667 in eval_frame (f=0x818a42c) at
Python/ceval.c:2116
#5  0x080a65f3 in PyEval_EvalCodeEx (co=0x402b6720,
globals=0x40273714, 
    locals=0x0, args=0x81e69d8, argcount=2,
kws=0x81e69e0, kwcount=0, 
    defs=0x403b5a38, defcount=1, closure=0x0) at
Python/ceval.c:2663
#6  0x080a8adb in fast_function (func=0x4025ef7c,
pp_stack=0xbfffebcc, n=2, 
    na=2, nk=0) at Python/ceval.c:3532
#7  0x080a7036 in call_function (pp_stack=0xbfffebcc,
oparg=2)
    at Python/ceval.c:3458
#8  0x080a5667 in eval_frame (f=0x81e6874) at
Python/ceval.c:2116
#9  0x080a8a77 in fast_function (func=0x4025ef0c,
pp_stack=0xbfffecdc, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#10 0x080a7036 in call_function (pp_stack=0xbfffecdc,
oparg=2)
    at Python/ceval.c:3458
#11 0x080a5667 in eval_frame (f=0x816c6d4) at
Python/ceval.c:2116
#12 0x080a8a77 in fast_function (func=0x402afe64,
pp_stack=0xbfffedec, n=2, 
    na=2, nk=0) at Python/ceval.c:3518
#13 0x080a7036 in call_function (pp_stack=0xbfffedec,
oparg=1)
    at Python/ceval.c:3458
---Type <return> to continue, or q <return> to quit---
#14 0x080a5667 in eval_frame (f=0x81bc834) at
Python/ceval.c:2116
#15 0x080a65f3 in PyEval_EvalCodeEx (co=0x402641a0,
globals=0x4027335c, 
    locals=0x0, args=0x40345b00, argcount=3, kws=0x0,
kwcount=0, 
    defs=0x402b2db8, defcount=2, closure=0x0) at
Python/ceval.c:2663
#16 0x080e3def in function_call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/funcobject.c:504
#17 0x0805a004 in PyObject_Call (func=0x402afe2c,
arg=0x40345af4, kw=0x0)
    at Objects/abstract.c:1755
#18 0x08060cc3 in instancemethod_call (func=0x402afe2c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:2433
#19 0x0805a004 in PyObject_Call (func=0x403c6c84,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#20 0x080a82ab in PyEval_CallObjectWithKeywords
(func=0x403c6c84, 
    arg=0x4020d2ec, kw=0x0) at Python/ceval.c:3346
#21 0x0805cd5f in PyInstance_New (klass=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/classobject.c:575
#22 0x0805a004 in PyObject_Call (func=0x402c2b6c,
arg=0x4020d2ec, kw=0x0)
    at Objects/abstract.c:1755
#23 0x080a8b66 in do_call (func=0x402c2b6c,
pp_stack=0xbffff2cc, na=2, nk=0)
    at Python/ceval.c:3644
#24 0x080a704d in call_function (pp_stack=0xbffff2cc,
oparg=2)
    at Python/ceval.c:3460
#25 0x080a5667 in eval_frame (f=0x814867c) at
Python/ceval.c:2116
---Type <return> to continue, or q <return> to quit---
#26 0x080a65f3 in PyEval_EvalCodeEx (co=0x40206520,
globals=0x401feb54, 
    locals=0x0, args=0x8159db0, argcount=12,
kws=0x8159de0, kwcount=0, 
    defs=0x40277620, defcount=11, closure=0x0) at
Python/ceval.c:2663
#27 0x080a8adb in fast_function (func=0x40347144,
pp_stack=0xbffff46c, n=12, 
    na=12, nk=0) at Python/ceval.c:3532
#28 0x080a7036 in call_function (pp_stack=0xbffff46c,
oparg=12)
    at Python/ceval.c:3458
#29 0x080a5667 in eval_frame (f=0x8159c04) at
Python/ceval.c:2116
#30 0x080a65f3 in PyEval_EvalCodeEx (co=0x402062e0,
globals=0x401feb54, 
    locals=0x0, args=0x819303c, argcount=15,
kws=0x8193078, kwcount=0, 
    defs=0x4026c628, defcount=14, closure=0x0) at
Python/ceval.c:2663
#31 0x080a8adb in fast_function (func=0x4034709c,
pp_stack=0xbffff60c, n=15, 
    na=15, nk=0) at Python/ceval.c:3532
#32 0x080a7036 in call_function (pp_stack=0xbffff60c,
oparg=15)
    at Python/ceval.c:3458
#33 0x080a5667 in eval_frame (f=0x8192ea4) at
Python/ceval.c:2116
#34 0x080a8a77 in fast_function (func=0x40202c34,
pp_stack=0xbffff71c, n=1, 
    na=1, nk=0) at Python/ceval.c:3518
#35 0x080a7036 in call_function (pp_stack=0xbffff71c,
oparg=1)
    at Python/ceval.c:3458
#36 0x080a5667 in eval_frame (f=0x812444c) at
Python/ceval.c:2116
#37 0x080a65f3 in PyEval_EvalCodeEx (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c, args=0x0, argcount=0, kws=0x0,
kwcount=0, defs=0x0, 
---Type <return> to continue, or q <return> to quit---
    defcount=0, closure=0x0) at Python/ceval.c:2663
#38 0x080a8976 in PyEval_EvalCode (co=0x401ff2e0,
globals=0x401b879c, 
    locals=0x401b879c) at Python/ceval.c:542
#39 0x080c4db1 in run_node (n=0x4019f488, 
    filename=0xbffffa73 "commandLine.py",
globals=0x401b879c, locals=0x401b879c, 
    flags=0xbffff89c) at Python/pythonrun.c:1265
#40 0x080c3781 in PyRun_SimpleFileExFlags (fp=0x8122288, 
    filename=0xbffffa73 "commandLine.py", closeit=1,
flags=0xbffff89c)
    at Python/pythonrun.c:862
#41 0x0805506a in Py_Main (argc=2, argv=0xbffff934) at
Modules/main.c:415
#42 0x4007e507 in __libc_start_main (main=0x8054980
<main>, argc=2, 
    ubp_av=0xbffff934, init=0x8053cb0 <_init>,
fini=0x80e6ae0 <_fini>, 
    rtld_fini=0x4000dc14 <_dl_fini>, stack_end=0xbffff92c)
    at ../sysdeps/generic/libc-start.c:129
(gdb) 


----------------------------------------------------------------------

>Comment By: Jean-Baptiste Combes (jbcombes)
Date: 2004-03-23 16:11

Message:
Logged In: YES 
user_id=116408

Thanks tjreedy. I lack time to track it down, so => close.
Also a segfault noted on Solaris 2.8 

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-02-14 00:45

Message:
Logged In: YES 
user_id=593130

I know nothing of XSV, even if it is C or Python coded, so 
can only offer generic comment:  You are more likely to get 
attention of voluteer patchers if you can pinpoint the line of 
XSV code inducing the segfault.

>It works on Linux Mandrake 9.1, and segfaults
on redhat 7.2

The header lines displayed in interactive mode describing the 
respective builds might help explain.  A possible reason is a 
bug in the compiler or compilation mode (such as 
optimization) in one and not the other.

Good luck.  This is beyond my competance.

----------------------------------------------------------------------

Comment By: Jean-Baptiste Combes (jbcombes)
Date: 2004-02-10 16:54

Message:
Logged In: YES 
user_id=116408

Quite strange. It works on Linux Mandrake 9.1, and segfaults
on redhat 7.2.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=893610&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 11:17:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 12:04:00 2004
Subject: [ python-Bugs-909230 ] bug in idna-encoding-module
Message-ID: <E1B5oaN-0006b3-00@sc8-sf-web2.sourceforge.net>

Bugs item #909230, was opened at 2004-03-03 18:13
Message generated for change (Comment added) made by rumpeltux
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rumpeltux (rumpeltux)
Assigned to: Martin v. L?wis (loewis)
Summary: bug in idna-encoding-module

Initial Comment:
in /usr/lib/python2.3/encodings/idna.py, line 175 it goes:
lables = input.split(&#039;.&#039;)
which causes the interpreter to stop executing the
program, but by changing it to
labels = dots.split(input)
everything&#039;s fine ;)

----------------------------------------------------------------------

>Comment By: Rumpeltux (rumpeltux)
Date: 2004-03-23 16:17

Message:
Logged In: YES 
user_id=989758

>>> unicode('xn--mller-kva.de', 'idna')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/encodings/idna.py", line 175, in
decode
    labels = input.split(".")
AttributeError: 'buffer' object has no attribute 'split'


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-22 22:26

Message:
Logged In: YES 
user_id=21627

I can't see any problem in the code. The invocation of unicode() is 
correct - we just look for the exception that call may raise.

Rumpeltux, can you please report the exact input and exception you get?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-05 19:52

Message:
Logged In: YES 
user_id=33168

Martin, it looks like line 174: unicode(input, "ascii")
should be input = unicode(input, "ascii").
I'm not sure what's supposed to happenning here, but it
looks like the if/else code block may be able to be
rewritten as:

if not isinstance(input, unicode):
    input = unicode(input, "ascii")
labels = dots.split(input)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 12:18:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 12:18:09 2004
Subject: [ python-Bugs-921868 ] socket_htons does not work under AIX 64-bit
Message-ID: <E1B5pXS-0006UG-00@sc8-sf-web4.sourceforge.net>

Bugs item #921868, was opened at 2004-03-23 12:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921868&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Marshall (john_marshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket_htons does not work under AIX 64-bit

Initial Comment:
The socket tests fail for htons under AIX when Python 
is compiled for 64 bits (OBJECTMODE=64). It seems 
that this is easily (?) fixed if the socket_htons() 
code is modified to be close to the socket_ntohs() 
code in Modules/socketmodule.c. 
 
Please see the attachment for the change I did which 
allows the socketmodule.c to function as expected. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921868&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 13:00:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 13:00:08 2004
Subject: [ python-Bugs-921898 ] socket_htons does not work under AIX 64-bit
Message-ID: <E1B5qC3-0001UR-00@sc8-sf-web2.sourceforge.net>

Bugs item #921898, was opened at 2004-03-23 13:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921898&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Marshall (john_marshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket_htons does not work under AIX 64-bit

Initial Comment:
The socket tests fail for htons under AIX when Python 
is compiled for 64 bits (OBJECTMODE=64). It seems 
that this is easily (?) fixed if the socket_htons() 
code is modified to be close to the socket_ntohs() 
code in Modules/socketmodule.c. 
 
Please see the attachment for the change I did which 
allows the socketmodule.c to function as expected. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921898&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 13:01:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 13:01:32 2004
Subject: [ python-Bugs-921898 ] socket_htons does not work under AIX 64-bit
Message-ID: <E1B5qDM-0001ck-00@sc8-sf-web2.sourceforge.net>

Bugs item #921898, was opened at 2004-03-23 13:00
Message generated for change (Settings changed) made by john_marshall
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921898&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: John Marshall (john_marshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket_htons does not work under AIX 64-bit

Initial Comment:
The socket tests fail for htons under AIX when Python 
is compiled for 64 bits (OBJECTMODE=64). It seems 
that this is easily (?) fixed if the socket_htons() 
code is modified to be close to the socket_ntohs() 
code in Modules/socketmodule.c. 
 
Please see the attachment for the change I did which 
allows the socketmodule.c to function as expected. 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921898&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 16:37:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 17:02:41 2004
Subject: [ python-Bugs-639311 ] urllib.basejoin() mishandles ''
Message-ID: <E1B5ta8-00071e-00@sc8-sf-web4.sourceforge.net>

Bugs item #639311, was opened at 2002-11-16 04:34
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

Category: Python Library
Group: Python 2.2.1
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.basejoin() mishandles ''

Initial Comment:
It&#039;s not entirely clear whether urllib.basejoin() intends to 
implement RFC 2396&#039;s "resolution of relative URI 
references to absolute form" faithfully, but it seems to 
behave improperly when given an empty string as the 
relative URI to make absolute.

>>> from urllib import basejoin
>>> basejoin(&#039;http://host/foo/bar.xml&#039;,&#039;&#039;)
&#039;http://host/foo/&#039;

I believe it should return the base as-is, because the 
empty string is a reference to the document that 
contains that reference... and presumably the 
document&#039;s URI is what you&#039;re passing in as the base.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 13:37

Message:
Logged In: YES 
user_id=357491

I disagree with what you are expecting.  For instance, if you run 
``urllib.basejoin("http://python.org/index.html", "/doc")`` it returns 
"http://python.org/dev", which makes sense.  So changing its behavior 
based on it being an empty string would not strictly match how the 
function works when compared to being given any string.

And on top of things the function is not even documented, so you really 
shouldn't be expecting any specific behavior.

Closing this as invalid.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-21 20:14

Message:
Logged In: YES 
user_id=357491

Perhaps urllib.basejoin (which is not documented) should just become a 
wrapper for urlparse.urljoin ?  It won't solve this bug but it would cut back 
on unneeded code.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2002-11-26 02:41

Message:
Logged In: YES 
user_id=371366

I was partly mistaken; the document's URI is not necessarily 
the base. A reference with an empty path (e.g., an empty 
string or just a fragment identifier) is a reference to the current 
document, regardless of the base URI you are resolving 
against. A base URI is only for resolving relative URIs that are 
not referencing the current document. See some discussion 
at http://lists.w3.org/Archives/Public/uri/2002Jan/0015.html

So neither urllib.basejoin() nor urlparse.urljoin() fully 
implement the RFC 2396 "resolution to absolute form", since 
there would need to be a way to indicate "current document" 
other than returning the base.

Nevertheless, basejoin()'s behavior differs from urlparse.urljoin
()'s when presented with the empty string, and it's not clear 
whether that is intentional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 16:13:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 17:02:45 2004
Subject: [ python-Bugs-706253 ] python accepts illegal "import mod.sub as
	name" syntax
Message-ID: <E1B5tDE-0003E3-00@sc8-sf-web1.sourceforge.net>

Bugs item #706253, was opened at 2003-03-19 04:44
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470

Category: Python Interpreter Core
>Group: None
Status: Closed
Resolution: Out of Date
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: python accepts illegal "import mod.sub as name" syntax

Initial Comment:
http://python.org/doc/current/ref/import.html
"To avoid confusion, you cannot import modules with
dotted names as a different local name. So import
module as m is legal, but import module.submod as s is
not."

sadly the interpreter accepts the illegal form without
comment which makes it "semi-legal".
packages that rely on this illegal form may cause
trouble with costum import implementations (i.e.
importing from zip file or similar)

tested with 2.2.2 and 2.3a2

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 13:13

Message:
Logged In: YES 
user_id=357491

Fixed in 2.3 and 2.4 (but not in 2.2.3), so closing as out of date.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 13:13

Message:
Logged In: YES 
user_id=357491

Fixed in 2.3 and 2.4 (but not in 2.2.3), so closing as out of date.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 15:19

Message:
Logged In: YES 
user_id=357491

That line seems to have been removed from the 2.3 
documentation as of revision 1.60 but it was not backported.  
Need to find out from Martin v. Lowis whether there is a reason 
he didn't backport it.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-03-25 14:21

Message:
Logged In: YES 
user_id=699438

Here's a case where I think the documentation should be 
fixed instead of the bug.  Every COM project I do starts 
with 'import win32com.client as client'.  I also don't see how 
one syntax is any more confusing than the other.  And even if 
the above syntax was illegal, you could still do something like:

>>> import win32com.client
>>> server = win32com.client

If you really wanted to be confusing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 16:13:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 17:03:08 2004
Subject: [ python-Bugs-706253 ] python accepts illegal "import mod.sub as
	name" syntax
Message-ID: <E1B5tD7-0003DD-00@sc8-sf-web1.sourceforge.net>

Bugs item #706253, was opened at 2003-03-19 04:44
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470

Category: Python Interpreter Core
>Group: Python 2.2.3
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Alexander Miseler (amiseler)
Assigned to: Nobody/Anonymous (nobody)
Summary: python accepts illegal "import mod.sub as name" syntax

Initial Comment:
http://python.org/doc/current/ref/import.html
"To avoid confusion, you cannot import modules with
dotted names as a different local name. So import
module as m is legal, but import module.submod as s is
not."

sadly the interpreter accepts the illegal form without
comment which makes it "semi-legal".
packages that rely on this illegal form may cause
trouble with costum import implementations (i.e.
importing from zip file or similar)

tested with 2.2.2 and 2.3a2

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 13:13

Message:
Logged In: YES 
user_id=357491

Fixed in 2.3 and 2.4 (but not in 2.2.3), so closing as out of date.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-06-08 15:19

Message:
Logged In: YES 
user_id=357491

That line seems to have been removed from the 2.3 
documentation as of revision 1.60 but it was not backported.  
Need to find out from Martin v. Lowis whether there is a reason 
he didn't backport it.

----------------------------------------------------------------------

Comment By: logistix (logistix)
Date: 2003-03-25 14:21

Message:
Logged In: YES 
user_id=699438

Here's a case where I think the documentation should be 
fixed instead of the bug.  Every COM project I do starts 
with 'import win32com.client as client'.  I also don't see how 
one syntax is any more confusing than the other.  And even if 
the above syntax was illegal, you could still do something like:

>>> import win32com.client
>>> server = win32com.client

If you really wanted to be confusing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=706253&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 18:15:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 18:15:18 2004
Subject: [ python-Bugs-639311 ] urllib.basejoin() mishandles ''
Message-ID: <E1B5v70-0006L6-00@sc8-sf-web1.sourceforge.net>

Bugs item #639311, was opened at 2002-11-16 05:34
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.basejoin() mishandles ''

Initial Comment:
It&#039;s not entirely clear whether urllib.basejoin() intends to 
implement RFC 2396&#039;s "resolution of relative URI 
references to absolute form" faithfully, but it seems to 
behave improperly when given an empty string as the 
relative URI to make absolute.

>>> from urllib import basejoin
>>> basejoin(&#039;http://host/foo/bar.xml&#039;,&#039;&#039;)
&#039;http://host/foo/&#039;

I believe it should return the base as-is, because the 
empty string is a reference to the document that 
contains that reference... and presumably the 
document&#039;s URI is what you&#039;re passing in as the base.

----------------------------------------------------------------------

>Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-23 16:15

Message:
Logged In: YES 
user_id=371366

Well, it is documented as "Utility to combine a URL with a 
base URL to form a new URL".

The notion of 'base URL' is described in the RFCs mentioned in 
urllib.__doc__ (all of which predate RFC 2396, I notice, 
though it doesn't matter) and is exclusively applicable to 
relative URL/URI reference resolution, a process in which an 
empty path denotes a same-document reference / no 
traversal from the origin. So I don't think it was unreasonable 
of me to have an expectation that basejoin() would be at 
least somewhat conformant to the specs that its parent 
module purports to implement.

And it actually *is* conformant when the relative URL 
consists of just a query or fragment; the empty path doesn't 
result in the tail of the base URL being chopped off before the 
query or fragment is added/replaced. So this lends further 
credence to the notion that the intent was to be conformant.

Furthermore, in the one and only place where it is used in 
core python libs at all (in urllib.FancyURLOpener), basejoin() 
is used in a way that would give a wrong result, if left as-is: 
to derive an absolute URL so a redirect can be followed, when 
given a relative URL in the Location header of an HTTP 302 
response. Granted, the odds of this header being empty are 
slim, but still. It's a bug in FancyURLOpener.redirect_internal, 
at least.

Nevertheless, I am now of the opinion that anyone serious 
about conformant URL handling will avoid urllib. In 4Suite I 
have implemented wrappers and replacements for the 
functions we need. See also bug #649962.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 14:37

Message:
Logged In: YES 
user_id=357491

I disagree with what you are expecting.  For instance, if you run 
``urllib.basejoin("http://python.org/index.html", "/doc")`` it returns 
"http://python.org/dev", which makes sense.  So changing its behavior 
based on it being an empty string would not strictly match how the 
function works when compared to being given any string.

And on top of things the function is not even documented, so you really 
shouldn't be expecting any specific behavior.

Closing this as invalid.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-21 20:14

Message:
Logged In: YES 
user_id=357491

Perhaps urllib.basejoin (which is not documented) should just become a 
wrapper for urlparse.urljoin ?  It won't solve this bug but it would cut back 
on unneeded code.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2002-11-26 03:41

Message:
Logged In: YES 
user_id=371366

I was partly mistaken; the document's URI is not necessarily 
the base. A reference with an empty path (e.g., an empty 
string or just a fragment identifier) is a reference to the current 
document, regardless of the base URI you are resolving 
against. A base URI is only for resolving relative URIs that are 
not referencing the current document. See some discussion 
at http://lists.w3.org/Archives/Public/uri/2002Jan/0015.html

So neither urllib.basejoin() nor urlparse.urljoin() fully 
implement the RFC 2396 "resolution to absolute form", since 
there would need to be a way to indicate "current document" 
other than returning the base.

Nevertheless, basejoin()'s behavior differs from urlparse.urljoin
()'s when presented with the empty string, and it's not clear 
whether that is intentional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

From noreply at sourceforge.net  Tue Mar 23 18:30:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 23 18:30:23 2004
Subject: [ python-Feature Requests-531145 ] socket.sslerror is not a
	socket.error
Message-ID: <E1B5vLe-0008Gv-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #531145, was opened at 2002-03-17 15:14
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=531145&group_id=5470

>Category: None
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 3
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sslerror is not a socket.error

Initial Comment:
Python 2.1.2 (#1, Mar 16 2002, 00:56:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
>>> socket.sslerror
<class socket.sslerror at 0x809c39c>
>>> try: raise socket.sslerror
... except socket.error: pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.sslerror
>>> 


----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 15:30

Message:
Logged In: YES 
user_id=357491

socket.sslerror is now a subclass of socket.error thanks to extending the 
socket module's C API.  Done in:

Misc/NEWS 1.960
Modules/socketmodule.h 1.12
Modules/socketmodule.c 1.286
Modules_ssl.c 1.16

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-16 18:42

Message:
Logged In: YES 
user_id=357491

Well, I have no issue with wanting to make socket.sslerror a subclass of 
socket.error, but socket.sslerror is not even documented so I don't see this 
as an issue until socket.sslerror is documented.

So this will need a doc patch on top of any patch to make the  change to 
socket.sslerror.

----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-02-04 08:19

Message:
Logged In: YES 
user_id=670441

If this behavior is desired, the patch below implements it.  If it's not desired, this bug sould be closed.

It isn't much work at all.  test_socket and test_socket_ssl still pass fine.  The following case will work after this patch, all other combinations will work as before:

>>> try: raise socket.sslerror
... except socket.error: print 'caught'
caught
>>>

patch (I cannot attach the file in sourceforge for some reason):
Index: dist/src/Modules/socketmodule.h
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.h,v
retrieving revision 1.8
diff -c -r1.8 socketmodule.h
*** dist/src/Modules/socketmodule.h	13 Jun 2002 15:07:44 -0000	1.8
--- dist/src/Modules/socketmodule.h	4 Feb 2003 16:05:27 -0000
***************
*** 140,145 ****
--- 140,146 ----
  /* C API for usage by other Python modules */
  typedef struct {
  	PyTypeObject *Sock_Type;
+         PyObject *Sock_Error;
  } PySocketModule_APIObject;
  
  /* XXX The net effect of the following appears to be to define a function
Index: dist/src/Modules/socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.251
diff -c -r1.251 socketmodule.c
*** dist/src/Modules/socketmodule.c	6 Jan 2003 12:41:26 -0000	1.251
--- dist/src/Modules/socketmodule.c	4 Feb 2003 16:05:43 -0000
***************
*** 3117,3122 ****
--- 3117,3123 ----
  PySocketModule_APIObject PySocketModuleAPI =
  {
  	&sock_type,
+         NULL,
  };
  
  
***************
*** 3178,3183 ****
--- 3179,3185 ----
  		return;
  
  	/* Export C API */
+         PySocketModuleAPI.Sock_Error = socket_error;
  	if (PyModule_AddObject(m, PySocket_CAPI_NAME,
  	       PyCObject_FromVoidPtr((void *)&PySocketModuleAPI, NULL)
  				 ) != 0)
Index: dist/src/Modules/_ssl.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_ssl.c,v
retrieving revision 1.9
diff -c -r1.9 _ssl.c
*** dist/src/Modules/_ssl.c	27 Jan 2003 22:19:21 -0000	1.9
--- dist/src/Modules/_ssl.c	4 Feb 2003 16:05:45 -0000
***************
*** 543,549 ****
  	SSLeay_add_ssl_algorithms();
  
  	/* Add symbols to module dict */
! 	PySSLErrorObject = PyErr_NewException("socket.sslerror", NULL, NULL);
  	if (PySSLErrorObject == NULL)
  		return;
  	PyDict_SetItemString(d, "sslerror", PySSLErrorObject);
--- 543,549 ----
  	SSLeay_add_ssl_algorithms();
  
  	/* Add symbols to module dict */
! 	PySSLErrorObject = PyErr_NewException("socket.sslerror", PySocketModule.Sock_Error, NULL);
  	if (PySSLErrorObject == NULL)
  		return;
  	PyDict_SetItemString(d, "sslerror", PySSLErrorObject);


----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2002-11-11 09:12

Message:
Logged In: YES 
user_id=9205

Yes, I want socket.sslerror to be a subclass of
socket.error. It simplifies code layout (see my previous
answer) and it follows the documentation.
And yes, its work, but only a little :)

----------------------------------------------------------------------

Comment By: Gerhard H?ring (ghaering)
Date: 2002-10-04 17:05

Message:
Logged In: YES 
user_id=163326

So do you propose to make socket.sslerror a subclass of
socket.error. Is this desirable? I'm not sure. Is it work? Yes.

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2002-03-18 12:23

Message:
Logged In: YES 
user_id=9205

The documentation says for socket.error: "This exception is
raised for socket- or address-related errors." I think
socket.sslerror is such an error, because then you can write

try: sock.write("") # could be ssl-socket
except socket.error: pass

The other way would be
_exceptions = [socket.error]
if hasattr(socket, "sslerror"):
    _exceptions.append(socket.sslerror)
try: sock.write("")
except _exceptions: pass

Anyway, I assume this is a minor "bug".

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-03-18 02:44

Message:
Logged In: YES 
user_id=21627

Why is this a bug?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=531145&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 06:31:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 06:34:33 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B66bM-0004jb-00@sc8-sf-web1.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-24 06:31

Message:
Logged In: YES 
user_id=80475

I attached a new version of the mt/sha1 combination.

Here are the relative merits as compared sha1/sha1 approach:
* simpiler to implement/maintain since state tracking is builtin
* larger state space (2**19937 vs 2**160)
* faster
* threadsafe

Favoring sha1/sha1:
* uses only one primitive
* easier to replace in situations where MT is not available


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-21 19:56

Message:
Logged In: YES 
user_id=72053

Two small corrections to below: 1) "in favor of an entropy"
is an editing error--the intended meaning should be obvious.
 2) I meant Bryan Mongeau, not Eric Mongeau.  Bryan's lib is
at <http://eevolved.com/cryptkit/>.  Sorry for any confusion.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-21 19:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 14:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 14:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 12:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 03:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 01:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 06:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 04:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 11:40:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 11:41:02 2004
Subject: [ python-Bugs-909230 ] bug in idna-encoding-module
Message-ID: <E1B6BR3-0001jc-00@sc8-sf-web1.sourceforge.net>

Bugs item #909230, was opened at 2004-03-03 19:13
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rumpeltux (rumpeltux)
Assigned to: Martin v. L?wis (loewis)
Summary: bug in idna-encoding-module

Initial Comment:
in /usr/lib/python2.3/encodings/idna.py, line 175 it goes:
lables = input.split(&#039;.&#039;)
which causes the interpreter to stop executing the
program, but by changing it to
labels = dots.split(input)
everything&#039;s fine ;)

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-24 17:40

Message:
Logged In: YES 
user_id=21627

This is now fixed in idna.py 1.4 and 1.2.12.2, by converting input to a 
string object. I leave this open to find out why there is a buffer object in 
the first place.

----------------------------------------------------------------------

Comment By: Rumpeltux (rumpeltux)
Date: 2004-03-23 17:17

Message:
Logged In: YES 
user_id=989758

>>> unicode('xn--mller-kva.de', 'idna')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/encodings/idna.py", line 175, in
decode
    labels = input.split(".")
AttributeError: 'buffer' object has no attribute 'split'


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-22 23:26

Message:
Logged In: YES 
user_id=21627

I can't see any problem in the code. The invocation of unicode() is 
correct - we just look for the exception that call may raise.

Rumpeltux, can you please report the exact input and exception you get?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-05 20:52

Message:
Logged In: YES 
user_id=33168

Martin, it looks like line 174: unicode(input, "ascii")
should be input = unicode(input, "ascii").
I'm not sure what's supposed to happenning here, but it
looks like the if/else code block may be able to be
rewritten as:

if not isinstance(input, unicode):
    input = unicode(input, "ascii")
labels = dots.split(input)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 11:55:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 11:55:58 2004
Subject: [ python-Bugs-812376 ] Problem with ftplib on HP-UX11i
Message-ID: <E1B6BfS-0005bK-00@sc8-sf-web3.sourceforge.net>

Bugs item #812376, was opened at 2003-09-25 12:10
Message generated for change (Comment added) made by rptownsend
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Richard Townsend (rptownsend)
Assigned to: Nobody/Anonymous (nobody)
Summary: Problem with ftplib on HP-UX11i

Initial Comment:
The following code fails on Python 2.3 (and 2.3.1).

import ftplib
f = ftplib.FTP()
f.connect(&#039;hostname&#039;, 21)

this raises:

socket.gaierror: (8, &#039;host nor service provided, or not 
known&#039;)

In FTP.connect() it is the call to socket.getaddrinfo() 
that is raising the exception.

The same code works OK on Python 2.2.1

If I pass an IP address instead of a hostname, the code 
runs OK on Python 2.3



----------------------------------------------------------------------

>Comment By: Richard Townsend (rptownsend)
Date: 2004-03-24 16:55

Message:
Logged In: YES 
user_id=200117

I have just tested this on Python 2.3.3 (sorry about the 
delay) and now it runs with no errors!


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-10-01 11:11

Message:
Logged In: YES 
user_id=200117

I tried dropping different versions of socketmodule.c & 
socketmodule.h into Python-2.3.1 and re-building.

The earliest version of socketmodule.c I could build & run was 
1.219 and this does raise the exception for a hostname that 
needs to be resolved via NIS.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 15:48

Message:
Logged In: YES 
user_id=29957

Darn. There's probably something Not Quite Right with how
socketmodule.c interacts with HP/UX's NIS, then. I'm not
sure what the problem would be, and I don't have access to a
HP/UX box that uses NIS for hostnames, so I'm not able to
help... 

As previously mentioned, there's a _lot_ of changes been
made to socketmodule.c between 2.2 and 2.3. If you're
CVS-savvy, you might like to try checking out different
versions between 2.200 (the version in 2.2) and 2.270 (the
version in 2.3) to narrow down exactly when the module stops
working.

One thing - "_" isn't supposed to be legal in domain names,
I don't know if that's related (although the other name has
no underscores...)


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 14:56

Message:
Logged In: YES 
user_id=200117

The hostnames I have tried are 'tate_mod' and 'rosalind'.
Lookup is by NIS. I can ping and remote login to these 
workstations using their hostnames.

I have since discovered that if I add an entry to /etc/hosts 
specifying a different hostname 'fred' and rosalind's IP 
address, then f.connect('fred', 21) doesn't give the error.


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 14:01

Message:
Logged In: YES 
user_id=29957

Hm. What's the actual hostname you're trying? I can't get
this failure on HP/UX 11.11, using the HP testdrive box. 

Are you using NIS or some other non-standard method of
hostname lookup? The problem is that there's a fair bit
changed between 2.2 and 2.3's socket module (there was 71
different checkins).


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-30 13:21

Message:
Logged In: YES 
user_id=200117

Apologies for not being clear.

I actually used the real hostname (in quotes) of a workstation 
on our local network in place of 'hostname'.

If I use 'localhost' or the hostname of the workstation the 
application is running on, I don't get the error.

If I use the hostname of any other workstation on the local 
network, I do get the error.

Running exactly the same code on Python 2.2.1 works OK for 
all hostnames.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-30 10:44

Message:
Logged In: YES 
user_id=29957

Using the HP testdrive system
HP-UX spe169 B.11.11 U 9000/800 1939057856 unlimited-user
license

I did the following with 2.3.2c1:
>>> import ftplib
>>> f = ftplib.FTP()
>>> f.connect('localhost', 21)
'220 spe169.testdrive.hp.com FTP server (Version
1.1.214.4(PHNE_27765) Wed Sep  4 05:59:34 GMT 2002) ready.'
>>> 

Ah. In your example, you have 'hostname'. Is that
_literally_ what you typed? If so, it's looking for a
machine called 'hostname'. I tried that, and got the same
error you got. 

Try it without the single quotes around 'hostname'. 


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:50

Message:
Logged In: YES 
user_id=29957

Hm. I'm obviously having reading difficulties. There's
obviously something else going on entirely. Damn. I will try
to grab some time on one of the HP test boxes to see if I
can figure what's going on...


----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:49

Message:
Logged In: YES 
user_id=29957

Did the workaround fix the problem? I'm not sure why it'd
work for 2.3 and not 2.3.1, unless 2.3.1's script was
generated with a newer version of autoconf - aha. Yes, it was. 
If you could check if the fix in 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=811160&group_id=5470
"makes it all better", that would be great. Put aclocal.m4
alongside configure &c, re-run autoconf, then ./configure ; make


----------------------------------------------------------------------

Comment By: Richard Townsend (rptownsend)
Date: 2003-09-26 18:21

Message:
Logged In: YES 
user_id=200117

I had already applied the workaround to my 2.3.1 build.

I don't think configure was broken with Python 2.3 - and it 
was with 2.3 that I first noticed the problem.



----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2003-09-26 18:04

Message:
Logged In: YES 
user_id=29957

Hm. I wonder if this is related to the configure broken-ness.
Can you apply the workaround from
http://www.python.org/2.3.1/bugs.html and see if the problem
is fixed?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=812376&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 12:00:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 12:13:14 2004
Subject: [ python-Bugs-909230 ] bug in idna-encoding-module
Message-ID: <E1B6BkN-0003lN-00@sc8-sf-web1.sourceforge.net>

Bugs item #909230, was opened at 2004-03-03 19:13
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Rumpeltux (rumpeltux)
Assigned to: Martin v. L?wis (loewis)
Summary: bug in idna-encoding-module

Initial Comment:
in /usr/lib/python2.3/encodings/idna.py, line 175 it goes:
lables = input.split(&#039;.&#039;)
which causes the interpreter to stop executing the
program, but by changing it to
labels = dots.split(input)
everything&#039;s fine ;)

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-24 18:00

Message:
Logged In: YES 
user_id=21627

Found it. PyUnicode_FromEncodedObject converts the string object to 
char*/len, then calls PyUnicode_Decode. This special-cases UTF-8, Latin
-1 and ASCII, then creates a buffer object and passes it to 
PyCodec_Decode.

Even if it might be possible to pass the string directly to the codec, the 
codec still has to deal with buffer objects, for direct callers of 
PyUnicode_Decode. So I leave the fix as-is, added a test-case 
(test_codecs.py 1.10), and close this as fixed.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-24 17:40

Message:
Logged In: YES 
user_id=21627

This is now fixed in idna.py 1.4 and 1.2.12.2, by converting input to a 
string object. I leave this open to find out why there is a buffer object in 
the first place.

----------------------------------------------------------------------

Comment By: Rumpeltux (rumpeltux)
Date: 2004-03-23 17:17

Message:
Logged In: YES 
user_id=989758

>>> unicode('xn--mller-kva.de', 'idna')
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/lib/python2.3/encodings/idna.py", line 175, in
decode
    labels = input.split(".")
AttributeError: 'buffer' object has no attribute 'split'


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-22 23:26

Message:
Logged In: YES 
user_id=21627

I can't see any problem in the code. The invocation of unicode() is 
correct - we just look for the exception that call may raise.

Rumpeltux, can you please report the exact input and exception you get?

----------------------------------------------------------------------

Comment By: Neal Norwitz (nnorwitz)
Date: 2004-03-05 20:52

Message:
Logged In: YES 
user_id=33168

Martin, it looks like line 174: unicode(input, "ascii")
should be input = unicode(input, "ascii").
I'm not sure what's supposed to happenning here, but it
looks like the if/else code block may be able to be
rewritten as:

if not isinstance(input, unicode):
    input = unicode(input, "ascii")
labels = dots.split(input)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=909230&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 14:35:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 14:35:06 2004
Subject: [ python-Feature Requests-531145 ] socket.sslerror is not a
	socket.error
Message-ID: <E1B6E9V-0004IF-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #531145, was opened at 2002-03-18 00:14
Message generated for change (Comment added) made by calvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=531145&group_id=5470

Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 3
Submitted By: Wummel (calvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket.sslerror is not a socket.error

Initial Comment:
Python 2.1.2 (#1, Mar 16 2002, 00:56:55) 
[GCC 2.95.4 20011002 (Debian prerelease)] on linux2
Type "copyright", "credits" or "license" for more
information.
>>> import socket
>>> socket.sslerror
<class socket.sslerror at 0x809c39c>
>>> try: raise socket.sslerror
... except socket.error: pass
... 
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
socket.sslerror
>>> 


----------------------------------------------------------------------

>Comment By: Wummel (calvin)
Date: 2004-03-24 20:35

Message:
Logged In: YES 
user_id=9205

Hei, thanks for patching this! It seems a new Python release
is nearby when such minor loose ends get tidied up :)

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-24 00:30

Message:
Logged In: YES 
user_id=357491

socket.sslerror is now a subclass of socket.error thanks to extending the 
socket module's C API.  Done in:

Misc/NEWS 1.960
Modules/socketmodule.h 1.12
Modules/socketmodule.c 1.286
Modules_ssl.c 1.16

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-17 03:42

Message:
Logged In: YES 
user_id=357491

Well, I have no issue with wanting to make socket.sslerror a subclass of 
socket.error, but socket.sslerror is not even documented so I don't see this 
as an issue until socket.sslerror is documented.

So this will need a doc patch on top of any patch to make the  change to 
socket.sslerror.

----------------------------------------------------------------------

Comment By: Michael Stone (mbrierst)
Date: 2003-02-04 17:19

Message:
Logged In: YES 
user_id=670441

If this behavior is desired, the patch below implements it.  If it's not desired, this bug sould be closed.

It isn't much work at all.  test_socket and test_socket_ssl still pass fine.  The following case will work after this patch, all other combinations will work as before:

>>> try: raise socket.sslerror
... except socket.error: print 'caught'
caught
>>>

patch (I cannot attach the file in sourceforge for some reason):
Index: dist/src/Modules/socketmodule.h
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.h,v
retrieving revision 1.8
diff -c -r1.8 socketmodule.h
*** dist/src/Modules/socketmodule.h	13 Jun 2002 15:07:44 -0000	1.8
--- dist/src/Modules/socketmodule.h	4 Feb 2003 16:05:27 -0000
***************
*** 140,145 ****
--- 140,146 ----
  /* C API for usage by other Python modules */
  typedef struct {
  	PyTypeObject *Sock_Type;
+         PyObject *Sock_Error;
  } PySocketModule_APIObject;
  
  /* XXX The net effect of the following appears to be to define a function
Index: dist/src/Modules/socketmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/socketmodule.c,v
retrieving revision 1.251
diff -c -r1.251 socketmodule.c
*** dist/src/Modules/socketmodule.c	6 Jan 2003 12:41:26 -0000	1.251
--- dist/src/Modules/socketmodule.c	4 Feb 2003 16:05:43 -0000
***************
*** 3117,3122 ****
--- 3117,3123 ----
  PySocketModule_APIObject PySocketModuleAPI =
  {
  	&sock_type,
+         NULL,
  };
  
  
***************
*** 3178,3183 ****
--- 3179,3185 ----
  		return;
  
  	/* Export C API */
+         PySocketModuleAPI.Sock_Error = socket_error;
  	if (PyModule_AddObject(m, PySocket_CAPI_NAME,
  	       PyCObject_FromVoidPtr((void *)&PySocketModuleAPI, NULL)
  				 ) != 0)
Index: dist/src/Modules/_ssl.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/_ssl.c,v
retrieving revision 1.9
diff -c -r1.9 _ssl.c
*** dist/src/Modules/_ssl.c	27 Jan 2003 22:19:21 -0000	1.9
--- dist/src/Modules/_ssl.c	4 Feb 2003 16:05:45 -0000
***************
*** 543,549 ****
  	SSLeay_add_ssl_algorithms();
  
  	/* Add symbols to module dict */
! 	PySSLErrorObject = PyErr_NewException("socket.sslerror", NULL, NULL);
  	if (PySSLErrorObject == NULL)
  		return;
  	PyDict_SetItemString(d, "sslerror", PySSLErrorObject);
--- 543,549 ----
  	SSLeay_add_ssl_algorithms();
  
  	/* Add symbols to module dict */
! 	PySSLErrorObject = PyErr_NewException("socket.sslerror", PySocketModule.Sock_Error, NULL);
  	if (PySSLErrorObject == NULL)
  		return;
  	PyDict_SetItemString(d, "sslerror", PySSLErrorObject);


----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2002-11-11 18:12

Message:
Logged In: YES 
user_id=9205

Yes, I want socket.sslerror to be a subclass of
socket.error. It simplifies code layout (see my previous
answer) and it follows the documentation.
And yes, its work, but only a little :)

----------------------------------------------------------------------

Comment By: Gerhard H?ring (ghaering)
Date: 2002-10-05 02:05

Message:
Logged In: YES 
user_id=163326

So do you propose to make socket.sslerror a subclass of
socket.error. Is this desirable? I'm not sure. Is it work? Yes.

----------------------------------------------------------------------

Comment By: Wummel (calvin)
Date: 2002-03-18 21:23

Message:
Logged In: YES 
user_id=9205

The documentation says for socket.error: "This exception is
raised for socket- or address-related errors." I think
socket.sslerror is such an error, because then you can write

try: sock.write("") # could be ssl-socket
except socket.error: pass

The other way would be
_exceptions = [socket.error]
if hasattr(socket, "sslerror"):
    _exceptions.append(socket.sslerror)
try: sock.write("")
except _exceptions: pass

Anyway, I assume this is a minor "bug".

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-03-18 11:44

Message:
Logged In: YES 
user_id=21627

Why is this a bug?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=531145&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 15:23:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 15:23:43 2004
Subject: [ python-Bugs-922690 ] package manager page outdated link
Message-ID: <E1B6EuY-0000kN-00@sc8-sf-web2.sourceforge.net>

Bugs item #922690, was opened at 2004-03-24 12:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: package manager page outdated link

Initial Comment:
The page http://www.python.org/packman/ has outdated links to Bob Ippolito&#039;s page. The correct link appears to be http://undefined.org/python/ (which includes links to various versions of the packages and to descriptions of the same).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 16:51:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 16:51:34 2004
Subject: [ python-Bugs-902075 ] urllib2 should be more robust for sloppy
	proxy URLs
Message-ID: <E1B6GHY-0000EF-00@sc8-sf-web1.sourceforge.net>

Bugs item #902075, was opened at 2004-02-22 04:05
Message generated for change (Comment added) made by lordsutch
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib2 should be more robust for sloppy proxy URLs

Initial Comment:
passing an URL like "foo.bar.baz" instead of
"http://foo.bar.baz" results in a stacktrace:

  File "/usr/lib/python2.3/urllib2.py", line 326, in open
    &#039;_open&#039;, req)
  File "/usr/lib/python2.3/urllib2.py", line 306, in
_call_chain
    result = func(*args)
  File "/usr/lib/python2.3/urllib2.py", line 491, in
<lambda>
    lambda r, proxy=url, type=type, meth=self.proxy_open:   File "/usr/lib/python2.3/urllib2.py", line 498, in
proxy_open
    if &#039;@&#039; in host:
TypeError: iterable argument required

This could be fixed by calling urlparse.urlparse on the
proxy url, either in the calling code or in the library
code, which I would prefer to make it more robust about
sloppy URLs passed in the http_proxy environment variable.


----------------------------------------------------------------------

Comment By: Chris Lawrence (lordsutch)
Date: 2004-03-24 15:51

Message:
Logged In: YES 
user_id=6757

I've put together a patch, which can be found at
http://bugs.debian.org/233305; it isn't perfect (ideally the
entire routine should be rewritten, as it's processing
environment data that could be from the "wild"), but it
avoids the traceback.

----------------------------------------------------------------------

Comment By: Matthias Klose (doko)
Date: 2004-02-22 04:19

Message:
Logged In: YES 
user_id=60903

Ok, I see, PEP42 ...


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=902075&group_id=5470

From noreply at sourceforge.net  Wed Mar 24 21:49:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 24 21:49:35 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1B6Kvt-0002qx-00@sc8-sf-web2.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 18:00
Message generated for change (Comment added) made by pje
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Phillip J. Eby (pje)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


----------------------------------------------------------------------

>Comment By: Phillip J. Eby (pje)
Date: 2004-03-25 02:49

Message:
Logged In: YES 
user_id=56214

Committed and backported.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 22:54

Message:
Logged In: YES 
user_id=6380

Phillip, now that you have CVS perms, please check this in
yourself (and backport).

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-03-06 12:35

Message:
Logged In: YES 
user_id=56214

Here's a patch against the CVS head to add a test for the
problem, and fix it.  Please backport to the 2.3 branch as
well.  Thanks!

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-25 19:09

Message:
Logged In: YES 
user_id=6656

I don't think you'll find any difference between the trunk
and release23-maint in this area, so it doesn't make much
difference.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 19:06

Message:
Logged In: YES 
user_id=56214

super().descriptor example:

class Base(object):
    aProp = property(lambda self: "foo")

class Sub(Base):
    def test(klass):
        print super(Sub,klass).aProp
    test = classmethod(test)

Sub.test()

This prints "foo", when it should print "<property object at
0x4024f84c>" instead.

To be precise, the issue is that accessing any descriptor
that behaves differently when retrieved on the class vs. the
instance, will behave incorrectly when accessed via super()
from a classmethod in a subclass.  Classmethods themselves
work correctly because they behave the same way no matter
how you retrieve them.

At present I think the patch should simply change the
descr_get call in super_getattro so that it checks whether
su->obj==su->obj_type, and if so, pass in NULL instead of
su->obj as the second argument to descr_get.

Should I create this patch against the 2.3 maintenance
branch, or against the head?  I'd like to make sure it gets
into the next 2.3.x bugfix release.  (I didn't realize this
bug was still open until I stumbled across it the other day,
and I'm not expecting to upgrade to 2.3 production use for a
few months yet.  I've been using a pure-Python
reimplementation of super() as a workaround.)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 15:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 07:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 00:15:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 00:16:01 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B6NDB-00016g-00@sc8-sf-web3.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2004-03-25 05:15

Message:
Logged In: YES 
user_id=72053

I'm not sure why the larger state space of mt/sha1 is
supposed to be an advantage, but the other points are
reasonable.  I like the new sha1/sha1 implementation except
for a few minor points (below).  I made the old version
hopefully threadsafe by adding a threading.Lock() object to
the instance and locking it on update. I generally like your
version better so maybe the lock can be added.  Of course
that slows it down even further, but in the context of an
interpreted Python program I feel that the generator is
still fast enough compared to the other stuff the program is
likely to be doing.

Re the new attachment, some minor issues:

1) The number 2.0**-160 is < 10**-50.  This is a valid IEEE
double but on some non-IEEE machines it may be a floating
underflow or even equal to zero.  I don't know if this matters.

2) Paranoia led me to hash the seed twice in the seed
operation in my version, to defeat unlikely
message-extension attacks against the hash function.  I
figured reseeding is infrequent enough that an extra hash
operation doesn't matter.

3) Storing s1 as a string of 40 hex digits in SHARandom2
means that s1+s2 is 60 characters, which means hashing it
will need two sha1 compression operations, slowing it down some.

4) the intiialization of ciphertxt to ["0x0"] instead of []
doesn't seem to do anything useful.  int('123abc', 16) is
valid without the 0x prefix.

5) random() uses hex(cnt) while getrandbits uses str(cnt)
(converting to decimal instead of hex).  I think it's better
to use hex and remove the 0x prefix from the output, which
is cleanest, and simpler to implement on some targets
(embedded microcontroller).  The same goes for the %s
conversion in jumpahead (my version also uses %s there).

6) It may be worthwhile to include cnt in both the s0 and s1
hash updates.  That guarantees the s1 hash never gets the
same input twice.

7) The variable "s1" in getrandbits (instead of self.s1) is
set but never used.

Note in my version of sharandom.py, I didn't put a thread
lock around the tuple assignment in setstate().  I'm not
sure if that's safe or not.  But it looks to me like
random.py in the CVS does the same thing, so maybe both are
unsafe.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-24 11:31

Message:
Logged In: YES 
user_id=80475

I attached a new version of the mt/sha1 combination.

Here are the relative merits as compared sha1/sha1 approach:
* simpiler to implement/maintain since state tracking is builtin
* larger state space (2**19937 vs 2**160)
* faster
* threadsafe

Favoring sha1/sha1:
* uses only one primitive
* easier to replace in situations where MT is not available


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-22 00:56

Message:
Logged In: YES 
user_id=72053

Two small corrections to below: 1) "in favor of an entropy"
is an editing error--the intended meaning should be obvious.
 2) I meant Bryan Mongeau, not Eric Mongeau.  Bryan's lib is
at <http://eevolved.com/cryptkit/>.  Sorry for any confusion.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-22 00:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 19:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 19:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 17:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 08:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 06:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 11:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 00:55:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 00:55:06 2004
Subject: [ python-Bugs-922914 ] Installer misplaces tcl library
Message-ID: <E1B6NpW-0002y2-00@sc8-sf-web3.sourceforge.net>

Bugs item #922914, was opened at 2004-03-25 13:55
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: WS Wong (wswong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer misplaces tcl library

Initial Comment:
Python 2.3.3 on Windows 2000 Professional
-------------------------------------------
Could not start IDLE after installation of Python in 
C:\WSPrograms\Python23

Went to C:\WSPrograms\Python23\Lib\idlelib and from 
the command line typed
C:\WSPrograms\Python23\python idle.py

The following traceback obtained:

C:\WSPrograms\Python23
\Lib\idlelib>c:\wsprograms\python23\python idle.py
Traceback (most recent call last):
  File "idle.py", line 23, in ?
    idlelib.PyShell.main()
  File "C:\WSPrograms\Python23\lib\idlelib\PyShell.py", 
line 1269, in main
    root = Tk(className="Idle")
  File "C:\WSPrograms\Python23\lib\lib-tk\Tkinter.py", 
line 1564, in __init__
    self.tk = _tkinter.create(screenName, baseName, 
className)
_tkinter.TclError: Can&#039;t find a usable init.tcl in the 
following directories:
    {C:\WSPrograms\ruby167ms\tcl\lib\tcl8.3} 
{C:\WSPrograms\ruby167ms\tcl\lib\tc
l8.3} C:/WSPrograms/ruby167ms/tcl/lib/tcl8.4 
c:/wsprograms/python23/lib/tcl8.4 c
:/wsprograms/lib/tcl8.4 c:/lib/tcl8.4 
c:/wsprograms/library c:/library c:/../tcl
8.4.3/library

Looking at the directories that was installed, 
I found that the tcl8.4 was actually located in
C:\WSPrograms\Python23\tcl\tk8.4
which was never on the search path.

After I copied the tcl8.4 directory to  
C:\WSPrograms\Python23\Lib
and run the commands again, it worked. Not sure what 
other implications this will cause 
but at least I have IDLE running again. 


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 01:06:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 01:06:27 2004
Subject: [ python-Bugs-922922 ] tempfile.mkstemp() documentation discrepancy
Message-ID: <E1B6O0V-0004wT-00@sc8-sf-web1.sourceforge.net>

Bugs item #922922, was opened at 2004-03-25 06:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922922&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael S. Fischer (otterley)
Assigned to: Nobody/Anonymous (nobody)
Summary: tempfile.mkstemp() documentation discrepancy

Initial Comment:
The documentation for tempfile.mkstemp() at 
http://www.python.org/doc/2.3.3/lib/module-
tempfile.html (as well as the ActivePython 
documentation that ships with the Windows 2.3 build) 
says:

"mkstemp() returns a tuple containing an OS-level 
handle to an open file (as would be returned by os.open
()) and the absolute pathname of that file, in that order."

However, whenever I use it, it returns a tuple containing 
an integer (presumably the file descriptor) and the 
absolute pathname of the tempfile.  No file handle is 
returned.  

Sure enough, the in-line documentation states:

"The return value is a pair (fd, name) where fd is the file 
descriptor returned by os.open, and name is the 
filename."

Could someone please correct this discrepancy?


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922922&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 03:18:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 03:18:05 2004
Subject: [ python-Bugs-922964 ] file built-in object is after file() function
Message-ID: <E1B6Q3u-0002rC-00@sc8-sf-web3.sourceforge.net>

Bugs item #922964, was opened at 2004-03-25 09:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922964&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: file built-in object is after file() function

Initial Comment:
In section 2.1 of the HTML and PDF-A4 library 
references (so supposedly in all lib references), in the 
description of the file() function, it says that "Return a 
new file object (described earlier under Built-in Types)", 
but the Built-in Types section is later not earlier.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922964&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 03:25:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 03:26:03 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B6QBT-0003uI-00@sc8-sf-web2.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 03:25

Message:
Logged In: YES 
user_id=80475

1.  We don't care about non IEEE.

2.  One-way is one-way, so double hashing is unnecessary. 
Also, I've fielded bug reports from existing user apps that
re-seed very frequently (multiple times per second).

3.  The implementations reflect the results of timing
experiments which showed that the fastest intermediate
representation was hex.

4.  ['0x0'] is necessary to hanlde the case where n==0. 
int('', 16) raises a ValueError while int('0x0', 16) does not.

5.  random() and getrandbits() do not have to go through the
same intermediate steps (it's okay for one to use hex and
the other to use str) -- speed and space issues dominate. 
0x comes up enough in Python, there is little use in tossing
it away for an obscure, hypothetical micro-controller
implementation.

6.  Leaving cnt out of the s1 computation guarantees that it
will never track the updates of s0 -- any syncronization
would be a disaster.  Adding a count or some variant smacks
of desperation rather than reliance on proven hash properties.

7.  The function is already 100 times slower than MT. 
Adding locks will make the situation worse.  It is better to
simply document it as being non-threadsafe.  

Look at back at the mt/sha version.  Its code is much
cleaner, faster, and threadsafe.  It goes a long way towards
meeting your 
request and serving as an alternate generator to validate
simulation results.

If we use the sha/sha version, I'm certain that we will be
fielding bug reports on this through 2010.  It is also
sufficiently complex that it will spawn lengthy, wasteful
discussions and it will create a mine-field for future
maintainers. 


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-25 00:15

Message:
Logged In: YES 
user_id=72053

I'm not sure why the larger state space of mt/sha1 is
supposed to be an advantage, but the other points are
reasonable.  I like the new sha1/sha1 implementation except
for a few minor points (below).  I made the old version
hopefully threadsafe by adding a threading.Lock() object to
the instance and locking it on update. I generally like your
version better so maybe the lock can be added.  Of course
that slows it down even further, but in the context of an
interpreted Python program I feel that the generator is
still fast enough compared to the other stuff the program is
likely to be doing.

Re the new attachment, some minor issues:

1) The number 2.0**-160 is < 10**-50.  This is a valid IEEE
double but on some non-IEEE machines it may be a floating
underflow or even equal to zero.  I don't know if this matters.

2) Paranoia led me to hash the seed twice in the seed
operation in my version, to defeat unlikely
message-extension attacks against the hash function.  I
figured reseeding is infrequent enough that an extra hash
operation doesn't matter.

3) Storing s1 as a string of 40 hex digits in SHARandom2
means that s1+s2 is 60 characters, which means hashing it
will need two sha1 compression operations, slowing it down some.

4) the intiialization of ciphertxt to ["0x0"] instead of []
doesn't seem to do anything useful.  int('123abc', 16) is
valid without the 0x prefix.

5) random() uses hex(cnt) while getrandbits uses str(cnt)
(converting to decimal instead of hex).  I think it's better
to use hex and remove the 0x prefix from the output, which
is cleanest, and simpler to implement on some targets
(embedded microcontroller).  The same goes for the %s
conversion in jumpahead (my version also uses %s there).

6) It may be worthwhile to include cnt in both the s0 and s1
hash updates.  That guarantees the s1 hash never gets the
same input twice.

7) The variable "s1" in getrandbits (instead of self.s1) is
set but never used.

Note in my version of sharandom.py, I didn't put a thread
lock around the tuple assignment in setstate().  I'm not
sure if that's safe or not.  But it looks to me like
random.py in the CVS does the same thing, so maybe both are
unsafe.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-24 06:31

Message:
Logged In: YES 
user_id=80475

I attached a new version of the mt/sha1 combination.

Here are the relative merits as compared sha1/sha1 approach:
* simpiler to implement/maintain since state tracking is builtin
* larger state space (2**19937 vs 2**160)
* faster
* threadsafe

Favoring sha1/sha1:
* uses only one primitive
* easier to replace in situations where MT is not available


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-21 19:56

Message:
Logged In: YES 
user_id=72053

Two small corrections to below: 1) "in favor of an entropy"
is an editing error--the intended meaning should be obvious.
 2) I meant Bryan Mongeau, not Eric Mongeau.  Bryan's lib is
at <http://eevolved.com/cryptkit/>.  Sorry for any confusion.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-21 19:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 14:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 14:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 12:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 03:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 01:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 06:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 04:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 03:28:36 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 03:28:41 2004
Subject: [ python-Bugs-922964 ] file built-in object is after file() function
Message-ID: <E1B6QE8-00045I-00@sc8-sf-web2.sourceforge.net>

Bugs item #922964, was opened at 2004-03-25 03:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922964&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: file built-in object is after file() function

Initial Comment:
In section 2.1 of the HTML and PDF-A4 library 
references (so supposedly in all lib references), in the 
description of the file() function, it says that "Return a 
new file object (described earlier under Built-in Types)", 
but the Built-in Types section is later not earlier.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 03:28

Message:
Logged In: YES 
user_id=80475

Forward references are only problematic in the tutorial. 
The rest of the docs tend to be used in a random access
fashion rather than sequentially.  That's a good thing
because forward references are everywhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922964&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 04:08:45 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 04:09:16 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B6Qqz-0004hF-00@sc8-sf-web4.sourceforge.net>

Bugs item #917055, was opened at 2004-03-15 21:46
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 04:08

Message:
Logged In: YES 
user_id=80475

Took another look at #5 and will change str() to hex().

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 03:25

Message:
Logged In: YES 
user_id=80475

1.  We don't care about non IEEE.

2.  One-way is one-way, so double hashing is unnecessary. 
Also, I've fielded bug reports from existing user apps that
re-seed very frequently (multiple times per second).

3.  The implementations reflect the results of timing
experiments which showed that the fastest intermediate
representation was hex.

4.  ['0x0'] is necessary to hanlde the case where n==0. 
int('', 16) raises a ValueError while int('0x0', 16) does not.

5.  random() and getrandbits() do not have to go through the
same intermediate steps (it's okay for one to use hex and
the other to use str) -- speed and space issues dominate. 
0x comes up enough in Python, there is little use in tossing
it away for an obscure, hypothetical micro-controller
implementation.

6.  Leaving cnt out of the s1 computation guarantees that it
will never track the updates of s0 -- any syncronization
would be a disaster.  Adding a count or some variant smacks
of desperation rather than reliance on proven hash properties.

7.  The function is already 100 times slower than MT. 
Adding locks will make the situation worse.  It is better to
simply document it as being non-threadsafe.  

Look at back at the mt/sha version.  Its code is much
cleaner, faster, and threadsafe.  It goes a long way towards
meeting your 
request and serving as an alternate generator to validate
simulation results.

If we use the sha/sha version, I'm certain that we will be
fielding bug reports on this through 2010.  It is also
sufficiently complex that it will spawn lengthy, wasteful
discussions and it will create a mine-field for future
maintainers. 


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-25 00:15

Message:
Logged In: YES 
user_id=72053

I'm not sure why the larger state space of mt/sha1 is
supposed to be an advantage, but the other points are
reasonable.  I like the new sha1/sha1 implementation except
for a few minor points (below).  I made the old version
hopefully threadsafe by adding a threading.Lock() object to
the instance and locking it on update. I generally like your
version better so maybe the lock can be added.  Of course
that slows it down even further, but in the context of an
interpreted Python program I feel that the generator is
still fast enough compared to the other stuff the program is
likely to be doing.

Re the new attachment, some minor issues:

1) The number 2.0**-160 is < 10**-50.  This is a valid IEEE
double but on some non-IEEE machines it may be a floating
underflow or even equal to zero.  I don't know if this matters.

2) Paranoia led me to hash the seed twice in the seed
operation in my version, to defeat unlikely
message-extension attacks against the hash function.  I
figured reseeding is infrequent enough that an extra hash
operation doesn't matter.

3) Storing s1 as a string of 40 hex digits in SHARandom2
means that s1+s2 is 60 characters, which means hashing it
will need two sha1 compression operations, slowing it down some.

4) the intiialization of ciphertxt to ["0x0"] instead of []
doesn't seem to do anything useful.  int('123abc', 16) is
valid without the 0x prefix.

5) random() uses hex(cnt) while getrandbits uses str(cnt)
(converting to decimal instead of hex).  I think it's better
to use hex and remove the 0x prefix from the output, which
is cleanest, and simpler to implement on some targets
(embedded microcontroller).  The same goes for the %s
conversion in jumpahead (my version also uses %s there).

6) It may be worthwhile to include cnt in both the s0 and s1
hash updates.  That guarantees the s1 hash never gets the
same input twice.

7) The variable "s1" in getrandbits (instead of self.s1) is
set but never used.

Note in my version of sharandom.py, I didn't put a thread
lock around the tuple assignment in setstate().  I'm not
sure if that's safe or not.  But it looks to me like
random.py in the CVS does the same thing, so maybe both are
unsafe.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-24 06:31

Message:
Logged In: YES 
user_id=80475

I attached a new version of the mt/sha1 combination.

Here are the relative merits as compared sha1/sha1 approach:
* simpiler to implement/maintain since state tracking is builtin
* larger state space (2**19937 vs 2**160)
* faster
* threadsafe

Favoring sha1/sha1:
* uses only one primitive
* easier to replace in situations where MT is not available


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-21 19:56

Message:
Logged In: YES 
user_id=72053

Two small corrections to below: 1) "in favor of an entropy"
is an editing error--the intended meaning should be obvious.
 2) I meant Bryan Mongeau, not Eric Mongeau.  Bryan's lib is
at <http://eevolved.com/cryptkit/>.  Sorry for any confusion.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-21 19:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 14:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 14:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 12:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 03:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 01:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 06:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 04:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 06:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 10:47:21 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 10:47:27 2004
Subject: [ python-Bugs-639311 ] urllib.basejoin() mishandles ''
Message-ID: <E1B6X4j-0005Fh-00@sc8-sf-web3.sourceforge.net>

Bugs item #639311, was opened at 2002-11-16 04:34
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
>Assigned to: Brett Cannon (bcannon)
Summary: urllib.basejoin() mishandles ''

Initial Comment:
It&#039;s not entirely clear whether urllib.basejoin() intends to 
implement RFC 2396&#039;s "resolution of relative URI 
references to absolute form" faithfully, but it seems to 
behave improperly when given an empty string as the 
relative URI to make absolute.

>>> from urllib import basejoin
>>> basejoin(&#039;http://host/foo/bar.xml&#039;,&#039;&#039;)
&#039;http://host/foo/&#039;

I believe it should return the base as-is, because the 
empty string is a reference to the document that 
contains that reference... and presumably the 
document&#039;s URI is what you&#039;re passing in as the base.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-25 07:47

Message:
Logged In: YES 
user_id=357491

There is a misunderstanding about what I meant by "documented".  I 
meant it is not a specific part of the public API since it is not documented 
at http://www.python.org/dev/doc/devel/lib/module-urllib.html which is 
the official docs for urllib.  Having a docstring does not mean the code is 
considered part of the public API.  Sorry I didn't clarify that.

Now you obviously know a lot about this Mike, so can you give me your 
opinion on whether replacing urllib.basejoin with urlparse.urljoin is a 
reasonable move?

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-23 15:15

Message:
Logged In: YES 
user_id=371366

Well, it is documented as "Utility to combine a URL with a 
base URL to form a new URL".

The notion of 'base URL' is described in the RFCs mentioned in 
urllib.__doc__ (all of which predate RFC 2396, I notice, 
though it doesn't matter) and is exclusively applicable to 
relative URL/URI reference resolution, a process in which an 
empty path denotes a same-document reference / no 
traversal from the origin. So I don't think it was unreasonable 
of me to have an expectation that basejoin() would be at 
least somewhat conformant to the specs that its parent 
module purports to implement.

And it actually *is* conformant when the relative URL 
consists of just a query or fragment; the empty path doesn't 
result in the tail of the base URL being chopped off before the 
query or fragment is added/replaced. So this lends further 
credence to the notion that the intent was to be conformant.

Furthermore, in the one and only place where it is used in 
core python libs at all (in urllib.FancyURLOpener), basejoin() 
is used in a way that would give a wrong result, if left as-is: 
to derive an absolute URL so a redirect can be followed, when 
given a relative URL in the Location header of an HTTP 302 
response. Granted, the odds of this header being empty are 
slim, but still. It's a bug in FancyURLOpener.redirect_internal, 
at least.

Nevertheless, I am now of the opinion that anyone serious 
about conformant URL handling will avoid urllib. In 4Suite I 
have implemented wrappers and replacements for the 
functions we need. See also bug #649962.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 13:37

Message:
Logged In: YES 
user_id=357491

I disagree with what you are expecting.  For instance, if you run 
``urllib.basejoin("http://python.org/index.html", "/doc")`` it returns 
"http://python.org/dev", which makes sense.  So changing its behavior 
based on it being an empty string would not strictly match how the 
function works when compared to being given any string.

And on top of things the function is not even documented, so you really 
shouldn't be expecting any specific behavior.

Closing this as invalid.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-21 20:14

Message:
Logged In: YES 
user_id=357491

Perhaps urllib.basejoin (which is not documented) should just become a 
wrapper for urlparse.urljoin ?  It won't solve this bug but it would cut back 
on unneeded code.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2002-11-26 02:41

Message:
Logged In: YES 
user_id=371366

I was partly mistaken; the document's URI is not necessarily 
the base. A reference with an empty path (e.g., an empty 
string or just a fragment identifier) is a reference to the current 
document, regardless of the base URI you are resolving 
against. A base URI is only for resolving relative URIs that are 
not referencing the current document. See some discussion 
at http://lists.w3.org/Archives/Public/uri/2002Jan/0015.html

So neither urllib.basejoin() nor urlparse.urljoin() fully 
implement the RFC 2396 "resolution to absolute form", since 
there would need to be a way to indicate "current document" 
other than returning the base.

Nevertheless, basejoin()'s behavior differs from urlparse.urljoin
()'s when presented with the empty string, and it's not clear 
whether that is intentional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 11:36:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 11:37:00 2004
Subject: [ python-Bugs-832251 ] Wrong reference for specific minidom methods
Message-ID: <E1B6Xqg-0007vI-00@sc8-sf-web1.sourceforge.net>

Bugs item #832251, was opened at 2003-10-29 04:39
Message generated for change (Settings changed) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 7
Submitted By: Francesco Ricciardi (nerby)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Wrong reference for specific minidom methods

Initial Comment:
In the HTML documentation the method in section 
13.7.1  "DOM Objects" of the library reference are listed 
as HTMLParser method.
In the "paper" documentation (PDF-A4 and Ps-A4) the 
same methods have no module reference.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 12:04:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 12:04:41 2004
Subject: [ python-Bugs-725265 ] urlopen object's read() doesn't read to EOF
Message-ID: <E1B6YHD-0002Ul-00@sc8-sf-web1.sourceforge.net>

Bugs item #725265, was opened at 2003-04-21 16:49
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470

Category: Documentation
Group: Python 2.2.2
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urlopen object's read() doesn't read to EOF

Initial Comment:
On http://python.org/doc/current/lib/module-urllib.html it says that 
the object returned by urlopen supports the read()method and that 
this and other methods "have the same interface as for file objects 
-- see section 2.2.8".  In that section on page 
http://python.org/doc/current/lib/bltin-file-objects.html it says about 
the read() method that "if the size argument is negative or omitted, 
[read should] read all data until EOF is reached."

I was a bit surprised when a project that students of mine were 
working on were failing when they tried to process the data 
obtained by the read() method on a connection made to a web 
page.  The problem, apparently, is that the read may not obtain all 
of the data requested in the first request and the total response 
has to be built up someting like follows:

import urllib
c=urllib.urlopen("http://www.blakeschool.org")
data = &#039;&#039;
while 1:
	packet=c.read()
	if packet == &#039;&#039;: break
	data+=packet
	
I&#039;m not sure if this is a feature or a bug.  Could a file&#039;s read method 
fail to obtain the whole file in one read(), too?  It seems that either 
the documentation should be changed or the read() method for at 
least urllib objects should be changed.

/c

Christopher P. Smith
The Blake School
Minneapolis, MN


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-25 12:04

Message:
Logged In: YES 
user_id=3066

This is an issue with reading from a socket; there's no way
to recognize the end of the stream until the remote end of
the socket actually closes the socket.

I've documented this limitation in Doc/lib/liburllib.tex
1.52.  Someone should backport the patch to Python 2.3.x and
close this report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 12:41:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 12:41:39 2004
Subject: [ python-Bugs-880951 ] "ez" format code for ParseTuple()
Message-ID: <E1B6YrG-0000uh-00@sc8-sf-web4.sourceforge.net>

Bugs item #880951, was opened at 2004-01-21 00:03
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=880951&group_id=5470

Category: Unicode
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: Jon Willeke (willeke)
Assigned to: M.-A. Lemburg (lemburg)
Summary: "ez" format code for ParseTuple()

Initial Comment:
I&#039;m using Python 2.3.3 on SuSE Linux 8.2.

It would be nice to have an "ez" format code that is to
"es" as "z" is to "s".  Whereas the "s" and "z" codes
depend on the default encoding, "es" lets you specify
the encoding, which is useful for interfacing with GTK+
and GNOME libraries, which have largely standardized on
UTF-8.

I think it is possible to simulate the desired behavior
with "O&", but it would be simpler with "ez".

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-03-25 18:41

Message:
Logged In: YES 
user_id=38388

Can you elaborate on the use case ? I'm asking because I don't
find the 'z' code particulary useful myself because there
are more
elegant ways to deal with optional arguments.

----------------------------------------------------------------------

Comment By: Jon Willeke (willeke)
Date: 2004-01-22 00:29

Message:
Logged In: YES 
user_id=185468

I'm attaching a patch that adds support for the "ez" and
"ez#" format codes.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=880951&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 11:51:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 13:02:47 2004
Subject: [ python-Bugs-832251 ] Wrong reference for specific minidom methods
Message-ID: <E1B6Y4k-0007V3-00@sc8-sf-web2.sourceforge.net>

Bugs item #832251, was opened at 2003-10-29 04:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470

Category: Documentation
>Group: Python 2.3
Status: Open
>Resolution: Fixed
>Priority: 6
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Wrong reference for specific minidom methods

Initial Comment:
In the HTML documentation the method in section 
13.7.1  "DOM Objects" of the library reference are listed 
as HTMLParser method.
In the "paper" documentation (PDF-A4 and Ps-A4) the 
same methods have no module reference.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-25 11:51

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/xmldomminidom.tex revision 1.9.
Someone should backport this to Python 2.3.x and close this
bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 13:06:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 13:06:55 2004
Subject: [ python-Bugs-923315 ] AIX POLLNVAL definition causes problems
Message-ID: <E1B6ZFj-0002D5-00@sc8-sf-web3.sourceforge.net>

Bugs item #923315, was opened at 2004-03-25 13:06
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923315&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: John Marshall (john_marshall)
Assigned to: Nobody/Anonymous (nobody)
Summary: AIX POLLNVAL definition causes problems

Initial Comment:
Under AIX (5.1 at least), POLLNVAL (from sys/poll.h) 
is 0x8000. This causes a problem because it is stored 
in a (signed) short (e.g., revents): 
 
----- 
struct  pollfd 
{ 
  int    fd;      /* file descriptor or file ptr */ 
  short  events;  /* requested events */ 
  short  revents; /* returned events */ 
}; 
----- 
 
As such, the following tests and results are given: 
----- 
ashort (%hx)   = 8000, ashort (%x)   = ffff8000 
POLLNVAL (%hx) = 8000, POLLNVAL (%x) = 8000 
 
ashort == POLLNVAL        => 0 
ashort == (short)POLLNVAL => 1 
----- 
 
Note that the &#039;ashort == POLLNVAL&#039; test is 0 rather 
than 1 because (I believe) POLLNVAL is treated as a 
signed integer, the ashort value is then promoted to 
signed integer thus giving 0xffff8000, not 0x8000. 
 
The problem arises because IBM has chosen to use a 
negative short value (0x8000) in a signed short 
variable. Neither Linux or IRIX have this problem 
because they use POLLNVAL=0x20 which promotes to 
0x20. 
 
This situation will cause the test_poll to fail and 
will certainly be a gotcha for AIX users. 
 
I have added the following code to the selectmodule.c 
to address the problem (mask out the upper 32 bits): 
 
-----~ line 513:selectmodule.c 
num = PyInt_FromLong(self->ufds[i].revents & 0xffff); 
----- 
 
John 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923315&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 14:26:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 14:26:46 2004
Subject: [ python-Bugs-873005 ] platform module needs update
Message-ID: <E1B6aUy-0008Gm-00@sc8-sf-web1.sourceforge.net>

Bugs item #873005, was opened at 2004-01-08 12:28
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=873005&group_id=5470

Category: Python Library
Group: None
>Status: Closed
>Resolution: Accepted
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: M.-A. Lemburg (lemburg)
Summary: platform module needs update

Initial Comment:
The platform module doesn&#039;t know about windows XP.

It would be possible to simplify it (and get rid of the
win32all dependency) by using the _winreg module, and
the sys.getwindowsversion() function - although the
1.5.2 compatibility would suffer.

Documentation is missing completely.

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-03-25 20:26

Message:
Logged In: YES 
user_id=38388

Checked in.
Thanks, Thomas.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-01-08 20:10

Message:
Logged In: YES 
user_id=11105

To be honest, I have no use for this module.
But, to get you started, I attached a simple patch which at
least detects Windows Me, XP, and 2003 Server family.

The maj and min version numbers were taken from:
http://msdn.microsoft.com/library/en-us/sysinfo/base/osversioninfo_str.asp

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-01-08 12:41

Message:
Logged In: YES 
user_id=38388

Patches are welcome :-)

I'd like to keep the 1.5.2 compatibility for 2.4. By the
time 2.5 gets developed, we can then move on to Python 2.1.

It should be possible to write the win32 code in a way that
only gets rid off the win32all dependency if the _winreg
module is available. I think  that would be a good compromise.

As for documentation: this is already written (see patch
#785752).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=873005&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 14:32:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 14:32:33 2004
Subject: [ python-Feature Requests-617979 ] need easy way of decoding a
	literal
Message-ID: <E1B6aaX-0006cX-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #617979, was opened at 2002-10-03 11:00
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Hudson (mwh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: need easy way of decoding a literal

Initial Comment:
Especially since PEP 263, we badly need a way of
turning a Python string literal into the appropriate
object.

The immediate need is to get the compiler package
working again, but I&#039;m sure there are other places it
could be used.

I thought Martin already had a patch somewhere doing
this, but I can&#039;t find it.  Maybe he remembers?

----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-03-25 20:32

Message:
Logged In: YES 
user_id=38388

Has there been any progress on this or can I close it ?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-16 14:28

Message:
Logged In: YES 
user_id=6656

For a bunch of reasons, I now care less about this so I'm
going to reduce the priority.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-10-04 13:15

Message:
Logged In: YES 
user_id=38388

MWH: My first paragraph was refering to Martin's suggestion
to use eval() for mapping literal strings to objects.

Please take this to the python-dev mailing list.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-10-04 11:00

Message:
Logged In: YES 
user_id=6656

MAL: I don't understand your first paragraph at all.

The {sys.,}source_encoding variable might work, but it would
be a dreadful hack for my purposes.  Using eval() is already
a nasty hack, IMHO.

I agree a mailing list is a more civilised interface than a
web browser...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 21:21

Message:
Logged In: YES 
user_id=21627

That would not be correct. If you have a (plain) string
literal, it would end up encoded as UTF-8, whereas the
original source encoding was, say, Latin-1. People will be
confused if string literals don't come out in the expected
encoding in interactive mode.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-10-03 20:11

Message:
Logged In: YES 
user_id=38388

I believe the correct way to handle this would be to have
eval() accept Unicode and then convert it to UTF-8 for
the parser to process. The PEP only talks about compile()
which should accept Unicode objects, but eval() is certainly
a candidate too.

About the source_encoding idea: wouldn't it be better to
define this for interactive use in the sys module ? A Python
startup script could then be used to set this variable in
interactive mode.

BTW, it's better to discuss these things on python-dev than
in these small textareas... IMHO, at least.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 19:55

Message:
Logged In: YES 
user_id=21627

I see.

For a different reason (interactive mode), I have been
contemplating to recognize a variable source_encoding in
globals(), which would be set in interactive mode to the
terminal's encoding, so that input of non-ASCII Unicode
literals would "work", without having to type an encoding
declaration each time.

I believe such a mechanism could also solve this problem;
callers of eval would have to set the global.

What do you think?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-10-03 18:45

Message:
Logged In: YES 
user_id=6656

How do you get eval to take notice of the declared encoding?

What I want is the functionality of compile.c:parsestr
available from Python.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 18:35

Message:
Logged In: YES 
user_id=21627

Not sure what you are asking. eval() would certainly be an
easy way, no?
In any case, I'm not aware of an alternative.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 14:35:52 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 14:35:59 2004
Subject: [ python-Feature Requests-617979 ] need easy way of decoding a
	literal
Message-ID: <E1B6ads-0002Ns-00@sc8-sf-web3.sourceforge.net>

Feature Requests item #617979, was opened at 2002-10-03 11:00
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Hudson (mwh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: need easy way of decoding a literal

Initial Comment:
Especially since PEP 263, we badly need a way of
turning a Python string literal into the appropriate
object.

The immediate need is to get the compiler package
working again, but I&#039;m sure there are other places it
could be used.

I thought Martin already had a patch somewhere doing
this, but I can&#039;t find it.  Maybe he remembers?

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-25 20:35

Message:
Logged In: YES 
user_id=21627

It still needs to be implemented.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-03-25 20:32

Message:
Logged In: YES 
user_id=38388

Has there been any progress on this or can I close it ?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-16 14:28

Message:
Logged In: YES 
user_id=6656

For a bunch of reasons, I now care less about this so I'm
going to reduce the priority.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-10-04 13:15

Message:
Logged In: YES 
user_id=38388

MWH: My first paragraph was refering to Martin's suggestion
to use eval() for mapping literal strings to objects.

Please take this to the python-dev mailing list.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-10-04 11:00

Message:
Logged In: YES 
user_id=6656

MAL: I don't understand your first paragraph at all.

The {sys.,}source_encoding variable might work, but it would
be a dreadful hack for my purposes.  Using eval() is already
a nasty hack, IMHO.

I agree a mailing list is a more civilised interface than a
web browser...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 21:21

Message:
Logged In: YES 
user_id=21627

That would not be correct. If you have a (plain) string
literal, it would end up encoded as UTF-8, whereas the
original source encoding was, say, Latin-1. People will be
confused if string literals don't come out in the expected
encoding in interactive mode.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-10-03 20:11

Message:
Logged In: YES 
user_id=38388

I believe the correct way to handle this would be to have
eval() accept Unicode and then convert it to UTF-8 for
the parser to process. The PEP only talks about compile()
which should accept Unicode objects, but eval() is certainly
a candidate too.

About the source_encoding idea: wouldn't it be better to
define this for interactive use in the sys module ? A Python
startup script could then be used to set this variable in
interactive mode.

BTW, it's better to discuss these things on python-dev than
in these small textareas... IMHO, at least.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 19:55

Message:
Logged In: YES 
user_id=21627

I see.

For a different reason (interactive mode), I have been
contemplating to recognize a variable source_encoding in
globals(), which would be set in interactive mode to the
terminal's encoding, so that input of non-ASCII Unicode
literals would "work", without having to type an encoding
declaration each time.

I believe such a mechanism could also solve this problem;
callers of eval would have to set the global.

What do you think?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-10-03 18:45

Message:
Logged In: YES 
user_id=6656

How do you get eval to take notice of the declared encoding?

What I want is the functionality of compile.c:parsestr
available from Python.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 18:35

Message:
Logged In: YES 
user_id=21627

Not sure what you are asking. eval() would certainly be an
easy way, no?
In any case, I'm not aware of an alternative.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 15:06:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 15:06:43 2004
Subject: [ python-Bugs-876278 ] Unbounded recursion in modulefinder
Message-ID: <E1B6b7X-0003lr-00@sc8-sf-web1.sourceforge.net>

Bugs item #876278, was opened at 2004-01-13 19:46
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Just van Rossum (jvr)
Summary: Unbounded recursion in modulefinder

Initial Comment:
modulefinder goes into unbounded recursion when a
module named &#039;path.py&#039;, containing &#039;import os&#039;, is on
sys.path.

Last part of the traceback:
  File "c:\python23\lib\modulefinder.py", line 255, in
import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "c:\python23\lib\modulefinder.py", line 285, in
load_module
    self.scan_code(co, m)
  File "c:\python23\lib\modulefinder.py", line 342, in
scan_code
    self._safe_import_hook(name, m, fromlist)
  File "c:\python23\lib\modulefinder.py", line 300, in
_safe_import_hook
    self.import_hook(name, caller)
  File "c:\python23\lib\modulefinder.py", line 124, in
import_hook
    q, tail = self.find_head_package(parent, name)
  File "c:\python23\lib\modulefinder.py", line 166, in
find_head_package
    q = self.import_module(head, qname, parent)
  File "c:\python23\lib\modulefinder.py", line 237, in
import_module
    self.msgin(3, "import_module", partname, fqname,
parent)
RuntimeError: maximum recursion depth exceeded

Running modulefinder with the &#039;-x os.path&#039; command line
option prevents the recursion.

This is not really a contrived situation, there&#039;s a
possibly useful path.py module from Jason Orendorff at
<http://www.jorendorff.com/articles/python/path>


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-03-25 21:06

Message:
Logged In: YES 
user_id=11105

<ping> Just, do you have time to look into this?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-01-28 21:36

Message:
Logged In: YES 
user_id=11105

Just, do you have time to look into this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 15:53:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 15:53:50 2004
Subject: [ python-Bugs-876278 ] Unbounded recursion in modulefinder
Message-ID: <E1B6bqk-000199-00@sc8-sf-web3.sourceforge.net>

Bugs item #876278, was opened at 2004-01-13 19:46
Message generated for change (Comment added) made by jvr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Just van Rossum (jvr)
Summary: Unbounded recursion in modulefinder

Initial Comment:
modulefinder goes into unbounded recursion when a
module named &#039;path.py&#039;, containing &#039;import os&#039;, is on
sys.path.

Last part of the traceback:
  File "c:\python23\lib\modulefinder.py", line 255, in
import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "c:\python23\lib\modulefinder.py", line 285, in
load_module
    self.scan_code(co, m)
  File "c:\python23\lib\modulefinder.py", line 342, in
scan_code
    self._safe_import_hook(name, m, fromlist)
  File "c:\python23\lib\modulefinder.py", line 300, in
_safe_import_hook
    self.import_hook(name, caller)
  File "c:\python23\lib\modulefinder.py", line 124, in
import_hook
    q, tail = self.find_head_package(parent, name)
  File "c:\python23\lib\modulefinder.py", line 166, in
find_head_package
    q = self.import_module(head, qname, parent)
  File "c:\python23\lib\modulefinder.py", line 237, in
import_module
    self.msgin(3, "import_module", partname, fqname,
parent)
RuntimeError: maximum recursion depth exceeded

Running modulefinder with the &#039;-x os.path&#039; command line
option prevents the recursion.

This is not really a contrived situation, there&#039;s a
possibly useful path.py module from Jason Orendorff at
<http://www.jorendorff.com/articles/python/path>


----------------------------------------------------------------------

>Comment By: Just van Rossum (jvr)
Date: 2004-03-25 21:53

Message:
Logged In: YES 
user_id=92689

Hm, not really. Do you have any idea what's causing it?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-03-25 21:06

Message:
Logged In: YES 
user_id=11105

<ping> Just, do you have time to look into this?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-01-28 21:36

Message:
Logged In: YES 
user_id=11105

Just, do you have time to look into this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 16:09:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 16:09:36 2004
Subject: [ python-Bugs-876278 ] Unbounded recursion in modulefinder
Message-ID: <E1B6c6G-0001FA-00@sc8-sf-web1.sourceforge.net>

Bugs item #876278, was opened at 2004-01-13 19:46
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Just van Rossum (jvr)
Summary: Unbounded recursion in modulefinder

Initial Comment:
modulefinder goes into unbounded recursion when a
module named &#039;path.py&#039;, containing &#039;import os&#039;, is on
sys.path.

Last part of the traceback:
  File "c:\python23\lib\modulefinder.py", line 255, in
import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "c:\python23\lib\modulefinder.py", line 285, in
load_module
    self.scan_code(co, m)
  File "c:\python23\lib\modulefinder.py", line 342, in
scan_code
    self._safe_import_hook(name, m, fromlist)
  File "c:\python23\lib\modulefinder.py", line 300, in
_safe_import_hook
    self.import_hook(name, caller)
  File "c:\python23\lib\modulefinder.py", line 124, in
import_hook
    q, tail = self.find_head_package(parent, name)
  File "c:\python23\lib\modulefinder.py", line 166, in
find_head_package
    q = self.import_module(head, qname, parent)
  File "c:\python23\lib\modulefinder.py", line 237, in
import_module
    self.msgin(3, "import_module", partname, fqname,
parent)
RuntimeError: maximum recursion depth exceeded

Running modulefinder with the &#039;-x os.path&#039; command line
option prevents the recursion.

This is not really a contrived situation, there&#039;s a
possibly useful path.py module from Jason Orendorff at
<http://www.jorendorff.com/articles/python/path>


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-03-25 22:09

Message:
Logged In: YES 
user_id=11105

It has something to do with os.path.  Adding 'os.path' to
the excludes list, the problem does not appear.

Adding print statements it seems that mf is looking for 
os.os.os.os.os.......something, it seems that it recurses
without noting that something failed.

If I had to fix this myself, I probably had to first step
through these imports with the C debugger, and then through mf.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2004-03-25 21:53

Message:
Logged In: YES 
user_id=92689

Hm, not really. Do you have any idea what's causing it?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-03-25 21:06

Message:
Logged In: YES 
user_id=11105

<ping> Just, do you have time to look into this?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-01-28 21:36

Message:
Logged In: YES 
user_id=11105

Just, do you have time to look into this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 16:58:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 16:59:21 2004
Subject: [ python-Feature Requests-540952 ] Memory Usage Reporting
Message-ID: <E1B6csI-00035e-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #540952, was opened at 2002-04-08 08:01
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Allan Crooks (amc1)
Assigned to: Nobody/Anonymous (nobody)
Summary: Memory Usage Reporting

Initial Comment:
I would personally like a way in Python to report how 
many bytes of memory that the interpreter is using 
(perhaps through the sys module)?

If this sort of mechanism is added, then it may allow 
SoftReferences (a la Java) to be introduced, which 
would definitely be useful for memory sensitive 
caches...

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-25 16:58

Message:
Logged In: YES 
user_id=764593


For many uses, an exact count isn't required; it is enough to 
know that memory has grown by approximately X over some 
baseline.

_PyObject_DebugMallocStats has most of the desired 
information.  (Except that it is usually #ifdef ed out entirely, 
instead of being exposed as a python function.)

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2004-03-22 13:31

Message:
Logged In: NO 

What is the minimum worth including?

For instance, objmalloc.c states that it never returns an arena 
to the operating system, so just (narenas * ARENA_SIZE) is an 
upper bound on python-managed generic small object memory. 
Whether that is enough of the used memory (or a tight enough 
bound, in case of good VM), I can't yet judge.

When I have wanted it, it was to ask either "Do I have to 
shrink my cache yet?" or "Is this getting slow because I've 
taken too much memory for the system it is running on".  Both 
probably require more a accurate version.  (Walking the 
individual arenas and pools?)



----------------------------------------------------------------------

Comment By: Jean M. Brouwers (jbrouwers)
Date: 2003-07-28 19:57

Message:
Logged In: YES 
user_id=832557

It would be useful to get some figure(s) about the memory
usage of the current process.

For example, just the 'high water mark' returned by sbrk(0)
on uni* is very helpful in many cases.

I tried the resource.getrusage(resource.RUSAGE_SELF)
function but that does return all zero's in slice [2:6] on
my uni* system.  Not sure whether that is an artifact of the
O/S or Python.

----------------------------------------------------------------------

Comment By: Anthony Baxter (anthonybaxter)
Date: 2002-04-10 10:03

Message:
Logged In: YES 
user_id=29957

You _can_ do this for most O/Ss, true. The problem is that
it's something that's extremely operating system specific,
and, worse yet, varies significantly between operating 
system releases. Have a look at the source for the system
utility 'top' one day - most of it is in the 'operating 
system specific' section, and there's all sorts of horrible
horrible hoops you have to jump through for different releases.

In addition, the notion of "how much memory is being used"
isn't always that clear in the case of things like shared
libraries.

On the plus side, implementing this would move the HP/UX
threading problem to #2 on the list of "most annoying 
operating-system dependent bugs".

----------------------------------------------------------------------

Comment By: Allan Crooks (amc1)
Date: 2002-04-09 10:45

Message:
Logged In: YES 
user_id=39733

Thanks for the response.

Rather than having an internal way of figuring out how much 
memory is used, is there no external way that we can get 
the OS to return how big the process is?

I know that it is less than elegant, and would have to have 
different platform-dependent code to do this, but it is 
still an idea. I know that Jython can quiz the VM to see 
how much memory is being used, and I'll assume that you can 
do that with different OS's as well...

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-04-08 12:38

Message:
Logged In: YES 
user_id=31435

Allan, this isn't easy, so the cost/benefit ratio is high.  
For the most part, Python gets memory from the system 
malloc, and doesn't even try to keep track of it now; nor 
has it any idea how much overhead (padding, control bytes) 
the system malloc adds; nor is there a portable interface 
to C's malloc for finding out such things.

Still, I agree it would be nice to have such things <wink>.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=540952&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 17:17:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 17:20:44 2004
Subject: [ python-Bugs-796042 ] sdist ignores scripts argument in setup
Message-ID: <E1B6dA5-0007PT-00@sc8-sf-web1.sourceforge.net>

Bugs item #796042, was opened at 2003-08-27 11:09
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796042&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
>Resolution: Fixed
Priority: 5
Submitted By: Anna Ravenscroft (annarave)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sdist ignores scripts argument in setup

Initial Comment:
When writing the setup script for a distribution, section 3.4 explains:

3.4 Installing Scripts

So far we have been dealing with pure and non-pure Python modules, which are usually not run by themselves but imported by scripts.

Scripts are files containing Python source code, intended to be started from the command line. Scripts don&#039;t require Distutils to do anything very complicated. The only clever feature is that if the first line of the script starts with #! and contains the word ``python&#039;&#039;, the Distutils will adjust the first line to refer to the current interpreter location. 

The scripts option simply is a list of files to be handled in this way. From the PyXML setup script: 


setup (...
       scripts = [&#039;scripts/xmlproc_parse&#039;, &#039;scripts/xmlproc_val&#039;]
      )

Unfortunately, this doesn&#039;t work with sdist unless you ALSO create a manifest.in file. Otherwise, it silently ignores the scripts listed in setup. bdist works just fine, so it&#039;s apparently something wrong in sdist.

Please fix this. Thank you.

Anna Ravenscroft

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-25 17:17

Message:
Logged In: YES 
user_id=3066

This is fixed on the trunk as
Lib/distutils/command/build_scripts.py 1.22 and sdist.py 1.57.

I'm not entirely sure this should be backported for Python
2.3.x, but it probably should be.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796042&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 19:36:40 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 19:37:43 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B6fKy-0001We-00@sc8-sf-web4.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2004-03-26 00:36

Message:
Logged In: YES 
user_id=72053

1. OK, though the docs should mention this.

2. One-way just means collision resistant, and we're trying
to make something without a distinguisher, which is a
stronger criterion.  I'm not saying there's any problem with
a single hash; I just don't see an obvious proof that
there's not a problem.  Also it makes me cringe slightly to
keep the seed around as plaintext even temporarily.  The PC
that I'm using (midrange Athlon) can do about a million sha1
hashes per second, so an extra hash per reseed "multiple"
times per second shouldn't be noticible, for reasonable
values of "multiple".

3. Since most of the real computation of this function is in
the sha1 compression, the timing indicates that evaluation
is dominated by interpreter overhead rather than by hashing.
 I presume you're using CPython.  The results may be
different in Jython or with Psyco and different again under
PyPy once that becomes real.  I think we should take the
view that we're designing a mathematical function that
exists independently of any specific implementation, then
figure out what characteristics it should have and implement
those, rather than tailoring it to the peculiarities of
CPython.  

If people are really going to be using this function in
2010, CPython will hopefully be dead and gone (replaced by
PyPy) by then, so that's all the more reason to not worry
about small CPython-specific effects since the function will
outlast CPython.  Maybe also sometime between now and then,
these libraries can be compiled with psyco.

4. OK

5. OK.  Would be good to also change %s for cnt in setstate
to %x.

6. Synchronization can be avoided by hashing different fixed
strings into s0 and s1 at each rehash (I did that in my
version).  I think it's worth doing that just to kick the
hash function away from standard sha.  I actually don't see
much need for the counter in either hash, but you were
concerned about hitting possible short cycles in sha.

7. OK.  WHrandom is already non-threadsafe, so there's
precedent.   I do have to wonder if the 160 bit arithmetic
is slowing things down.  If we don't care about non-IEEE
doubles, we're ok with 53 bits.   Hmm, I also wonder whether
the 160 bit int to float conversion is precisely specified
even for IEEE and isn't an artifact of Python's long int
implementation.  But I guess it doesn't matter, since we're
never hashing those floats.

Re bugs til 2010: oh let's have more confidence than that
:).  I think if we're careful and get the details correct
before deployment, we shouldn't have any problems.  This is
just one screenful of code or so, not complex by most
reasonable standards.  However, we might want post the
algorithm on sci.crypt for comments, since there's some
knowledgeable people there.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 09:08

Message:
Logged In: YES 
user_id=80475

Took another look at #5 and will change str() to hex().

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 08:25

Message:
Logged In: YES 
user_id=80475

1.  We don't care about non IEEE.

2.  One-way is one-way, so double hashing is unnecessary. 
Also, I've fielded bug reports from existing user apps that
re-seed very frequently (multiple times per second).

3.  The implementations reflect the results of timing
experiments which showed that the fastest intermediate
representation was hex.

4.  ['0x0'] is necessary to hanlde the case where n==0. 
int('', 16) raises a ValueError while int('0x0', 16) does not.

5.  random() and getrandbits() do not have to go through the
same intermediate steps (it's okay for one to use hex and
the other to use str) -- speed and space issues dominate. 
0x comes up enough in Python, there is little use in tossing
it away for an obscure, hypothetical micro-controller
implementation.

6.  Leaving cnt out of the s1 computation guarantees that it
will never track the updates of s0 -- any syncronization
would be a disaster.  Adding a count or some variant smacks
of desperation rather than reliance on proven hash properties.

7.  The function is already 100 times slower than MT. 
Adding locks will make the situation worse.  It is better to
simply document it as being non-threadsafe.  

Look at back at the mt/sha version.  Its code is much
cleaner, faster, and threadsafe.  It goes a long way towards
meeting your 
request and serving as an alternate generator to validate
simulation results.

If we use the sha/sha version, I'm certain that we will be
fielding bug reports on this through 2010.  It is also
sufficiently complex that it will spawn lengthy, wasteful
discussions and it will create a mine-field for future
maintainers. 


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-25 05:15

Message:
Logged In: YES 
user_id=72053

I'm not sure why the larger state space of mt/sha1 is
supposed to be an advantage, but the other points are
reasonable.  I like the new sha1/sha1 implementation except
for a few minor points (below).  I made the old version
hopefully threadsafe by adding a threading.Lock() object to
the instance and locking it on update. I generally like your
version better so maybe the lock can be added.  Of course
that slows it down even further, but in the context of an
interpreted Python program I feel that the generator is
still fast enough compared to the other stuff the program is
likely to be doing.

Re the new attachment, some minor issues:

1) The number 2.0**-160 is < 10**-50.  This is a valid IEEE
double but on some non-IEEE machines it may be a floating
underflow or even equal to zero.  I don't know if this matters.

2) Paranoia led me to hash the seed twice in the seed
operation in my version, to defeat unlikely
message-extension attacks against the hash function.  I
figured reseeding is infrequent enough that an extra hash
operation doesn't matter.

3) Storing s1 as a string of 40 hex digits in SHARandom2
means that s1+s2 is 60 characters, which means hashing it
will need two sha1 compression operations, slowing it down some.

4) the intiialization of ciphertxt to ["0x0"] instead of []
doesn't seem to do anything useful.  int('123abc', 16) is
valid without the 0x prefix.

5) random() uses hex(cnt) while getrandbits uses str(cnt)
(converting to decimal instead of hex).  I think it's better
to use hex and remove the 0x prefix from the output, which
is cleanest, and simpler to implement on some targets
(embedded microcontroller).  The same goes for the %s
conversion in jumpahead (my version also uses %s there).

6) It may be worthwhile to include cnt in both the s0 and s1
hash updates.  That guarantees the s1 hash never gets the
same input twice.

7) The variable "s1" in getrandbits (instead of self.s1) is
set but never used.

Note in my version of sharandom.py, I didn't put a thread
lock around the tuple assignment in setstate().  I'm not
sure if that's safe or not.  But it looks to me like
random.py in the CVS does the same thing, so maybe both are
unsafe.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-24 11:31

Message:
Logged In: YES 
user_id=80475

I attached a new version of the mt/sha1 combination.

Here are the relative merits as compared sha1/sha1 approach:
* simpiler to implement/maintain since state tracking is builtin
* larger state space (2**19937 vs 2**160)
* faster
* threadsafe

Favoring sha1/sha1:
* uses only one primitive
* easier to replace in situations where MT is not available


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-22 00:56

Message:
Logged In: YES 
user_id=72053

Two small corrections to below: 1) "in favor of an entropy"
is an editing error--the intended meaning should be obvious.
 2) I meant Bryan Mongeau, not Eric Mongeau.  Bryan's lib is
at <http://eevolved.com/cryptkit/>.  Sorry for any confusion.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-22 00:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 19:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 19:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 17:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 08:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 06:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 11:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Thu Mar 25 19:43:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Thu Mar 25 19:44:05 2004
Subject: [ python-Bugs-923576 ] Incorrect __name__ assignment
Message-ID: <E1B6fRl-0006BD-00@sc8-sf-web2.sourceforge.net>

Bugs item #923576, was opened at 2004-03-26 00:43
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

Category: Parser/Compiler
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: El cepi (elcepi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect __name__ assignment

Initial Comment:
When you use PythonLauncher or PythonIDE the value of 
__name__ is incorrectly assigned.

For example, in the attached file the output is "The module 
has been load" when the module is fun in PythonIDE.

With this you can not disciminate between the code you 
should run when you load the module and when you try to 
run it.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 01:39:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 01:40:07 2004
Subject: [ python-Bugs-923697 ] SAX2 'property_encoding' feature not
	supported
Message-ID: <E1B6l0Y-0001KR-00@sc8-sf-web3.sourceforge.net>

Bugs item #923697, was opened at 2004-03-26 06:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923697&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Joseph Walton (josephw)
Assigned to: Nobody/Anonymous (nobody)
Summary: SAX2 'property_encoding' feature not supported

Initial Comment:
I need to parse a byte stream as an XML document and,
afterwards, access the same document as a Unicode
string. I would prefer to rely on the parser&#039;s
charset-determining logic, and the &#039;property_encoding&#039;
feature
("http://www.python.org/sax/properties/encoding") seems
to offer exactly this information.

However, the default Expat parser doesn&#039;t support this
feature.

---
from xml.sax import make_parser, handler
from xml.sax.xmlreader import InputSource
from sys import stdin

p = make_parser()

# Should not fail. Should it return None, or UTF-8?
assert(p.getProperty(handler.property_encoding) == None)

source = InputSource()
source.setByteStream(stdin)

p.parse(source)

# Should now be the name of the actual encoding used
assert(p.getProperty(handler.property_encoding) != None)
---

This raises SAXNotRecognizedException.

Is there another SAX parser I could use instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923697&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 01:42:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 01:42:17 2004
Subject: [ python-Bugs-923697 ] SAX2 'property_encoding' feature not
	supported
Message-ID: <E1B6l2g-0001RA-00@sc8-sf-web3.sourceforge.net>

Bugs item #923697, was opened at 2004-03-26 06:39
Message generated for change (Settings changed) made by josephw
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923697&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
>Priority: 4
Submitted By: Joseph Walton (josephw)
Assigned to: Nobody/Anonymous (nobody)
Summary: SAX2 'property_encoding' feature not supported

Initial Comment:
I need to parse a byte stream as an XML document and,
afterwards, access the same document as a Unicode
string. I would prefer to rely on the parser&#039;s
charset-determining logic, and the &#039;property_encoding&#039;
feature
("http://www.python.org/sax/properties/encoding") seems
to offer exactly this information.

However, the default Expat parser doesn&#039;t support this
feature.

---
from xml.sax import make_parser, handler
from xml.sax.xmlreader import InputSource
from sys import stdin

p = make_parser()

# Should not fail. Should it return None, or UTF-8?
assert(p.getProperty(handler.property_encoding) == None)

source = InputSource()
source.setByteStream(stdin)

p.parse(source)

# Should now be the name of the actual encoding used
assert(p.getProperty(handler.property_encoding) != None)
---

This raises SAXNotRecognizedException.

Is there another SAX parser I could use instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923697&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 04:59:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 05:00:05 2004
Subject: [ python-Bugs-639311 ] urllib.basejoin() mishandles ''
Message-ID: <E1B6o83-0006PH-00@sc8-sf-web3.sourceforge.net>

Bugs item #639311, was opened at 2002-11-16 05:34
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Brett Cannon (bcannon)
Summary: urllib.basejoin() mishandles ''

Initial Comment:
It&#039;s not entirely clear whether urllib.basejoin() intends to 
implement RFC 2396&#039;s "resolution of relative URI 
references to absolute form" faithfully, but it seems to 
behave improperly when given an empty string as the 
relative URI to make absolute.

>>> from urllib import basejoin
>>> basejoin(&#039;http://host/foo/bar.xml&#039;,&#039;&#039;)
&#039;http://host/foo/&#039;

I believe it should return the base as-is, because the 
empty string is a reference to the document that 
contains that reference... and presumably the 
document&#039;s URI is what you&#039;re passing in as the base.

----------------------------------------------------------------------

>Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-26 02:59

Message:
Logged In: YES 
user_id=371366

Given that it's not part of the public API and isn't used 
anywhere other than urllib.FancyURLOpener, I think that 
should be safe.

As for whether I recommend it, well, I don't know. Cons are 
that urlparse.urljoin() is currently slower, makes the call stack 
a bit deeper, and has some minor issues related to the fact 
that the entire module was coded to implement facets of RFC 
1808, which has been obsolete since Aug 1998. RFC 1808 has 
various issues mainly relating to how it handles relative paths, 
path params, paths containing '.' or '..' segments, and the 
finer points of merging query and fragment parts. None of 
these are showstoppers, but urljoin doesn't even get 1808 
completely right, though -- it accepts relative base URLs, for 
example, which is a contradiction in terms that has never 
been allowed by the specs. (basejoin does this, too) Another 
possible con is that importing a function from urlparse into 
urllib might not be desirable. I don't know what your policy is 
on introducing dependencies between core libs.

Alternatively, what I think might be a better option is to just 
change urllib.FancyURLOpener.redirect_internal() to use 
urlparse.urljoin() instead of urllib.basejoin(). Then, you could 
just remove urllib.basejoin() altogether.

For the record, the main differences in behavior that you can 
expect to see when using urljoin instead of basejoin will be 
that it will better handle the case where the new URL in the 
redirect is an empty string or just '..'. There will also be some 
weird behavior, in some cases, with URLs that use 'file' or 
unrecognized URL schemes, but basejoin() wouldn't have 
done any better.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-25 08:47

Message:
Logged In: YES 
user_id=357491

There is a misunderstanding about what I meant by "documented".  I 
meant it is not a specific part of the public API since it is not documented 
at http://www.python.org/dev/doc/devel/lib/module-urllib.html which is 
the official docs for urllib.  Having a docstring does not mean the code is 
considered part of the public API.  Sorry I didn't clarify that.

Now you obviously know a lot about this Mike, so can you give me your 
opinion on whether replacing urllib.basejoin with urlparse.urljoin is a 
reasonable move?

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-23 16:15

Message:
Logged In: YES 
user_id=371366

Well, it is documented as "Utility to combine a URL with a 
base URL to form a new URL".

The notion of 'base URL' is described in the RFCs mentioned in 
urllib.__doc__ (all of which predate RFC 2396, I notice, 
though it doesn't matter) and is exclusively applicable to 
relative URL/URI reference resolution, a process in which an 
empty path denotes a same-document reference / no 
traversal from the origin. So I don't think it was unreasonable 
of me to have an expectation that basejoin() would be at 
least somewhat conformant to the specs that its parent 
module purports to implement.

And it actually *is* conformant when the relative URL 
consists of just a query or fragment; the empty path doesn't 
result in the tail of the base URL being chopped off before the 
query or fragment is added/replaced. So this lends further 
credence to the notion that the intent was to be conformant.

Furthermore, in the one and only place where it is used in 
core python libs at all (in urllib.FancyURLOpener), basejoin() 
is used in a way that would give a wrong result, if left as-is: 
to derive an absolute URL so a redirect can be followed, when 
given a relative URL in the Location header of an HTTP 302 
response. Granted, the odds of this header being empty are 
slim, but still. It's a bug in FancyURLOpener.redirect_internal, 
at least.

Nevertheless, I am now of the opinion that anyone serious 
about conformant URL handling will avoid urllib. In 4Suite I 
have implemented wrappers and replacements for the 
functions we need. See also bug #649962.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 14:37

Message:
Logged In: YES 
user_id=357491

I disagree with what you are expecting.  For instance, if you run 
``urllib.basejoin("http://python.org/index.html", "/doc")`` it returns 
"http://python.org/dev", which makes sense.  So changing its behavior 
based on it being an empty string would not strictly match how the 
function works when compared to being given any string.

And on top of things the function is not even documented, so you really 
shouldn't be expecting any specific behavior.

Closing this as invalid.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-21 20:14

Message:
Logged In: YES 
user_id=357491

Perhaps urllib.basejoin (which is not documented) should just become a 
wrapper for urlparse.urljoin ?  It won't solve this bug but it would cut back 
on unneeded code.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2002-11-26 03:41

Message:
Logged In: YES 
user_id=371366

I was partly mistaken; the document's URI is not necessarily 
the base. A reference with an empty path (e.g., an empty 
string or just a fragment identifier) is a reference to the current 
document, regardless of the base URI you are resolving 
against. A base URI is only for resolving relative URIs that are 
not referencing the current document. See some discussion 
at http://lists.w3.org/Archives/Public/uri/2002Jan/0015.html

So neither urllib.basejoin() nor urlparse.urljoin() fully 
implement the RFC 2396 "resolution to absolute form", since 
there would need to be a way to indicate "current document" 
other than returning the base.

Nevertheless, basejoin()'s behavior differs from urlparse.urljoin
()'s when presented with the empty string, and it's not clear 
whether that is intentional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 11:16:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 12:03:00 2004
Subject: [ python-Bugs-924008 ] make fails using -std option
Message-ID: <E1B6u0v-0006Il-00@sc8-sf-web2.sourceforge.net>

Bugs item #924008, was opened at 2004-03-26 11:16
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924008&group_id=5470

Category: Installation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Benites (benites)
Assigned to: Nobody/Anonymous (nobody)
Summary: make fails using -std option

Initial Comment:
I&#039;m running OSF1 V5.1 1885 alpha, 
Compaq C V6.4-014 on Compaq Tru64 UNIX V5.1A (Rev. 1885)
Compiler Driver V6.4-215 (sys) cc Driver
Compaq C++ V6.2-024 for Compaq Tru64 UNIX V5.1A (Rev. 1885)

I used the following configure command:

CC=cc ./configure --without-gcc --with-cxx=/usr/bin/cxx      --with-dec-threads

When I compile the first module I see the following
error messages:

/usr/bin/cxx -pthread -c -ieee -std -Olimit 1500
-DNDEBUG -O    -I. -I./Include  -DPy_BUILD_CORE -o Modules/ccpython.o    ./Modules/ccpython.cc
cxx: Severe: invalid std option:
cxx: Info: 1 catastrophic error detected in this
compilation.
cxx: Info: Compilation terminated.
make: *** [Modules/ccpython.o] Error 1

If I remove the -std option or use the -std1 option it
will compile without error. 

Any suggestions?

-- Bob Benites

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924008&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 09:05:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 12:03:18 2004
Subject: [ python-Bugs-639311 ] urllib.basejoin() mishandles ''
Message-ID: <E1B6rxu-0008Et-00@sc8-sf-web3.sourceforge.net>

Bugs item #639311, was opened at 2002-11-16 04:34
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Brett Cannon (bcannon)
Summary: urllib.basejoin() mishandles ''

Initial Comment:
It&#039;s not entirely clear whether urllib.basejoin() intends to 
implement RFC 2396&#039;s "resolution of relative URI 
references to absolute form" faithfully, but it seems to 
behave improperly when given an empty string as the 
relative URI to make absolute.

>>> from urllib import basejoin
>>> basejoin(&#039;http://host/foo/bar.xml&#039;,&#039;&#039;)
&#039;http://host/foo/&#039;

I believe it should return the base as-is, because the 
empty string is a reference to the document that 
contains that reference... and presumably the 
document&#039;s URI is what you&#039;re passing in as the base.

----------------------------------------------------------------------

>Comment By: Brett Cannon (bcannon)
Date: 2004-03-26 06:05

Message:
Logged In: YES 
user_id=357491

I actually just did ``from urlparse import urljoin as basejoin`` and 
deleted the code for basejoin.  So I have already implemented your 
suggestion in Python 2.4 .

Thanks for the help, Mike.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-26 01:59

Message:
Logged In: YES 
user_id=371366

Given that it's not part of the public API and isn't used 
anywhere other than urllib.FancyURLOpener, I think that 
should be safe.

As for whether I recommend it, well, I don't know. Cons are 
that urlparse.urljoin() is currently slower, makes the call stack 
a bit deeper, and has some minor issues related to the fact 
that the entire module was coded to implement facets of RFC 
1808, which has been obsolete since Aug 1998. RFC 1808 has 
various issues mainly relating to how it handles relative paths, 
path params, paths containing '.' or '..' segments, and the 
finer points of merging query and fragment parts. None of 
these are showstoppers, but urljoin doesn't even get 1808 
completely right, though -- it accepts relative base URLs, for 
example, which is a contradiction in terms that has never 
been allowed by the specs. (basejoin does this, too) Another 
possible con is that importing a function from urlparse into 
urllib might not be desirable. I don't know what your policy is 
on introducing dependencies between core libs.

Alternatively, what I think might be a better option is to just 
change urllib.FancyURLOpener.redirect_internal() to use 
urlparse.urljoin() instead of urllib.basejoin(). Then, you could 
just remove urllib.basejoin() altogether.

For the record, the main differences in behavior that you can 
expect to see when using urljoin instead of basejoin will be 
that it will better handle the case where the new URL in the 
redirect is an empty string or just '..'. There will also be some 
weird behavior, in some cases, with URLs that use 'file' or 
unrecognized URL schemes, but basejoin() wouldn't have 
done any better.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-25 07:47

Message:
Logged In: YES 
user_id=357491

There is a misunderstanding about what I meant by "documented".  I 
meant it is not a specific part of the public API since it is not documented 
at http://www.python.org/dev/doc/devel/lib/module-urllib.html which is 
the official docs for urllib.  Having a docstring does not mean the code is 
considered part of the public API.  Sorry I didn't clarify that.

Now you obviously know a lot about this Mike, so can you give me your 
opinion on whether replacing urllib.basejoin with urlparse.urljoin is a 
reasonable move?

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-23 15:15

Message:
Logged In: YES 
user_id=371366

Well, it is documented as "Utility to combine a URL with a 
base URL to form a new URL".

The notion of 'base URL' is described in the RFCs mentioned in 
urllib.__doc__ (all of which predate RFC 2396, I notice, 
though it doesn't matter) and is exclusively applicable to 
relative URL/URI reference resolution, a process in which an 
empty path denotes a same-document reference / no 
traversal from the origin. So I don't think it was unreasonable 
of me to have an expectation that basejoin() would be at 
least somewhat conformant to the specs that its parent 
module purports to implement.

And it actually *is* conformant when the relative URL 
consists of just a query or fragment; the empty path doesn't 
result in the tail of the base URL being chopped off before the 
query or fragment is added/replaced. So this lends further 
credence to the notion that the intent was to be conformant.

Furthermore, in the one and only place where it is used in 
core python libs at all (in urllib.FancyURLOpener), basejoin() 
is used in a way that would give a wrong result, if left as-is: 
to derive an absolute URL so a redirect can be followed, when 
given a relative URL in the Location header of an HTTP 302 
response. Granted, the odds of this header being empty are 
slim, but still. It's a bug in FancyURLOpener.redirect_internal, 
at least.

Nevertheless, I am now of the opinion that anyone serious 
about conformant URL handling will avoid urllib. In 4Suite I 
have implemented wrappers and replacements for the 
functions we need. See also bug #649962.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2004-03-23 13:37

Message:
Logged In: YES 
user_id=357491

I disagree with what you are expecting.  For instance, if you run 
``urllib.basejoin("http://python.org/index.html", "/doc")`` it returns 
"http://python.org/dev", which makes sense.  So changing its behavior 
based on it being an empty string would not strictly match how the 
function works when compared to being given any string.

And on top of things the function is not even documented, so you really 
shouldn't be expecting any specific behavior.

Closing this as invalid.

----------------------------------------------------------------------

Comment By: Brett Cannon (bcannon)
Date: 2003-05-21 20:14

Message:
Logged In: YES 
user_id=357491

Perhaps urllib.basejoin (which is not documented) should just become a 
wrapper for urlparse.urljoin ?  It won't solve this bug but it would cut back 
on unneeded code.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2002-11-26 02:41

Message:
Logged In: YES 
user_id=371366

I was partly mistaken; the document's URI is not necessarily 
the base. A reference with an empty path (e.g., an empty 
string or just a fragment identifier) is a reference to the current 
document, regardless of the base URI you are resolving 
against. A base URI is only for resolving relative URIs that are 
not referencing the current document. See some discussion 
at http://lists.w3.org/Archives/Public/uri/2002Jan/0015.html

So neither urllib.basejoin() nor urlparse.urljoin() fully 
implement the RFC 2396 "resolution to absolute form", since 
there would need to be a way to indicate "current document" 
other than returning the base.

Nevertheless, basejoin()'s behavior differs from urlparse.urljoin
()'s when presented with the empty string, and it's not clear 
whether that is intentional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=639311&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 13:47:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 14:02:50 2004
Subject: [ python-Bugs-922922 ] tempfile.mkstemp() documentation discrepancy
Message-ID: <E1B6wMO-0008IY-00@sc8-sf-web1.sourceforge.net>

Bugs item #922922, was opened at 2004-03-25 01:06
Message generated for change (Comment added) made by mondragon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922922&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael S. Fischer (otterley)
Assigned to: Nobody/Anonymous (nobody)
Summary: tempfile.mkstemp() documentation discrepancy

Initial Comment:
The documentation for tempfile.mkstemp() at 
http://www.python.org/doc/2.3.3/lib/module-
tempfile.html (as well as the ActivePython 
documentation that ships with the Windows 2.3 build) 
says:

"mkstemp() returns a tuple containing an OS-level 
handle to an open file (as would be returned by os.open
()) and the absolute pathname of that file, in that order."

However, whenever I use it, it returns a tuple containing 
an integer (presumably the file descriptor) and the 
absolute pathname of the tempfile.  No file handle is 
returned.  

Sure enough, the in-line documentation states:

"The return value is a pair (fd, name) where fd is the file 
descriptor returned by os.open, and name is the 
filename."

Could someone please correct this discrepancy?


----------------------------------------------------------------------

>Comment By: Nick Bastin (mondragon)
Date: 2004-03-26 13:47

Message:
Logged In: YES 
user_id=430343

As noted in the os.open() documentation, it returns a
file descriptor, which seems to make the mkstemp()
documentation perfectly reasonable (and correct).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922922&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 15:47:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 15:48:04 2004
Subject: [ python-Bugs-923576 ] Incorrect __name__ assignment
Message-ID: <E1B6yFB-0007cN-00@sc8-sf-web4.sourceforge.net>

Bugs item #923576, was opened at 2004-03-26 00:43
Message generated for change (Settings changed) made by elcepi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

>Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: El cepi (elcepi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect __name__ assignment

Initial Comment:
When you use PythonLauncher or PythonIDE the value of 
__name__ is incorrectly assigned.

For example, in the attached file the output is "The module 
has been load" when the module is fun in PythonIDE.

With this you can not disciminate between the code you 
should run when you load the module and when you try to 
run it.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 16:33:23 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 16:33:28 2004
Subject: [ python-Bugs-924218 ] socket._fileobject._getclosed() returns
	wrong value
Message-ID: <E1B6yx9-0003I9-00@sc8-sf-web4.sourceforge.net>

Bugs item #924218, was opened at 2004-03-26 13:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924218&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: June Kim (gigamorph)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket._fileobject._getclosed() returns wrong value

Initial Comment:
In socket.py, _getclosed() is defined as follows:

  class _fileobject(object)
      # ...
      def _getclosed(self):
          return self._sock is not None

Which causes the following interaction:
  >>> import socket
  >>> s = socket.socket()
  >>> f = s.makefile()
  >>> f.closed
  True
  >>> f.close()
  >>> f.closed
  False

Shouldn&#039;t the values of f.closed the opposite of the above?





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924218&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 17:03:11 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 17:03:16 2004
Subject: [ python-Bugs-924242 ] socket._fileobject._getclosed() returns
	wrong value
Message-ID: <E1B6zPz-0005e6-00@sc8-sf-web4.sourceforge.net>

Bugs item #924242, was opened at 2004-03-26 14:03
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: June Kim (gigamorph)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket._fileobject._getclosed() returns wrong value

Initial Comment:
In socket.py, _getclosed() is defined as follows:

  class _fileobject(object)
      # ...
      def _getclosed(self):
          return self._sock is not None

Which causes the following interaction:
  >>> import socket
  >>> s = socket.socket()
  >>> f = s.makefile()
  >>> f.closed
  True
  >>> f.close()
  >>> f.closed
  False

Shouldn&#039;t the values of f.closed the opposite of the above?





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 17:04:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 17:04:33 2004
Subject: [ python-Bugs-924242 ] socket._fileobject._getclosed() returns
	wrong value
Message-ID: <E1B6zRG-0005jl-00@sc8-sf-web4.sourceforge.net>

Bugs item #924242, was opened at 2004-03-26 14:03
Message generated for change (Settings changed) made by gigamorph
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: June Kim (gigamorph)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket._fileobject._getclosed() returns wrong value

Initial Comment:
In socket.py, _getclosed() is defined as follows:

  class _fileobject(object)
      # ...
      def _getclosed(self):
          return self._sock is not None

Which causes the following interaction:
  >>> import socket
  >>> s = socket.socket()
  >>> f = s.makefile()
  >>> f.closed
  True
  >>> f.close()
  >>> f.closed
  False

Shouldn&#039;t the values of f.closed the opposite of the above?





----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 19:07:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 19:07:49 2004
Subject: [ python-Bugs-924294 ] IPV6 not correctly ifdef'd in socketmodule.c
Message-ID: <E1B71MY-0001nx-00@sc8-sf-web3.sourceforge.net>

Bugs item #924294, was opened at 2004-03-26 19:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924294&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David Meleedy (dmeleedy)
Assigned to: Nobody/Anonymous (nobody)
Summary: IPV6 not correctly ifdef'd in socketmodule.c

Initial Comment:
buckaroo-75: diff -c3 socketmodule.c-dist socketmodule.c
*** socketmodule.c-dist Fri Mar 26 18:51:52 2004
--- socketmodule.c      Fri Mar 26 18:52:47 2004
***************
*** 2971,2977 ****
                return NULL;
        }
  
! #ifndef ENABLE_IPV6
        if(af == AF_INET6) {
                PyErr_SetString(socket_error,
                                "can&#039;t use AF_INET6,
IPv6 is disabled");
--- 2971,2977 ----
                return NULL;
        }
  
! #ifdef ENABLE_IPV6
        if(af == AF_INET6) {
                PyErr_SetString(socket_error,
                                "can&#039;t use AF_INET6,
IPv6 is disabled");


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924294&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 19:28:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 19:29:01 2004
Subject: [ python-Bugs-924301 ] A leak case with cmd.py & readline &
	exception
Message-ID: <E1B71h2-0006L8-00@sc8-sf-web4.sourceforge.net>

Bugs item #924301, was opened at 2004-03-27 01:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sverker Nilsson (svenil)
Assigned to: Nobody/Anonymous (nobody)
Summary: A leak case with cmd.py & readline & exception

Initial Comment:
A leak to do with readline & cmd, in Python 2.3.

I found out what hold on to my interactive objects
too long (&#039;for ever&#039;) in certain circumstances.  The
circumstance had to do with an exception being
raised in Cmd.cmdloop and handled (or not handled)
outside of Cmd.cmdloop.

In cmd.py, class Cmd, in cmdloop(), if an
exception is raised and propagated out from the
interior of cmdloop, the function postloop() is
not called. The default function of this, (in 2.3)
when the readline library is present, is to
restore the completer, via:

readline.set_completer(self.old_completer)

If this is not done, the newly (by preloop)
inserted completer will remain. Even if the loop
is called again and run without exception, the new
completer will remain, because then in postloop
the old completer will be set to our new
completer. When we exit, the completer will remain
the one we set. This will hold on to our object,
aka &#039;leak&#039;. - In cmd.py in 2.2 no attempt was made
to restore the completer, so this was also a kind
of leak, but it was replaced the next time a Cmd
instance was initialized.  Now, however, the next
time we will not replace the old completer, but
both of them will remain in memory. The old one
will be stored as self.old_completer.  If we
terminate with an exception, bad luck... the
stored completer retains both of the instances. If
we terminate normally, the old one will be
retained.  In no case do we restore the space of
the first instance. The only way that would
happen, would be if the second instance first
exited the loop with an exception, and then
entered the loop again an exited normally. But
then, the second instance is retained instead! If
each instance happens to terminate with an
exception, it seems well possible that an ever
increasing chain of leaking instances will be
accumulated.

My fix is to always call the postloop, given the
preloop succeeded. This is done via a try:finally
clause.

    def cmdloop(self, intro=None):
	...

        self.preloop()
	try:
		...
	finally: # Make sure postloop called
	    self.postloop()

I am attaching my patched version of cmd.py.  It
was originally from the tarball of Python 2.3.3
downloaded from Python.org some month or so ago in
which cmd.py had this size & date:

14504 Feb 19 2003 cmd.py


Best regards,

Sverker Nilsson


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 19:35:28 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 19:35:33 2004
Subject: [ python-Bugs-924301 ] A leak case with cmd.py & readline &
	exception
Message-ID: <E1B71nM-0006V4-00@sc8-sf-web2.sourceforge.net>

Bugs item #924301, was opened at 2004-03-27 01:28
Message generated for change (Settings changed) made by svenil
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sverker Nilsson (svenil)
Assigned to: Nobody/Anonymous (nobody)
>Summary: A leak case with cmd.py & readline & exception

Initial Comment:
A leak to do with readline & cmd, in Python 2.3.

I found out what hold on to my interactive objects
too long (&#039;for ever&#039;) in certain circumstances.  The
circumstance had to do with an exception being
raised in Cmd.cmdloop and handled (or not handled)
outside of Cmd.cmdloop.

In cmd.py, class Cmd, in cmdloop(), if an
exception is raised and propagated out from the
interior of cmdloop, the function postloop() is
not called. The default function of this, (in 2.3)
when the readline library is present, is to
restore the completer, via:

readline.set_completer(self.old_completer)

If this is not done, the newly (by preloop)
inserted completer will remain. Even if the loop
is called again and run without exception, the new
completer will remain, because then in postloop
the old completer will be set to our new
completer. When we exit, the completer will remain
the one we set. This will hold on to our object,
aka &#039;leak&#039;. - In cmd.py in 2.2 no attempt was made
to restore the completer, so this was also a kind
of leak, but it was replaced the next time a Cmd
instance was initialized.  Now, however, the next
time we will not replace the old completer, but
both of them will remain in memory. The old one
will be stored as self.old_completer.  If we
terminate with an exception, bad luck... the
stored completer retains both of the instances. If
we terminate normally, the old one will be
retained.  In no case do we restore the space of
the first instance. The only way that would
happen, would be if the second instance first
exited the loop with an exception, and then
entered the loop again an exited normally. But
then, the second instance is retained instead! If
each instance happens to terminate with an
exception, it seems well possible that an ever
increasing chain of leaking instances will be
accumulated.

My fix is to always call the postloop, given the
preloop succeeded. This is done via a try:finally
clause.

    def cmdloop(self, intro=None):
	...

        self.preloop()
	try:
		...
	finally: # Make sure postloop called
	    self.postloop()

I am attaching my patched version of cmd.py.  It
was originally from the tarball of Python 2.3.3
downloaded from Python.org some month or so ago in
which cmd.py had this size & date:

14504 Feb 19 2003 cmd.py


Best regards,

Sverker Nilsson


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924301&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 19:53:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 19:53:26 2004
Subject: [ python-Bugs-796219 ] ntpath.expanduser() is still wrong
Message-ID: <E1B724g-0007Rr-00@sc8-sf-web2.sourceforge.net>

Bugs item #796219, was opened at 2003-08-27 13:11
Message generated for change (Comment added) made by josiahcarlson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470

Category: Windows
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Guido van Rossum (gvanrossum)
Assigned to: Guido van Rossum (gvanrossum)
Summary: ntpath.expanduser() is still wrong

Initial Comment:
I found a system with the following setup:

- os.getenv("HOME") returns "%USERPROFILE%"
- os.getenv("USERPROFILE") returns the home directory

Currently, ntpath.py doesn&#039;t expand ~ correctly in this
case.
The fix is pretty simple, I&#039;ll try to submit it if I
have time.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2004-03-26 16:53

Message:
Logged In: YES 
user_id=341410

After doing some more playing around, I discovered a few
other examples that would kill either method described below:
HOME=%USERDRIVE%%USERPATH%
HOME=C:\%userprofiles\%USERNAME%

The real trick is that % can exist in a path on windows, so
even c:\%HOME% is a vaild path:
 Directory of D:\test

03/26/2004  03:58p      <DIR>          .
03/26/2004  03:58p      <DIR>          ..
03/26/2004  03:59p      <DIR>          %HOME%
               0 File(s)              0 bytes
               3 Dir(s)   5,355,511,808 bytes free

D:\test>

I suppose the question remains as to what cases do we want
to cover.  If we assume that there aren't any % symbols in a
path, then the code is straightforward, and I can have a
patch for you in a few minutes.  If % can be in a path, then
the problem is a pain, and a miniature parser needs to be
written to deal with it.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 14:49

Message:
Logged In: YES 
user_id=6380

Unclear what I'm asked to do here. Josiah, could you produce
an actual patch against CVS rather than random example code?

If you have forward slashes, you should use
os.path.normpath(). Why doesn't that work?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-09-30 07:00

Message:
Logged In: YES 
user_id=31435

Assigned back to Guido.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-09-29 23:33

Message:
Logged In: YES 
user_id=341410

I just noticed that I've got some forward slashes in various
paths on my windows machines...here's some updated code:

    def expandfull(var, rem=3):
        if not rem:
            return os.path.expandvars(var)
        a = os.path.expandvars(var)
        b = []
        d = [b.extend(i.split('\')) for i in a.split('/')]
        c = []
        for i in b:
            if '%' in i:
                c.append(expandfull(i), rem-1)
            else:
                c.append(i)
        return '\'.join(c)


----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-30 02:55

Message:
Logged In: YES 
user_id=539787

I stand corrected; multiple backslashes inside a path are not 
merged into one on Windows.  Thank you.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 11:48

Message:
Logged In: YES 
user_id=341410

Sourceforge ate my double-backslashes.
All '\' should be '\\'.

----------------------------------------------------------------------

Comment By: Josiah Carlson (josiahcarlson)
Date: 2003-08-29 11:20

Message:
Logged In: YES 
user_id=341410

The code you offered won't work correctly for all
environment variable returns.  An example that would kill
your code:
%SYSTEMROOT%\System32

def expandfull(var, rem=3):
    if not rem:
        return expandvars(var)
    a = expandvars(var)
    b = a.split('\')
    c = []
    for i in b:
        if '%' in i:
            c.append(expandfull(i), rem-1)
        else:
            c.append(i)
    return '\'.join(c)

The above would work properly for all environment variables.

----------------------------------------------------------------------

Comment By: Christos Georgiou (tzot)
Date: 2003-08-29 01:38

Message:
Logged In: YES 
user_id=539787

If expandvars worked for nt variable syntax too, then just 
before the expanduser final return, the following code would 
suffice, right?

max_recursion = 3
while '%' in userhome and max_recursion > 0:
    userhome = expandvars(userhome)
    max_recursion -= 1

ignoring the fact that path[1:] could contain variables too.

Shouldn't expandvars be made to work with %var% format 
too?  If yes, I'll offer code.

----------------------------------------------------------------------

Comment By: Jarek Zgoda (zgoda)
Date: 2003-08-28 00:47

Message:
Logged In: YES 
user_id=92222

This is very common setting on Windows2000 Professional.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796219&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 21:32:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 21:33:00 2004
Subject: [ python-Bugs-922922 ] tempfile.mkstemp() documentation discrepancy
Message-ID: <E1B73cY-0000J9-00@sc8-sf-web1.sourceforge.net>

Bugs item #922922, was opened at 2004-03-25 06:06
Message generated for change (Comment added) made by otterley
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922922&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Michael S. Fischer (otterley)
Assigned to: Nobody/Anonymous (nobody)
Summary: tempfile.mkstemp() documentation discrepancy

Initial Comment:
The documentation for tempfile.mkstemp() at 
http://www.python.org/doc/2.3.3/lib/module-
tempfile.html (as well as the ActivePython 
documentation that ships with the Windows 2.3 build) 
says:

"mkstemp() returns a tuple containing an OS-level 
handle to an open file (as would be returned by os.open
()) and the absolute pathname of that file, in that order."

However, whenever I use it, it returns a tuple containing 
an integer (presumably the file descriptor) and the 
absolute pathname of the tempfile.  No file handle is 
returned.  

Sure enough, the in-line documentation states:

"The return value is a pair (fd, name) where fd is the file 
descriptor returned by os.open, and name is the 
filename."

Could someone please correct this discrepancy?


----------------------------------------------------------------------

>Comment By: Michael S. Fischer (otterley)
Date: 2004-03-27 02:32

Message:
Logged In: YES 
user_id=7820

The documentation could be a bit clearer.  When I think of a 
file descriptor in python, I think of a file-like object, i.e. that 
which is returned by open(), as opposed to os.open().  

It's unclear to me why mkstemp() returns an os-level file 
descriptor as opposed to a Python file-like object, but I 
suppose that's beside the point.

I'll close the bug, though, because the documentation is 
literally correct, and the team has more urgent priorities.

----------------------------------------------------------------------

Comment By: Nick Bastin (mondragon)
Date: 2004-03-26 18:47

Message:
Logged In: YES 
user_id=430343

As noted in the os.open() documentation, it returns a
file descriptor, which seems to make the mkstemp()
documentation perfectly reasonable (and correct).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922922&group_id=5470

From noreply at sourceforge.net  Fri Mar 26 23:12:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Fri Mar 26 23:12:33 2004
Subject: [ python-Bugs-924333 ] Build issues (lib path) on linux2-x86_64
Message-ID: <E1B75BO-0005Lp-00@sc8-sf-web3.sourceforge.net>

Bugs item #924333, was opened at 2004-03-26 23:12
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Petrilli (petrilli)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build issues (lib path) on linux2-x86_64

Initial Comment:
The current CVS HEAD won&#039;t build "out of the box" on a
Fedora x86_64 box, nor on any other Linux AMD64
platform.  This is due to the fact that the libraries
for many things are not in /usr/lib, but /usr/lib64,
and the current &#039;autoconf&#039; script, as well as the
current setup.py do not look there.  When added, they
detect, build.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470

From noreply at sourceforge.net  Sat Mar 27 03:20:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 27 03:20:15 2004
Subject: [ python-Bugs-924361 ] unicodeobjct: bad argument to internal
	function
Message-ID: <E1B7933-0001gZ-00@sc8-sf-web4.sourceforge.net>

Bugs item #924361, was opened at 2004-03-27 08:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924361&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: M.-A. Lemburg (lemburg)
Summary: unicodeobjct: bad argument to internal function

Initial Comment:
[forwarded from http://bugs.debian.org/239986]

#! /usr/bin/python2.3
import unicodedata
unicodedata.normalize(&#039;NFKC&#039;, u&#039;&#039;)

I guess (but haven&#039;t looked at the source) that
something isn&#039;t cleaned up properly in this scenario. 
The bug doesn&#039;t manifest itself in the normalize() call
itself but the exception is thrown in the next
statement.  (eg running  unicodedata.normalize(&#039;NFKC&#039;,
u&#039;&#039;) ; x = 1 interactively causes the error to be
printed after the x=1 statement)

The x=1 doesn&#039;t seem to be needed, simply hitting
return shows the message.

$ python
Python 2.3.3 (#2, Feb 24 2004, 09:29:20) 
[GCC 3.3.3 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import unicodedata
>>> unicodedata.normalize(&#039;NFKC&#039;, u&#039;&#039;)
u&#039;&#039;
>>> 
SystemError: ../Objects/unicodeobject.c:278: bad
argument to internal function
>>> 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924361&group_id=5470

From noreply at sourceforge.net  Sat Mar 27 06:56:31 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 27 06:56:42 2004
Subject: [ python-Bugs-875692 ] Ctrl-C doesn't work with sleepy main thread
Message-ID: <E1B7CQR-0006eT-00@sc8-sf-web4.sourceforge.net>

Bugs item #875692, was opened at 2004-01-12 21:37
Message generated for change (Comment added) made by rhamphoryncus
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ctrl-C doesn't work with sleepy main thread

Initial Comment:
[forwarded from http://bugs.debian.org/226547]

I only have access to Debian systems ... Maybe this is
related to 846817?

I&#039;m trying to do some basic threading with Python.
However, there are times when Ctrl-C fails to cause a
KeyboardInterrupt in the main thread.

Here is a test program that illustrates the problem. As
written, I cannot interrupt it with Ctrl-C (nothing
happens even if I hold it down). If I uncomment the
print statement in the main thread, then I can
interrupt it with Ctrl-C.

It seems like adding the print in the main thread gives
the main thread a "chance to run" where it finally
notices the signal from the Ctrl-C.  However, I
shouldn&#039;t have to use hacks like this to get this to work.

People on comp.lang.python could not reproduce this on
Fedora and some others, so I&#039;m posting it here (maybe
some problem with Debian&#039;s libc6?).


----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2004-03-27 11:56

Message:
Logged In: YES 
user_id=12364

I use debian and can reproduce it.  Python package version 
2.3.3-6.  I also tried with python 2.2 and the bug was NOT 
present.  Package version 2.2.3-9. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-01-13 11:16

Message:
Logged In: YES 
user_id=6656

As the guy says in the bug report, the comp.lang.python
opinion was that this was a problem in debian!  Can someone
with a debian machine (or any other -- I can't) reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

From noreply at sourceforge.net  Sat Mar 27 11:00:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 27 11:00:55 2004
Subject: [ python-Bugs-875692 ] Ctrl-C doesn't work with sleepy main thread
Message-ID: <E1B7GEp-0000i1-00@sc8-sf-web2.sourceforge.net>

Bugs item #875692, was opened at 2004-01-12 16:37
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ctrl-C doesn't work with sleepy main thread

Initial Comment:
[forwarded from http://bugs.debian.org/226547]

I only have access to Debian systems ... Maybe this is
related to 846817?

I&#039;m trying to do some basic threading with Python.
However, there are times when Ctrl-C fails to cause a
KeyboardInterrupt in the main thread.

Here is a test program that illustrates the problem. As
written, I cannot interrupt it with Ctrl-C (nothing
happens even if I hold it down). If I uncomment the
print statement in the main thread, then I can
interrupt it with Ctrl-C.

It seems like adding the print in the main thread gives
the main thread a "chance to run" where it finally
notices the signal from the Ctrl-C.  However, I
shouldn&#039;t have to use hacks like this to get this to work.

People on comp.lang.python could not reproduce this on
Fedora and some others, so I&#039;m posting it here (maybe
some problem with Debian&#039;s libc6?).


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-27 11:00

Message:
Logged In: YES 
user_id=31435

Ctrl+C interrupts it on Win98SE -- upgrade to a real OS 
<wink>.  When odd cmdline behavior is seen on a Unixish box, 
staring at (try with and without) GNU readline is a good 
experiment.

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2004-03-27 06:56

Message:
Logged In: YES 
user_id=12364

I use debian and can reproduce it.  Python package version 
2.3.3-6.  I also tried with python 2.2 and the bug was NOT 
present.  Package version 2.2.3-9. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-01-13 06:16

Message:
Logged In: YES 
user_id=6656

As the guy says in the bug report, the comp.lang.python
opinion was that this was a problem in debian!  Can someone
with a debian machine (or any other -- I can't) reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

From noreply at sourceforge.net  Sat Mar 27 14:04:48 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 27 14:04:59 2004
Subject: [ python-Bugs-875692 ] Ctrl-C doesn't work with sleepy main thread
Message-ID: <E1B7J6u-00063A-00@sc8-sf-web1.sourceforge.net>

Bugs item #875692, was opened at 2004-01-13 06:37
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ctrl-C doesn't work with sleepy main thread

Initial Comment:
[forwarded from http://bugs.debian.org/226547]

I only have access to Debian systems ... Maybe this is
related to 846817?

I&#039;m trying to do some basic threading with Python.
However, there are times when Ctrl-C fails to cause a
KeyboardInterrupt in the main thread.

Here is a test program that illustrates the problem. As
written, I cannot interrupt it with Ctrl-C (nothing
happens even if I hold it down). If I uncomment the
print statement in the main thread, then I can
interrupt it with Ctrl-C.

It seems like adding the print in the main thread gives
the main thread a "chance to run" where it finally
notices the signal from the Ctrl-C.  However, I
shouldn&#039;t have to use hacks like this to get this to work.

People on comp.lang.python could not reproduce this on
Fedora and some others, so I&#039;m posting it here (maybe
some problem with Debian&#039;s libc6?).


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-03-28 04:04

Message:
Logged In: YES 
user_id=55188

Nah. For my some investigation, it doesn't seem to be a
problem of GNU readline.

On my debian machine, main for loop of ceval.c:eval_frame
switches threads context for every periodic loops. Because
main threads is just running time.sleep(), it goes in this way:

1) context switches to sub thread by time.sleep()
2) entering periodic if-block and resets _Py_Tick to 100.
3) because main thread has only 1 line that runs
time.sleep(), _Py_Tick is always 97~99 for main thread.
4) goto 1)

So, Py_MakePendingCalls() will never be called from main
thread. As a result, Ctrl-C doesn't work.

Hmm. I don't have a fix for right now. How about to make
per-thread _Py_Tick?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-28 01:00

Message:
Logged In: YES 
user_id=31435

Ctrl+C interrupts it on Win98SE -- upgrade to a real OS 
<wink>.  When odd cmdline behavior is seen on a Unixish box, 
staring at (try with and without) GNU readline is a good 
experiment.

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2004-03-27 20:56

Message:
Logged In: YES 
user_id=12364

I use debian and can reproduce it.  Python package version 
2.3.3-6.  I also tried with python 2.2 and the bug was NOT 
present.  Package version 2.2.3-9. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-01-13 20:16

Message:
Logged In: YES 
user_id=6656

As the guy says in the bug report, the comp.lang.python
opinion was that this was a problem in debian!  Can someone
with a debian machine (or any other -- I can't) reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

From noreply at sourceforge.net  Sat Mar 27 20:48:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 27 20:48:38 2004
Subject: [ python-Bugs-924703 ] test_unicode_file fails on Win98SE
Message-ID: <E1B7PPc-0005Hb-00@sc8-sf-web4.sourceforge.net>

Bugs item #924703, was opened at 2004-03-27 20:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: M.-A. Lemburg (lemburg)
Summary: test_unicode_file fails on Win98SE

Initial Comment:
In current CVS, test_unicode_file fails on Win98SE.  This 
has been going on for some time, actually.

ERROR: test_single_files (__main__.TestUnicodeFiles)

Traceback (most recent call last):
  File ".../lib/test/test_unicode_file.py", line 162, in 
test_single_files
    self._test_single(TESTFN_UNICODE)
  File ".../lib/test/test_unicode_file.py", line 136, in 
_test_single
    self._do_single(filename)
  File ".../lib/test/test_unicode_file.py", line 49, in 
_do_single
    new_base = unicodedata.normalize("NFD", new_base)
TypeError: normalized() argument 2 must be unicode, 
not str

At this point,

filename is TESTFN_UNICODE is
u&#039;@test-\xe0\xf2&#039;

os.path.abspath(filename) is
&#039;C:\Code\python\PC\VC6\@test-\xe0\xf2&#039;

new_base is
&#039;@test-\xe0\xf2

So abspath() removed the "Unicodeness" of filename, 
and new_base is indeed not a Unicode string at this 
point.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

From noreply at sourceforge.net  Sat Mar 27 21:05:16 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 27 21:05:19 2004
Subject: [ python-Bugs-924242 ] socket._fileobject._getclosed() returns
	wrong value
Message-ID: <E1B7Pfo-0000E8-00@sc8-sf-web2.sourceforge.net>

Bugs item #924242, was opened at 2004-03-26 17:03
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Open
Resolution: None
Priority: 5
Submitted By: June Kim (gigamorph)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket._fileobject._getclosed() returns wrong value

Initial Comment:
In socket.py, _getclosed() is defined as follows:

  class _fileobject(object)
      # ...
      def _getclosed(self):
          return self._sock is not None

Which causes the following interaction:
  >>> import socket
  >>> s = socket.socket()
  >>> f = s.makefile()
  >>> f.closed
  True
  >>> f.close()
  >>> f.closed
  False

Shouldn&#039;t the values of f.closed the opposite of the above?





----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-27 21:05

Message:
Logged In: YES 
user_id=31435

Why did you change the status from Open to Deleted?  
Changed back to Open.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

From noreply at sourceforge.net  Sat Mar 27 21:33:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sat Mar 27 21:33:08 2004
Subject: [ python-Bugs-924242 ] socket._fileobject._getclosed() returns
	wrong value
Message-ID: <E1B7Q6i-0003uo-00@sc8-sf-web3.sourceforge.net>

Bugs item #924242, was opened at 2004-03-26 17:03
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: June Kim (gigamorph)
>Assigned to: Tim Peters (tim_one)
Summary: socket._fileobject._getclosed() returns wrong value

Initial Comment:
In socket.py, _getclosed() is defined as follows:

  class _fileobject(object)
      # ...
      def _getclosed(self):
          return self._sock is not None

Which causes the following interaction:
  >>> import socket
  >>> s = socket.socket()
  >>> f = s.makefile()
  >>> f.closed
  True
  >>> f.close()
  >>> f.closed
  False

Shouldn&#039;t the values of f.closed the opposite of the above?





----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-27 21:33

Message:
Logged In: YES 
user_id=31435

I agree the .closed property always returned the wrong result.
Fixed, in

lib/socket.py; new revision: 1.43
lib/test/test_socket.py; new revision: 1.68

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-27 21:05

Message:
Logged In: YES 
user_id=31435

Why did you change the status from Open to Deleted?  
Changed back to Open.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924242&group_id=5470

From noreply at sourceforge.net  Sun Mar 28 02:10:06 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 28 02:10:36 2004
Subject: [ python-Bugs-875692 ] Ctrl-C doesn't work with sleepy main thread
Message-ID: <E1B7UQo-0001vm-00@sc8-sf-web4.sourceforge.net>

Bugs item #875692, was opened at 2004-01-13 06:37
Message generated for change (Comment added) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ctrl-C doesn't work with sleepy main thread

Initial Comment:
[forwarded from http://bugs.debian.org/226547]

I only have access to Debian systems ... Maybe this is
related to 846817?

I&#039;m trying to do some basic threading with Python.
However, there are times when Ctrl-C fails to cause a
KeyboardInterrupt in the main thread.

Here is a test program that illustrates the problem. As
written, I cannot interrupt it with Ctrl-C (nothing
happens even if I hold it down). If I uncomment the
print statement in the main thread, then I can
interrupt it with Ctrl-C.

It seems like adding the print in the main thread gives
the main thread a "chance to run" where it finally
notices the signal from the Ctrl-C.  However, I
shouldn&#039;t have to use hacks like this to get this to work.

People on comp.lang.python could not reproduce this on
Fedora and some others, so I&#039;m posting it here (maybe
some problem with Debian&#039;s libc6?).


----------------------------------------------------------------------

>Comment By: Hye-Shik Chang (perky)
Date: 2004-03-28 16:10

Message:
Logged In: YES 
user_id=55188

Here's my patch. Please review/test it. :)

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-28 04:04

Message:
Logged In: YES 
user_id=55188

Nah. For my some investigation, it doesn't seem to be a
problem of GNU readline.

On my debian machine, main for loop of ceval.c:eval_frame
switches threads context for every periodic loops. Because
main threads is just running time.sleep(), it goes in this way:

1) context switches to sub thread by time.sleep()
2) entering periodic if-block and resets _Py_Tick to 100.
3) because main thread has only 1 line that runs
time.sleep(), _Py_Tick is always 97~99 for main thread.
4) goto 1)

So, Py_MakePendingCalls() will never be called from main
thread. As a result, Ctrl-C doesn't work.

Hmm. I don't have a fix for right now. How about to make
per-thread _Py_Tick?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-28 01:00

Message:
Logged In: YES 
user_id=31435

Ctrl+C interrupts it on Win98SE -- upgrade to a real OS 
<wink>.  When odd cmdline behavior is seen on a Unixish box, 
staring at (try with and without) GNU readline is a good 
experiment.

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2004-03-27 20:56

Message:
Logged In: YES 
user_id=12364

I use debian and can reproduce it.  Python package version 
2.3.3-6.  I also tried with python 2.2 and the bug was NOT 
present.  Package version 2.2.3-9. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-01-13 20:16

Message:
Logged In: YES 
user_id=6656

As the guy says in the bug report, the comp.lang.python
opinion was that this was a problem in debian!  Can someone
with a debian machine (or any other -- I can't) reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

From noreply at sourceforge.net  Sun Mar 28 04:33:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 28 04:34:06 2004
Subject: [ python-Bugs-924806 ] email.Header.Header() produces wrong headers
	with utf8 enc.
Message-ID: <E1B7Wg1-0003Rh-00@sc8-sf-web2.sourceforge.net>

Bugs item #924806, was opened at 2004-03-28 04:33
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924806&group_id=5470

Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Andreas Jung (ajung)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Header.Header() produces wrong headers with utf8 enc.

Initial Comment:
If you pass &#039;utf8&#039; as encoding to the Header() (e.g.
for the subject)
then most mailer can not decode the subject because
they expect
&#039;utf-8&#039; and not &#039;utf8&#039;. Maybe there should be a check
for this encoding in the code.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924806&group_id=5470

From noreply at sourceforge.net  Sun Mar 28 05:00:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 28 05:00:37 2004
Subject: [ python-Bugs-875692 ] Ctrl-C doesn't work with sleepy main thread
Message-ID: <E1B7X5a-0003c3-00@sc8-sf-web4.sourceforge.net>

Bugs item #875692, was opened at 2004-01-12 21:37
Message generated for change (Comment added) made by doko
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

Category: Threads
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
Assigned to: Nobody/Anonymous (nobody)
Summary: Ctrl-C doesn't work with sleepy main thread

Initial Comment:
[forwarded from http://bugs.debian.org/226547]

I only have access to Debian systems ... Maybe this is
related to 846817?

I&#039;m trying to do some basic threading with Python.
However, there are times when Ctrl-C fails to cause a
KeyboardInterrupt in the main thread.

Here is a test program that illustrates the problem. As
written, I cannot interrupt it with Ctrl-C (nothing
happens even if I hold it down). If I uncomment the
print statement in the main thread, then I can
interrupt it with Ctrl-C.

It seems like adding the print in the main thread gives
the main thread a "chance to run" where it finally
notices the signal from the Ctrl-C.  However, I
shouldn&#039;t have to use hacks like this to get this to work.

People on comp.lang.python could not reproduce this on
Fedora and some others, so I&#039;m posting it here (maybe
some problem with Debian&#039;s libc6?).


----------------------------------------------------------------------

>Comment By: Matthias Klose (doko)
Date: 2004-03-28 10:00

Message:
Logged In: YES 
user_id=60903

with the patch applied the example exits usually on the
second or third keystroke, never on the first ^C.

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-28 07:10

Message:
Logged In: YES 
user_id=55188

Here's my patch. Please review/test it. :)

----------------------------------------------------------------------

Comment By: Hye-Shik Chang (perky)
Date: 2004-03-27 19:04

Message:
Logged In: YES 
user_id=55188

Nah. For my some investigation, it doesn't seem to be a
problem of GNU readline.

On my debian machine, main for loop of ceval.c:eval_frame
switches threads context for every periodic loops. Because
main threads is just running time.sleep(), it goes in this way:

1) context switches to sub thread by time.sleep()
2) entering periodic if-block and resets _Py_Tick to 100.
3) because main thread has only 1 line that runs
time.sleep(), _Py_Tick is always 97~99 for main thread.
4) goto 1)

So, Py_MakePendingCalls() will never be called from main
thread. As a result, Ctrl-C doesn't work.

Hmm. I don't have a fix for right now. How about to make
per-thread _Py_Tick?

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-27 16:00

Message:
Logged In: YES 
user_id=31435

Ctrl+C interrupts it on Win98SE -- upgrade to a real OS 
<wink>.  When odd cmdline behavior is seen on a Unixish box, 
staring at (try with and without) GNU readline is a good 
experiment.

----------------------------------------------------------------------

Comment By: Adam Olsen (rhamphoryncus)
Date: 2004-03-27 11:56

Message:
Logged In: YES 
user_id=12364

I use debian and can reproduce it.  Python package version 
2.3.3-6.  I also tried with python 2.2 and the bug was NOT 
present.  Package version 2.2.3-9. 

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-01-13 11:16

Message:
Logged In: YES 
user_id=6656

As the guy says in the bug report, the comp.lang.python
opinion was that this was a problem in debian!  Can someone
with a debian machine (or any other -- I can't) reproduce this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=875692&group_id=5470

From noreply at sourceforge.net  Sun Mar 28 18:31:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Sun Mar 28 18:32:02 2004
Subject: [ python-Bugs-925107 ] _Subfile.readline( ) in mailbox.py ignoring
	self.stop
Message-ID: <E1B7jl0-0000Il-00@sc8-sf-web3.sourceforge.net>

Bugs item #925107, was opened at 2004-03-28 18:31
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925107&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Sye van der Veen (syeberman)
Assigned to: Nobody/Anonymous (nobody)
Summary: _Subfile.readline( ) in mailbox.py ignoring self.stop

Initial Comment:
I&#039;m using Python 2.3.3 (on Windows, but that shouldn&#039;t 
matter) and I&#039;ve noticed a problem with the internal 
_Subfile class in mailbox.py.  The readline method 
doesn&#039;t consider self.stop if the length argument is not 
None.  It has:
    if length is None:
        length = self.stop - self.pos
when really it should have something like:
    if length is None or length < 0:
        length = remaining
    elif length > remaining:
        length = remaining
which is what the read method does.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925107&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 01:47:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 01:47:41 2004
Subject: [ python-Bugs-925152 ] buffer problem in
	pyexpat.c(xmlparse_GetInputContext)
Message-ID: <E1B7qYb-0005Md-00@sc8-sf-web2.sourceforge.net>

Bugs item #925152, was opened at 2004-03-29 16:47
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925152&group_id=5470

Category: XML
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Tobias Sargeant (tobiasjs)
Assigned to: Nobody/Anonymous (nobody)
Summary: buffer problem in pyexpat.c(xmlparse_GetInputContext)

Initial Comment:
xmlparse_GetInputContext doesn&#039;t adjust the bounds of the 
substring it returns, leading to the python string result hanging off 
one or more ends of the buffer & associated nastiness.

2 line fix attached.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925152&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 06:24:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 06:24:12 2004
Subject: [ python-Bugs-743267 ] super passes bad arguments to __get__ when
	used w/class
Message-ID: <E1B7us6-00049U-00@sc8-sf-web4.sourceforge.net>

Bugs item #743267, was opened at 2003-05-25 19:00
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

Category: Type/class unification
Group: Python 2.3
Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Phillip J. Eby (pje)
Assigned to: Phillip J. Eby (pje)
Summary: super passes bad arguments to __get__ when used w/class

Initial Comment:
Run the following code to demonstrate the issue:

====
class Getter(object):
    def __get__(self, ob, typ=None):
        print "called with", (ob, typ)

class Base(object):
    foo = Getter()

class Subclass(Base):
    pass

print
print

Base().foo
Subclass().foo
super(Subclass,Subclass()).foo

Base.foo
Subclass.foo
super(Subclass,Subclass).foo
====

Notice that super(Subclass,Subclass).foo is calling the
descriptor with the *class* object, not &#039;None&#039; as is
done for the analagous cases that don&#039;t use super().

The only reason this ever "works" is because
&#039;classmethod&#039; ignores the &#039;ob&#039; parameter to &#039;__get__&#039;.
 However, this breaks when using &#039;super&#039; to access
property descriptors in 2.3, and it will also break any
user-defined descriptors that are accessed via super().

The behavior is the same in 2.2, and is arguably broken
there as well.  For example,
&#039;super(someclass,someclass).X&#039; (where &#039;X&#039; is a normal
instance method) results in X being a *bound* method,
bound to the class, rather than an *unbound* method,
ready for use with an explicit instance.

Personally, I would be happy if super() grew an extra
argument to disambiguate whether you are doing a
(class,instance) or (class,class) call, anyway.  When
using super() with metaclasses, I&#039;ve encountered
situations where super() guessed wrong, because I was
using a type that was both an instance of, and a
subclass of, the same type.  Being able to explicitly
request that this "class method" form of super is being
used, would eliminate this confusion as well.  In the
face of ambiguity... ;)


----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-03-29 12:23

Message:
Logged In: YES 
user_id=6656

Phillip, it's a bit less of an issue as you've already backported this, 
but it helps if you mention the fixing revisions of the various files 
in the bug report.  Conversely, you should mention the bug # in 
the checkin message, but you did that already :-)

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-03-25 02:49

Message:
Logged In: YES 
user_id=56214

Committed and backported.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-03-20 22:54

Message:
Logged In: YES 
user_id=6380

Phillip, now that you have CVS perms, please check this in
yourself (and backport).

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-03-06 12:35

Message:
Logged In: YES 
user_id=56214

Here's a patch against the CVS head to add a test for the
problem, and fix it.  Please backport to the 2.3 branch as
well.  Thanks!

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-02-25 19:09

Message:
Logged In: YES 
user_id=6656

I don't think you'll find any difference between the trunk
and release23-maint in this area, so it doesn't make much
difference.

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 19:06

Message:
Logged In: YES 
user_id=56214

super().descriptor example:

class Base(object):
    aProp = property(lambda self: "foo")

class Sub(Base):
    def test(klass):
        print super(Sub,klass).aProp
    test = classmethod(test)

Sub.test()

This prints "foo", when it should print "<property object at
0x4024f84c>" instead.

To be precise, the issue is that accessing any descriptor
that behaves differently when retrieved on the class vs. the
instance, will behave incorrectly when accessed via super()
from a classmethod in a subclass.  Classmethods themselves
work correctly because they behave the same way no matter
how you retrieve them.

At present I think the patch should simply change the
descr_get call in super_getattro so that it checks whether
su->obj==su->obj_type, and if so, pass in NULL instead of
su->obj as the second argument to descr_get.

Should I create this patch against the 2.3 maintenance
branch, or against the head?  I'd like to make sure it gets
into the next 2.3.x bugfix release.  (I didn't realize this
bug was still open until I stumbled across it the other day,
and I'm not expecting to upgrade to 2.3 production use for a
few months yet.  I've been using a pure-Python
reimplementation of super() as a workaround.)


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2004-02-25 15:57

Message:
Logged In: YES 
user_id=6380

> However, this breaks when using &#039;super&#039; to access
> property descriptors in 2.3, and it will also break any
> user-defined descriptors that are accessed via super().

Can you give an example of this use case?

I don't have a strong opinion on this; methinks you should
go ahead and prepa patch...

----------------------------------------------------------------------

Comment By: Phillip J. Eby (pje)
Date: 2004-02-25 07:06

Message:
Logged In: YES 
user_id=56214

Assigning to Guido to request pronouncement on the correct
way to fix this before I attempt to create patch(es).

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=743267&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 06:26:26 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 06:26:32 2004
Subject: [ python-Feature Requests-617979 ] need easy way of decoding a
	literal
Message-ID: <E1B7uuQ-0004Lh-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #617979, was opened at 2002-10-03 10:00
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470

Category: Unicode
Group: None
Status: Open
Resolution: None
Priority: 3
Submitted By: Michael Hudson (mwh)
Assigned to: M.-A. Lemburg (lemburg)
Summary: need easy way of decoding a literal

Initial Comment:
Especially since PEP 263, we badly need a way of
turning a Python string literal into the appropriate
object.

The immediate need is to get the compiler package
working again, but I&#039;m sure there are other places it
could be used.

I thought Martin already had a patch somewhere doing
this, but I can&#039;t find it.  Maybe he remembers?

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-03-29 12:26

Message:
Logged In: YES 
user_id=6656

I'd have to admit to not being sure what I'm actually asking for in 
this report, so I won't object if it's closed.

I do think that, e.g., using the tokenize module has gotten harder 
since PEP 263, but I don't have a pressing problem right now...

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-25 19:35

Message:
Logged In: YES 
user_id=21627

It still needs to be implemented.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-03-25 19:32

Message:
Logged In: YES 
user_id=38388

Has there been any progress on this or can I close it ?

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2003-01-16 13:28

Message:
Logged In: YES 
user_id=6656

For a bunch of reasons, I now care less about this so I'm
going to reduce the priority.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-10-04 12:15

Message:
Logged In: YES 
user_id=38388

MWH: My first paragraph was refering to Martin's suggestion
to use eval() for mapping literal strings to objects.

Please take this to the python-dev mailing list.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-10-04 10:00

Message:
Logged In: YES 
user_id=6656

MAL: I don't understand your first paragraph at all.

The {sys.,}source_encoding variable might work, but it would
be a dreadful hack for my purposes.  Using eval() is already
a nasty hack, IMHO.

I agree a mailing list is a more civilised interface than a
web browser...


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 20:21

Message:
Logged In: YES 
user_id=21627

That would not be correct. If you have a (plain) string
literal, it would end up encoded as UTF-8, whereas the
original source encoding was, say, Latin-1. People will be
confused if string literals don't come out in the expected
encoding in interactive mode.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2002-10-03 19:11

Message:
Logged In: YES 
user_id=38388

I believe the correct way to handle this would be to have
eval() accept Unicode and then convert it to UTF-8 for
the parser to process. The PEP only talks about compile()
which should accept Unicode objects, but eval() is certainly
a candidate too.

About the source_encoding idea: wouldn't it be better to
define this for interactive use in the sys module ? A Python
startup script could then be used to set this variable in
interactive mode.

BTW, it's better to discuss these things on python-dev than
in these small textareas... IMHO, at least.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 18:55

Message:
Logged In: YES 
user_id=21627

I see.

For a different reason (interactive mode), I have been
contemplating to recognize a variable source_encoding in
globals(), which would be set in interactive mode to the
terminal's encoding, so that input of non-ASCII Unicode
literals would "work", without having to type an encoding
declaration each time.

I believe such a mechanism could also solve this problem;
callers of eval would have to set the global.

What do you think?


----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2002-10-03 17:45

Message:
Logged In: YES 
user_id=6656

How do you get eval to take notice of the declared encoding?

What I want is the functionality of compile.c:parsestr
available from Python.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-10-03 17:35

Message:
Logged In: YES 
user_id=21627

Not sure what you are asking. eval() would certainly be an
easy way, no?
In any case, I'm not aware of an alternative.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=617979&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 11:07:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 11:07:14 2004
Subject: [ python-Bugs-919776 ] Can't create Carbon.File.FSSpec for
	non-existent file
Message-ID: <E1B7zI3-0005Tl-00@sc8-sf-web3.sourceforge.net>

Bugs item #919776, was opened at 2004-03-19 20:36
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919776&group_id=5470

Category: Macintosh
Group: Platform-specific
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: has (hhas)
Assigned to: Jack Jansen (jackjansen)
Summary: Can't create Carbon.File.FSSpec for non-existent file

Initial Comment:
MacPython 2.3 can&#039;t create a Carbon.File.FSSpec for a non-
existent file. 

Example (where &#039;NEWFILE&#039; is name of a file still to be created):

from Carbon.File import *

f = FSSpec(u&#039;/Users/has/NEWFILE&#039;)

--> MacOS.Error: (-43, &#039;File not found&#039;)

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-03-29 17:07

Message:
Logged In: YES 
user_id=6656

I'm fairly sure this is a duplicate... at least, you can find mails on 
pythonmac-sig where I work around this.  It's a bit of a pain.

Ah, yes, it's 706592.  Closing.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=919776&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 12:57:47 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 12:58:04 2004
Subject: [ python-Bugs-922964 ] file built-in object is after file() function
Message-ID: <E1B8119-00088o-00@sc8-sf-web4.sourceforge.net>

Bugs item #922964, was opened at 2004-03-25 08:18
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922964&group_id=5470

Category: Documentation
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Nobody/Anonymous (nobody)
Summary: file built-in object is after file() function

Initial Comment:
In section 2.1 of the HTML and PDF-A4 library 
references (so supposedly in all lib references), in the 
description of the file() function, it says that "Return a 
new file object (described earlier under Built-in Types)", 
but the Built-in Types section is later not earlier.

----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-03-29 18:57

Message:
Logged In: YES 
user_id=6656

That's not what he's complaining about, though.

Seems to me that just removing the 'earlier' would suffice.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 08:28

Message:
Logged In: YES 
user_id=80475

Forward references are only problematic in the tutorial. 
The rest of the docs tend to be used in a random access
fashion rather than sequentially.  That's a good thing
because forward references are everywhere.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922964&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 13:41:56 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 13:41:59 2004
Subject: [ python-Bugs-925500 ] os.py uses #' - undocumented magic?
Message-ID: <E1B81hs-00043Q-00@sc8-sf-web4.sourceforge.net>

Bugs item #925500, was opened at 2004-03-29 13:41
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.py uses #' - undocumented magic?

Initial Comment:
os.py wraps the first section of code (determining which 
operating system and path to use) in lines containing just 

#&#039;

(A comment start followed by a single-quote start.)

This looks like unexplained magic.  It should either be 
deleted, or commented to indicate why it is there.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 13:42:53 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 13:42:56 2004
Subject: [ python-Bugs-925500 ] os.py uses #' - undocumented magic?
Message-ID: <E1B81in-0004pk-00@sc8-sf-web3.sourceforge.net>

Bugs item #925500, was opened at 2004-03-29 13:41
Message generated for change (Settings changed) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

Category: Python Library
>Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.py uses #' - undocumented magic?

Initial Comment:
os.py wraps the first section of code (determining which 
operating system and path to use) in lines containing just 

#&#039;

(A comment start followed by a single-quote start.)

This looks like unexplained magic.  It should either be 
deleted, or commented to indicate why it is there.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 14:28:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 14:28:23 2004
Subject: [ python-Bugs-925537 ] dir(mod) OK or use vars(mod).keys()?
Message-ID: <E1B82Qm-0006Qg-00@sc8-sf-web2.sourceforge.net>

Bugs item #925537, was opened at 2004-03-29 14:28
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 14:39:34 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 14:39:45 2004
Subject: [ python-Bugs-925537 ] dir(mod) OK or use vars(mod).keys()?
Message-ID: <E1B82be-00008p-00@sc8-sf-web1.sourceforge.net>

Bugs item #925537, was opened at 2004-03-29 14:28
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

>Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:39

Message:
Logged In: YES 
user_id=764593

If there concern is over attributes that are "public" but don't 
exist until called, then most uses of dir and vars are already 
broken.  An alternative reasonable promise would be

The output of dir(obj) will always include all (public?, 
non-magical?) names in vars(obj).keys().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 14:58:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 15:02:28 2004
Subject: [ python-Bugs-925537 ] dir(mod) OK or use vars(mod).keys()?
Message-ID: <E1B82tl-000178-00@sc8-sf-web2.sourceforge.net>

Bugs item #925537, was opened at 2004-03-29 14:28
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

>Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:58

Message:
Logged In: YES 
user_id=764593

Correction:  "The output of dir (module) will always include ..."

The most common use is figuring out what to do with (import 
from) a module.

Symmetry suggests the same for a no-argument call or a class 
or type object, but object instances do not use their __dict__ 
for their attributes; the results are already different there.

-jJ


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:39

Message:
Logged In: YES 
user_id=764593

If there concern is over attributes that are "public" but don't 
exist until called, then most uses of dir and vars are already 
broken.  An alternative reasonable promise would be

The output of dir(obj) will always include all (public?, 
non-magical?) names in vars(obj).keys().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 15:53:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 15:53:22 2004
Subject: [ python-Bugs-903339 ] OpenVMS file system and UNIVERSAL_NEWLINES
	support
Message-ID: <E1B83l0-0008H8-00@sc8-sf-web1.sourceforge.net>

Bugs item #903339, was opened at 2004-02-24 11:20
Message generated for change (Comment added) made by pieronne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pi?ronne Jean-Fran?ois (pieronne)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenVMS file system and UNIVERSAL_NEWLINES support

Initial Comment:
I am one of the maintainer of Python on OpenVMS.

Building from time to time Python 2.4 from CVS
snapshot, I have just noticed that all the conditional
compilation against WITH_UNIVERSAL_NEWLINES has been
removed.

This is a major problem on OpenVMS.

VMS has a complex file system which is mostly record
oriented and not stream oriented (even if it support
stream oriented files, this is not the default).
For example it support the following record formats:
fixed-length, variable-length, variable with
fixed-length control, 3 stream format, etc...
The default is variable-length.

So reading (opening) text file, for example during a
import, in binary mode lead to incorrect results
because there are no &#039;\n&#039; or any character (or
combinaison of characters) at the end of the line.
If the file is not open in binary mode the VMS CRTL
automatically append a &#039;\n&#039; at the end of the record,
so all work correctly. This not the case in binary
mode, in this case the record is read as is, in fact
you even get the control part of the record for some
record format.

So, is it possible to maintain this test, even as
undocumented or is it acceptable to transform it into a
specific VMS test. But I suspect that other mainframe
file systems will have the same problem.

Thanks for any help.

Regards,

Jean-Fran?ois 

----------------------------------------------------------------------

>Comment By: Pi?ronne Jean-Fran?ois (pieronne)
Date: 2004-03-29 22:53

Message:
Logged In: YES 
user_id=414701

I have attach a patch for
Include/fileobject.h
Modules/bz2module.c
Objects/fileobject.c

This patch use a new conditionnal compilation item:
Py_USE_RECORD_IO

which need to be define only on systems which use RECORD
oriented IO and not stream oriented IO

It also contain a small fix for OpenVMS.

Jean-Fran?ois

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 14:14:41 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 16:02:20 2004
Subject: [ python-Bugs-924218 ] socket._fileobject._getclosed() returns
	wrong value
Message-ID: <E1B82DZ-0007iv-00@sc8-sf-web4.sourceforge.net>

Bugs item #924218, was opened at 2004-03-26 13:33
Message generated for change (Comment added) made by gigamorph
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924218&group_id=5470

Category: Python Library
Group: Python 2.3
>Status: Closed
>Resolution: Duplicate
Priority: 5
Submitted By: June Kim (gigamorph)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket._fileobject._getclosed() returns wrong value

Initial Comment:
In socket.py, _getclosed() is defined as follows:

  class _fileobject(object)
      # ...
      def _getclosed(self):
          return self._sock is not None

Which causes the following interaction:
  >>> import socket
  >>> s = socket.socket()
  >>> f = s.makefile()
  >>> f.closed
  True
  >>> f.close()
  >>> f.closed
  False

Shouldn&#039;t the values of f.closed the opposite of the above?





----------------------------------------------------------------------

>Comment By: June Kim (gigamorph)
Date: 2004-03-29 11:14

Message:
Logged In: YES 
user_id=1007376

Duplicate, resolved in #924242.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924218&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 16:34:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 16:34:13 2004
Subject: [ python-Bugs-925628 ] help does not help with imported objects
Message-ID: <E1B84OX-0002Hr-00@sc8-sf-web3.sourceforge.net>

Bugs item #925628, was opened at 2004-03-29 16:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help does not help with imported objects

Initial Comment:
help(re) just says it is a wrapper for sre.  To get actually 
help, you need to explicitly import sre as well.

re.__doc__ = re.__doc__ + sre.__doc__ helps, but still 
does not list information on classes or exported functions. 

Specific requests, such as 

help(re.subn) 

do work;  it is only the module-level help that is lacking 
when a module reexports imported objects.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 16:34:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 16:34:36 2004
Subject: [ python-Bugs-925628 ] help does not help with imported objects
Message-ID: <E1B84Ov-0002Js-00@sc8-sf-web3.sourceforge.net>

Bugs item #925628, was opened at 2004-03-29 16:34
Message generated for change (Settings changed) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
>Priority: 2
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help does not help with imported objects

Initial Comment:
help(re) just says it is a wrapper for sre.  To get actually 
help, you need to explicitly import sre as well.

re.__doc__ = re.__doc__ + sre.__doc__ helps, but still 
does not list information on classes or exported functions. 

Specific requests, such as 

help(re.subn) 

do work;  it is only the module-level help that is lacking 
when a module reexports imported objects.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 16:34:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 16:34:55 2004
Subject: [ python-Bugs-925537 ] dir(mod) OK or use vars(mod).keys()?
Message-ID: <E1B84PC-0003iZ-00@sc8-sf-web1.sourceforge.net>

Bugs item #925537, was opened at 2004-03-29 14:28
Message generated for change (Settings changed) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 4
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:58

Message:
Logged In: YES 
user_id=764593

Correction:  "The output of dir (module) will always include ..."

The most common use is figuring out what to do with (import 
from) a module.

Symmetry suggests the same for a no-argument call or a class 
or type object, but object instances do not use their __dict__ 
for their attributes; the results are already different there.

-jJ


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:39

Message:
Logged In: YES 
user_id=764593

If there concern is over attributes that are "public" but don't 
exist until called, then most uses of dir and vars are already 
broken.  An alternative reasonable promise would be

The output of dir(obj) will always include all (public?, 
non-magical?) names in vars(obj).keys().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 16:35:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 16:35:53 2004
Subject: [ python-Bugs-925500 ] os.py uses #' - undocumented magic?
Message-ID: <E1B84Pa-0004p7-00@sc8-sf-web4.sourceforge.net>

Bugs item #925500, was opened at 2004-03-29 13:41
Message generated for change (Settings changed) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 3
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: os.py uses #' - undocumented magic?

Initial Comment:
os.py wraps the first section of code (determining which 
operating system and path to use) in lines containing just 

#&#039;

(A comment start followed by a single-quote start.)

This looks like unexplained magic.  It should either be 
deleted, or commented to indicate why it is there.



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:05:13 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:05:17 2004
Subject: [ python-Bugs-903339 ] OpenVMS file system and UNIVERSAL_NEWLINES
	support
Message-ID: <E1B84sb-0004wq-00@sc8-sf-web3.sourceforge.net>

Bugs item #903339, was opened at 2004-02-24 11:20
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pi?ronne Jean-Fran?ois (pieronne)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenVMS file system and UNIVERSAL_NEWLINES support

Initial Comment:
I am one of the maintainer of Python on OpenVMS.

Building from time to time Python 2.4 from CVS
snapshot, I have just noticed that all the conditional
compilation against WITH_UNIVERSAL_NEWLINES has been
removed.

This is a major problem on OpenVMS.

VMS has a complex file system which is mostly record
oriented and not stream oriented (even if it support
stream oriented files, this is not the default).
For example it support the following record formats:
fixed-length, variable-length, variable with
fixed-length control, 3 stream format, etc...
The default is variable-length.

So reading (opening) text file, for example during a
import, in binary mode lead to incorrect results
because there are no &#039;\n&#039; or any character (or
combinaison of characters) at the end of the line.
If the file is not open in binary mode the VMS CRTL
automatically append a &#039;\n&#039; at the end of the record,
so all work correctly. This not the case in binary
mode, in this case the record is read as is, in fact
you even get the control part of the record for some
record format.

So, is it possible to maintain this test, even as
undocumented or is it acceptable to transform it into a
specific VMS test. But I suspect that other mainframe
file systems will have the same problem.

Thanks for any help.

Regards,

Jean-Fran?ois 

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:05

Message:
Logged In: YES 
user_id=21627

I don't understand the problem. What precisely is currently
not working, and precisely why does it fail? (exact file and
line that causes problems, please)

----------------------------------------------------------------------

Comment By: Pi?ronne Jean-Fran?ois (pieronne)
Date: 2004-03-29 22:53

Message:
Logged In: YES 
user_id=414701

I have attach a patch for
Include/fileobject.h
Modules/bz2module.c
Objects/fileobject.c

This patch use a new conditionnal compilation item:
Py_USE_RECORD_IO

which need to be define only on systems which use RECORD
oriented IO and not stream oriented IO

It also contain a small fix for OpenVMS.

Jean-Fran?ois

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:09:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:10:29 2004
Subject: [ python-Bugs-925500 ] os.py uses #' - undocumented magic?
Message-ID: <E1B84x5-0005Hs-00@sc8-sf-web3.sourceforge.net>

Bugs item #925500, was opened at 2004-03-29 20:41
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 3
Submitted By: Jim Jewett (jimjjewett)
>Assigned to: Skip Montanaro (montanaro)
Summary: os.py uses #' - undocumented magic?

Initial Comment:
os.py wraps the first section of code (determining which 
operating system and path to use) in lines containing just 

#&#039;

(A comment start followed by a single-quote start.)

This looks like unexplained magic.  It should either be 
deleted, or commented to indicate why it is there.



----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:09

Message:
Logged In: YES 
user_id=21627

Assigning to Skip, who added these in os.py 1.41, with a
check-in message of

added several more __all__ lists


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:11:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:11:32 2004
Subject: [ python-Bugs-925537 ] dir(mod) OK or use vars(mod).keys()?
Message-ID: <E1B84yd-0005WK-00@sc8-sf-web2.sourceforge.net>

Bugs item #925537, was opened at 2004-03-29 21:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 4
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:11

Message:
Logged In: YES 
user_id=21627

I fail to see a bug. Which specific usage of dir() does not
work as intended?

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 21:58

Message:
Logged In: YES 
user_id=764593

Correction:  "The output of dir (module) will always include ..."

The most common use is figuring out what to do with (import 
from) a module.

Symmetry suggests the same for a no-argument call or a class 
or type object, but object instances do not use their __dict__ 
for their attributes; the results are already different there.

-jJ


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 21:39

Message:
Logged In: YES 
user_id=764593

If there concern is over attributes that are "public" but don't 
exist until called, then most uses of dir and vars are already 
broken.  An alternative reasonable promise would be

The output of dir(obj) will always include all (public?, 
non-magical?) names in vars(obj).keys().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:17:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:17:16 2004
Subject: [ python-Bugs-924703 ] test_unicode_file fails on Win98SE
Message-ID: <E1B8543-0005qo-00@sc8-sf-web3.sourceforge.net>

Bugs item #924703, was opened at 2004-03-28 03:48
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: M.-A. Lemburg (lemburg)
Summary: test_unicode_file fails on Win98SE

Initial Comment:
In current CVS, test_unicode_file fails on Win98SE.  This 
has been going on for some time, actually.

ERROR: test_single_files (__main__.TestUnicodeFiles)

Traceback (most recent call last):
  File ".../lib/test/test_unicode_file.py", line 162, in 
test_single_files
    self._test_single(TESTFN_UNICODE)
  File ".../lib/test/test_unicode_file.py", line 136, in 
_test_single
    self._do_single(filename)
  File ".../lib/test/test_unicode_file.py", line 49, in 
_do_single
    new_base = unicodedata.normalize("NFD", new_base)
TypeError: normalized() argument 2 must be unicode, 
not str

At this point,

filename is TESTFN_UNICODE is
u&#039;@test-\xe0\xf2&#039;

os.path.abspath(filename) is
&#039;C:\Code\python\PC\VC6\@test-\xe0\xf2&#039;

new_base is
&#039;@test-\xe0\xf2

So abspath() removed the "Unicodeness" of filename, 
and new_base is indeed not a Unicode string at this 
point.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:17

Message:
Logged In: YES 
user_id=21627

abspath(unicode) should return a Unicode path.

Does it help if _abspath (in ntpath.py) is changed to contain

            if not isabs(path):
                if isinstance(path, unicode): cwd = os.getcwdu()
                else: cwd = os.getcwd()
                path = join(cwd, path)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:18:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:18:53 2004
Subject: [ python-Bugs-924361 ] unicodeobjct: bad argument to internal
	function
Message-ID: <E1B855a-00063x-00@sc8-sf-web2.sourceforge.net>

Bugs item #924361, was opened at 2004-03-27 09:20
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924361&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthias Klose (doko)
>Assigned to: Martin v. L?wis (loewis)
Summary: unicodeobjct: bad argument to internal function

Initial Comment:
[forwarded from http://bugs.debian.org/239986]

#! /usr/bin/python2.3
import unicodedata
unicodedata.normalize(&#039;NFKC&#039;, u&#039;&#039;)

I guess (but haven&#039;t looked at the source) that
something isn&#039;t cleaned up properly in this scenario. 
The bug doesn&#039;t manifest itself in the normalize() call
itself but the exception is thrown in the next
statement.  (eg running  unicodedata.normalize(&#039;NFKC&#039;,
u&#039;&#039;) ; x = 1 interactively causes the error to be
printed after the x=1 statement)

The x=1 doesn&#039;t seem to be needed, simply hitting
return shows the message.

$ python
Python 2.3.3 (#2, Feb 24 2004, 09:29:20) 
[GCC 3.3.3 (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import unicodedata
>>> unicodedata.normalize(&#039;NFKC&#039;, u&#039;&#039;)
u&#039;&#039;
>>> 
SystemError: ../Objects/unicodeobject.c:278: bad
argument to internal function
>>> 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924361&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:19:57 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:20:01 2004
Subject: [ python-Bugs-924333 ] Build issues (lib path) on linux2-x86_64
Message-ID: <E1B856r-00064A-00@sc8-sf-web3.sourceforge.net>

Bugs item #924333, was opened at 2004-03-27 05:12
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Petrilli (petrilli)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build issues (lib path) on linux2-x86_64

Initial Comment:
The current CVS HEAD won&#039;t build "out of the box" on a
Fedora x86_64 box, nor on any other Linux AMD64
platform.  This is due to the fact that the libraries
for many things are not in /usr/lib, but /usr/lib64,
and the current &#039;autoconf&#039; script, as well as the
current setup.py do not look there.  When added, they
detect, build.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:19

Message:
Logged In: YES 
user_id=21627

Can you submit a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:20:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:20:59 2004
Subject: [ python-Bugs-924294 ] IPV6 not correctly ifdef'd in socketmodule.c
Message-ID: <E1B857h-0007eZ-00@sc8-sf-web1.sourceforge.net>

Bugs item #924294, was opened at 2004-03-27 01:07
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924294&group_id=5470

Category: Build
Group: Python 2.3
Status: Open
Resolution: None
>Priority: 7
Submitted By: David Meleedy (dmeleedy)
>Assigned to: Martin v. L?wis (loewis)
Summary: IPV6 not correctly ifdef'd in socketmodule.c

Initial Comment:
buckaroo-75: diff -c3 socketmodule.c-dist socketmodule.c
*** socketmodule.c-dist Fri Mar 26 18:51:52 2004
--- socketmodule.c      Fri Mar 26 18:52:47 2004
***************
*** 2971,2977 ****
                return NULL;
        }
  
! #ifndef ENABLE_IPV6
        if(af == AF_INET6) {
                PyErr_SetString(socket_error,
                                "can&#039;t use AF_INET6,
IPv6 is disabled");
--- 2971,2977 ----
                return NULL;
        }
  
! #ifdef ENABLE_IPV6
        if(af == AF_INET6) {
                PyErr_SetString(socket_error,
                                "can&#039;t use AF_INET6,
IPv6 is disabled");


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924294&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:22:15 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:22:21 2004
Subject: [ python-Feature Requests-923697 ] SAX2 'property_encoding' feature
	not supported
Message-ID: <E1B8595-0000Pe-00@sc8-sf-web4.sourceforge.net>

Feature Requests item #923697, was opened at 2004-03-26 07:39
Message generated for change (Settings changed) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=923697&group_id=5470

>Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Joseph Walton (josephw)
Assigned to: Nobody/Anonymous (nobody)
Summary: SAX2 'property_encoding' feature not supported

Initial Comment:
I need to parse a byte stream as an XML document and,
afterwards, access the same document as a Unicode
string. I would prefer to rely on the parser&#039;s
charset-determining logic, and the &#039;property_encoding&#039;
feature
("http://www.python.org/sax/properties/encoding") seems
to offer exactly this information.

However, the default Expat parser doesn&#039;t support this
feature.

---
from xml.sax import make_parser, handler
from xml.sax.xmlreader import InputSource
from sys import stdin

p = make_parser()

# Should not fail. Should it return None, or UTF-8?
assert(p.getProperty(handler.property_encoding) == None)

source = InputSource()
source.setByteStream(stdin)

p.parse(source)

# Should now be the name of the actual encoding used
assert(p.getProperty(handler.property_encoding) != None)
---

This raises SAXNotRecognizedException.

Is there another SAX parser I could use instead?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=923697&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:26:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:26:11 2004
Subject: [ python-Bugs-922914 ] Installer misplaces tcl library
Message-ID: <E1B85Cn-0000gy-00@sc8-sf-web4.sourceforge.net>

Bugs item #922914, was opened at 2004-03-25 06:55
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: WS Wong (wswong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer misplaces tcl library

Initial Comment:
Python 2.3.3 on Windows 2000 Professional
-------------------------------------------
Could not start IDLE after installation of Python in 
C:\WSPrograms\Python23

Went to C:\WSPrograms\Python23\Lib\idlelib and from 
the command line typed
C:\WSPrograms\Python23\python idle.py

The following traceback obtained:

C:\WSPrograms\Python23
\Lib\idlelib>c:\wsprograms\python23\python idle.py
Traceback (most recent call last):
  File "idle.py", line 23, in ?
    idlelib.PyShell.main()
  File "C:\WSPrograms\Python23\lib\idlelib\PyShell.py", 
line 1269, in main
    root = Tk(className="Idle")
  File "C:\WSPrograms\Python23\lib\lib-tk\Tkinter.py", 
line 1564, in __init__
    self.tk = _tkinter.create(screenName, baseName, 
className)
_tkinter.TclError: Can&#039;t find a usable init.tcl in the 
following directories:
    {C:\WSPrograms\ruby167ms\tcl\lib\tcl8.3} 
{C:\WSPrograms\ruby167ms\tcl\lib\tc
l8.3} C:/WSPrograms/ruby167ms/tcl/lib/tcl8.4 
c:/wsprograms/python23/lib/tcl8.4 c
:/wsprograms/lib/tcl8.4 c:/lib/tcl8.4 
c:/wsprograms/library c:/library c:/../tcl
8.4.3/library

Looking at the directories that was installed, 
I found that the tcl8.4 was actually located in
C:\WSPrograms\Python23\tcl\tk8.4
which was never on the search path.

After I copied the tcl8.4 directory to  
C:\WSPrograms\Python23\Lib
and run the commands again, it worked. Not sure what 
other implications this will cause 
but at least I have IDLE running again. 


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:26

Message:
Logged In: YES 
user_id=21627

Have you set the TCL_LIBRARY environment variable? If so,
you should unset it. If you cannot unset it, you are on your
own - as a system administrator, by setting this variable,
you express the desire to use a different Tcl installation
(apparently the one that comes with Ruby), and then it is
your responsibility to make this setting work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:28:30 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:28:33 2004
Subject: [ python-Bugs-921077 ] embedding in multi-threaded & multi
	sub-interpreter environ
Message-ID: <E1B85F8-0006sr-00@sc8-sf-web2.sourceforge.net>

Bugs item #921077, was opened at 2004-03-22 16:39
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470

Category: None
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Atul (atulkshirsagar)
Assigned to: Nobody/Anonymous (nobody)
>Summary: embedding in multi-threaded & multi sub-interpreter environ

Initial Comment:
I am embedding python in my C++ application. I am 
using Python *2.3.2* with a C++ extention DLL in multi-
threaded environment. I am using SWIG-1.3.19 to 
generate C++ to Python interface.

Now to explain it in details,
1. Python initialization [Py_Initialize()] and finalization 
[Py_Finalize()] is done in the *main* thread.
2. For each new thread I create a separate sub-
interpreter [Py_NewInterpreter()]. 
3. Using PyRun_String("import myModule"...) before 
execution of python script, extention module is imported.
4. Each thread executes *multiple* python script using 
PyEval_EvalCode() using the class objects in my 
extention DLL.
5. Each sub-interpreter is destroyed [Py_EndInterpreter
()] at the end of that particular thread.

I am observing that;
As explained above when multiple threads are running. 
And as one of these threads finishes, in other running 
threads I start getting 
"TypeError: &#039;NoneType&#039; object is not callable" error on 
the methods called on class objects in extention module. 

The same code *works fine* with Python 2.2.2.

I have found these links more or less talking about the 
same problem
migrating from 2.2 to 2.3.
http://mail.python.org/pipermail/python-dev/2003-
September/038237.html
http://mail.python.org/pipermail/python-list/2004-
February/206851.html
http://mail.python.org/pipermail/python-list/2004-
January/204040.html

I *guess* what is happening is global variables are 
zapped to "NoneType"
when one thread finishes and other thread trying to 
access them through the
Python script (step 4.) this error is generated. But it 
*works* sometimes
when(*guess*) the running thread is at step 3. and by 
importing the  module
the global variables are re-initialized for "Type" 
information.

I tried using reload(myModule) to solve the problem but 
that is generating
big memory leak every time it is called.

Is this a know issue with 2.3 (interpreter?) ? Or is there 
a change for 2.3 in the way embedding should be done 
in a multi-threaded and multi-sub-interpreter 
environment ?


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:28

Message:
Logged In: YES 
user_id=21627

Can you provide an example that demonstrates the supposed bug?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=921077&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:29:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:30:05 2004
Subject: [ python-Bugs-905046 ] test_tcl fails -- 
Message-ID: <E1B85GV-0008Lv-00@sc8-sf-web1.sourceforge.net>

Bugs item #905046, was opened at 2004-02-26 14:11
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905046&group_id=5470

Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Michael Hudson (mwh)
Assigned to: David Ascher (david_ascher)
>Summary: test_tcl fails -- 

Initial Comment:
As summary, really.  Fairly stock Redhat 9 install, CVS
as of a few minutes back.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:29

Message:
Logged In: YES 
user_id=21627

mwh, does that still fail?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=905046&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:32:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:32:45 2004
Subject: [ python-Bugs-922914 ] Installer misplaces tcl library
Message-ID: <E1B85J8-00006S-00@sc8-sf-web1.sourceforge.net>

Bugs item #922914, was opened at 2004-03-25 00:55
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: WS Wong (wswong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer misplaces tcl library

Initial Comment:
Python 2.3.3 on Windows 2000 Professional
-------------------------------------------
Could not start IDLE after installation of Python in 
C:\WSPrograms\Python23

Went to C:\WSPrograms\Python23\Lib\idlelib and from 
the command line typed
C:\WSPrograms\Python23\python idle.py

The following traceback obtained:

C:\WSPrograms\Python23
\Lib\idlelib>c:\wsprograms\python23\python idle.py
Traceback (most recent call last):
  File "idle.py", line 23, in ?
    idlelib.PyShell.main()
  File "C:\WSPrograms\Python23\lib\idlelib\PyShell.py", 
line 1269, in main
    root = Tk(className="Idle")
  File "C:\WSPrograms\Python23\lib\lib-tk\Tkinter.py", 
line 1564, in __init__
    self.tk = _tkinter.create(screenName, baseName, 
className)
_tkinter.TclError: Can&#039;t find a usable init.tcl in the 
following directories:
    {C:\WSPrograms\ruby167ms\tcl\lib\tcl8.3} 
{C:\WSPrograms\ruby167ms\tcl\lib\tc
l8.3} C:/WSPrograms/ruby167ms/tcl/lib/tcl8.4 
c:/wsprograms/python23/lib/tcl8.4 c
:/wsprograms/lib/tcl8.4 c:/lib/tcl8.4 
c:/wsprograms/library c:/library c:/../tcl
8.4.3/library

Looking at the directories that was installed, 
I found that the tcl8.4 was actually located in
C:\WSPrograms\Python23\tcl\tk8.4
which was never on the search path.

After I copied the tcl8.4 directory to  
C:\WSPrograms\Python23\Lib
and run the commands again, it worked. Not sure what 
other implications this will cause 
but at least I have IDLE running again. 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-29 17:32

Message:
Logged In: YES 
user_id=31435

This is almost certainly Ruby's "fault" -- the Ruby Windows 
installer does set environment variables forcing every app to 
try using Ruby's version of Tcl/Tk.  Get rid of the Ruby 
envars, and IDLE should work fine.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 17:26

Message:
Logged In: YES 
user_id=21627

Have you set the TCL_LIBRARY environment variable? If so,
you should unset it. If you cannot unset it, you are on your
own - as a system administrator, by setting this variable,
you express the desire to use a different Tcl installation
(apparently the one that comes with Ruby), and then it is
your responsibility to make this setting work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:34:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:34:22 2004
Subject: [ python-Bugs-908936 ] rexec.r_eval() does not work like eval()
Message-ID: <E1B85KZ-00075L-00@sc8-sf-web3.sourceforge.net>

Bugs item #908936, was opened at 2004-03-03 10:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908936&group_id=5470

Category: Python Library
Group: Python 2.2.2
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec.r_eval() does not work like eval()

Initial Comment:
I want to use the eval() function of python as simple
ultra-restricted expression evaluator. So, when
executing r_eval(), I want to pass a dictionnary of the
local and global variables, just like it is possible
with eval(). However, r_eval() does not allow it.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:34

Message:
Logged In: YES 
user_id=21627

The rexec module does not provide restricted execution, so
you should not be using it in the first place.

Closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908936&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 17:35:22 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 17:36:12 2004
Subject: [ python-Bugs-906405 ] Build fails on XP
Message-ID: <E1B85Lm-0000Iu-00@sc8-sf-web1.sourceforge.net>

Bugs item #906405, was opened at 2004-02-28 12:08
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470

Category: Build
Group: Python 2.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Con (shrodingersdog)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build fails on XP

Initial Comment:
When trying to build the source:

Modules/posixmodule.c fails to build.

I&#039;m running on XP SP1 using 
mingw32-make ver 3.80

Is there any known issues on XP?


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:35

Message:
Logged In: YES 
user_id=21627

In what way precisely does it fail?

It builds fine for me with VC.NET 2003, which is the
official build environment for Python on XP.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=906405&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 18:05:07 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 18:05:13 2004
Subject: [ python-Bugs-903339 ] OpenVMS file system and UNIVERSAL_NEWLINES
	support
Message-ID: <E1B85oZ-0002RA-00@sc8-sf-web1.sourceforge.net>

Bugs item #903339, was opened at 2004-02-24 11:20
Message generated for change (Comment added) made by pieronne
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

Category: None
Group: Platform-specific
Status: Open
Resolution: None
Priority: 5
Submitted By: Pi?ronne Jean-Fran?ois (pieronne)
Assigned to: Nobody/Anonymous (nobody)
Summary: OpenVMS file system and UNIVERSAL_NEWLINES support

Initial Comment:
I am one of the maintainer of Python on OpenVMS.

Building from time to time Python 2.4 from CVS
snapshot, I have just noticed that all the conditional
compilation against WITH_UNIVERSAL_NEWLINES has been
removed.

This is a major problem on OpenVMS.

VMS has a complex file system which is mostly record
oriented and not stream oriented (even if it support
stream oriented files, this is not the default).
For example it support the following record formats:
fixed-length, variable-length, variable with
fixed-length control, 3 stream format, etc...
The default is variable-length.

So reading (opening) text file, for example during a
import, in binary mode lead to incorrect results
because there are no &#039;\n&#039; or any character (or
combinaison of characters) at the end of the line.
If the file is not open in binary mode the VMS CRTL
automatically append a &#039;\n&#039; at the end of the record,
so all work correctly. This not the case in binary
mode, in this case the record is read as is, in fact
you even get the control part of the record for some
record format.

So, is it possible to maintain this test, even as
undocumented or is it acceptable to transform it into a
specific VMS test. But I suspect that other mainframe
file systems will have the same problem.

Thanks for any help.

Regards,

Jean-Fran?ois 

----------------------------------------------------------------------

>Comment By: Pi?ronne Jean-Fran?ois (pieronne)
Date: 2004-03-30 01:05

Message:
Logged In: YES 
user_id=414701

Hi Martin,

A few week ago I have open a thread on the mailing list do
you have read it which explain the problem and include a few
others contributions.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:05

Message:
Logged In: YES 
user_id=21627

I don't understand the problem. What precisely is currently
not working, and precisely why does it fail? (exact file and
line that causes problems, please)

----------------------------------------------------------------------

Comment By: Pi?ronne Jean-Fran?ois (pieronne)
Date: 2004-03-29 22:53

Message:
Logged In: YES 
user_id=414701

I have attach a patch for
Include/fileobject.h
Modules/bz2module.c
Objects/fileobject.c

This patch use a new conditionnal compilation item:
Py_USE_RECORD_IO

which need to be define only on systems which use RECORD
oriented IO and not stream oriented IO

It also contain a small fix for OpenVMS.

Jean-Fran?ois

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=903339&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 18:11:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 18:11:26 2004
Subject: [ python-Bugs-924703 ] test_unicode_file fails on Win98SE
Message-ID: <E1B85uX-0001Mb-00@sc8-sf-web2.sourceforge.net>

Bugs item #924703, was opened at 2004-03-27 20:48
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: M.-A. Lemburg (lemburg)
Summary: test_unicode_file fails on Win98SE

Initial Comment:
In current CVS, test_unicode_file fails on Win98SE.  This 
has been going on for some time, actually.

ERROR: test_single_files (__main__.TestUnicodeFiles)

Traceback (most recent call last):
  File ".../lib/test/test_unicode_file.py", line 162, in 
test_single_files
    self._test_single(TESTFN_UNICODE)
  File ".../lib/test/test_unicode_file.py", line 136, in 
_test_single
    self._do_single(filename)
  File ".../lib/test/test_unicode_file.py", line 49, in 
_do_single
    new_base = unicodedata.normalize("NFD", new_base)
TypeError: normalized() argument 2 must be unicode, 
not str

At this point,

filename is TESTFN_UNICODE is
u&#039;@test-\xe0\xf2&#039;

os.path.abspath(filename) is
&#039;C:\Code\python\PC\VC6\@test-\xe0\xf2&#039;

new_base is
&#039;@test-\xe0\xf2

So abspath() removed the "Unicodeness" of filename, 
and new_base is indeed not a Unicode string at this 
point.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-29 18:11

Message:
Logged In: YES 
user_id=31435

Nope, that can't help -- ntpath.py's _abspath doesn't exist 
on Win98SE (the "from nt import _getfullpathname" succeeds, 
so _abspath is never defined).  It's _getfullpathname() that's 
taking a Unicode input and returning a str output here.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 17:17

Message:
Logged In: YES 
user_id=21627

abspath(unicode) should return a Unicode path.

Does it help if _abspath (in ntpath.py) is changed to contain

            if not isabs(path):
                if isinstance(path, unicode): cwd = os.getcwdu()
                else: cwd = os.getcwd()
                path = join(cwd, path)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 20:33:46 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 20:33:51 2004
Subject: [ python-Bugs-922914 ] Installer misplaces tcl library
Message-ID: <E1B888Q-00088z-00@sc8-sf-web3.sourceforge.net>

Bugs item #922914, was opened at 2004-03-25 13:55
Message generated for change (Comment added) made by wswong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

Category: IDLE
Group: Python 2.3
>Status: Closed
>Resolution: Works For Me
Priority: 5
Submitted By: WS Wong (wswong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer misplaces tcl library

Initial Comment:
Python 2.3.3 on Windows 2000 Professional
-------------------------------------------
Could not start IDLE after installation of Python in 
C:\WSPrograms\Python23

Went to C:\WSPrograms\Python23\Lib\idlelib and from 
the command line typed
C:\WSPrograms\Python23\python idle.py

The following traceback obtained:

C:\WSPrograms\Python23
\Lib\idlelib>c:\wsprograms\python23\python idle.py
Traceback (most recent call last):
  File "idle.py", line 23, in ?
    idlelib.PyShell.main()
  File "C:\WSPrograms\Python23\lib\idlelib\PyShell.py", 
line 1269, in main
    root = Tk(className="Idle")
  File "C:\WSPrograms\Python23\lib\lib-tk\Tkinter.py", 
line 1564, in __init__
    self.tk = _tkinter.create(screenName, baseName, 
className)
_tkinter.TclError: Can&#039;t find a usable init.tcl in the 
following directories:
    {C:\WSPrograms\ruby167ms\tcl\lib\tcl8.3} 
{C:\WSPrograms\ruby167ms\tcl\lib\tc
l8.3} C:/WSPrograms/ruby167ms/tcl/lib/tcl8.4 
c:/wsprograms/python23/lib/tcl8.4 c
:/wsprograms/lib/tcl8.4 c:/lib/tcl8.4 
c:/wsprograms/library c:/library c:/../tcl
8.4.3/library

Looking at the directories that was installed, 
I found that the tcl8.4 was actually located in
C:\WSPrograms\Python23\tcl\tk8.4
which was never on the search path.

After I copied the tcl8.4 directory to  
C:\WSPrograms\Python23\Lib
and run the commands again, it worked. Not sure what 
other implications this will cause 
but at least I have IDLE running again. 


----------------------------------------------------------------------

>Comment By: WS Wong (wswong)
Date: 2004-03-30 09:33

Message:
Logged In: YES 
user_id=868242

Thanks. You are right. Deleting Ruby and getting rid of the tcl 
environment variable worked. Didn't think that would have 
affected the search path, but apparently it did.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-30 06:32

Message:
Logged In: YES 
user_id=31435

This is almost certainly Ruby's "fault" -- the Ruby Windows 
installer does set environment variables forcing every app to 
try using Ruby's version of Tcl/Tk.  Get rid of the Ruby 
envars, and IDLE should work fine.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 06:26

Message:
Logged In: YES 
user_id=21627

Have you set the TCL_LIBRARY environment variable? If so,
you should unset it. If you cannot unset it, you are on your
own - as a system administrator, by setting this variable,
you express the desire to use a different Tcl installation
(apparently the one that comes with Ruby), and then it is
your responsibility to make this setting work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 21:04:54 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 21:05:00 2004
Subject: [ python-Bugs-922914 ] Installer misplaces tcl library
Message-ID: <E1B88cY-0004ky-00@sc8-sf-web4.sourceforge.net>

Bugs item #922914, was opened at 2004-03-25 00:55
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

Category: IDLE
Group: Python 2.3
Status: Closed
Resolution: Works For Me
Priority: 5
Submitted By: WS Wong (wswong)
Assigned to: Nobody/Anonymous (nobody)
Summary: Installer misplaces tcl library

Initial Comment:
Python 2.3.3 on Windows 2000 Professional
-------------------------------------------
Could not start IDLE after installation of Python in 
C:\WSPrograms\Python23

Went to C:\WSPrograms\Python23\Lib\idlelib and from 
the command line typed
C:\WSPrograms\Python23\python idle.py

The following traceback obtained:

C:\WSPrograms\Python23
\Lib\idlelib>c:\wsprograms\python23\python idle.py
Traceback (most recent call last):
  File "idle.py", line 23, in ?
    idlelib.PyShell.main()
  File "C:\WSPrograms\Python23\lib\idlelib\PyShell.py", 
line 1269, in main
    root = Tk(className="Idle")
  File "C:\WSPrograms\Python23\lib\lib-tk\Tkinter.py", 
line 1564, in __init__
    self.tk = _tkinter.create(screenName, baseName, 
className)
_tkinter.TclError: Can&#039;t find a usable init.tcl in the 
following directories:
    {C:\WSPrograms\ruby167ms\tcl\lib\tcl8.3} 
{C:\WSPrograms\ruby167ms\tcl\lib\tc
l8.3} C:/WSPrograms/ruby167ms/tcl/lib/tcl8.4 
c:/wsprograms/python23/lib/tcl8.4 c
:/wsprograms/lib/tcl8.4 c:/lib/tcl8.4 
c:/wsprograms/library c:/library c:/../tcl
8.4.3/library

Looking at the directories that was installed, 
I found that the tcl8.4 was actually located in
C:\WSPrograms\Python23\tcl\tk8.4
which was never on the search path.

After I copied the tcl8.4 directory to  
C:\WSPrograms\Python23\Lib
and run the commands again, it worked. Not sure what 
other implications this will cause 
but at least I have IDLE running again. 


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-29 21:04

Message:
Logged In: YES 
user_id=31435

You didn't need to delete Ruby; just getting rid of the Tcl/Tk 
envars would have been enough.  I'm not sure why Ruby sets 
them to begin with (and you've noticed that Python doesn't 
set them).

----------------------------------------------------------------------

Comment By: WS Wong (wswong)
Date: 2004-03-29 20:33

Message:
Logged In: YES 
user_id=868242

Thanks. You are right. Deleting Ruby and getting rid of the tcl 
environment variable worked. Didn't think that would have 
affected the search path, but apparently it did.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-29 17:32

Message:
Logged In: YES 
user_id=31435

This is almost certainly Ruby's "fault" -- the Ruby Windows 
installer does set environment variables forcing every app to 
try using Ruby's version of Tcl/Tk.  Get rid of the Ruby 
envars, and IDLE should work fine.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 17:26

Message:
Logged In: YES 
user_id=21627

Have you set the TCL_LIBRARY environment variable? If so,
you should unset it. If you cannot unset it, you are on your
own - as a system administrator, by setting this variable,
you express the desire to use a different Tcl installation
(apparently the one that comes with Ruby), and then it is
your responsibility to make this setting work.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922914&group_id=5470

From noreply at sourceforge.net  Mon Mar 29 23:21:10 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Mon Mar 29 23:21:15 2004
Subject: [ python-Bugs-775353 ] IDLE: "Save As..." keybind (Ctrl+Shift+S)
	does not work
Message-ID: <E1B8AkQ-0002u7-00@sc8-sf-web1.sourceforge.net>

Bugs item #775353, was opened at 2003-07-21 18:54
Message generated for change (Comment added) made by kbk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470

Category: IDLE
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Matthew Shomphe (mshomphe)
Assigned to: Kurt B. Kaiser (kbk)
Summary: IDLE: "Save As..." keybind (Ctrl+Shift+S) does not work

Initial Comment:
Info:
-Python Version: Python 2.3c1 (#44, Jul 18 2003, 14:32:
36) [MSC v.1200 32 bit (Intel)] on win32
-IDLE Version:IDLE 1.0rc1  
-OS: Windows 2000 SP4
-Source: Installed from Installer on website (http://www.
python.org/ftp/python/2.3/Python-2.3c1.exe)

Behavior:

In the "File" dropdown menu in IDLE, the listed keybind for 
"Save As" is Ctrl+Shift+S.  This does not work.  When 
you hit Ctrl+Shift+S, nothing happens.

Additionally, the keybind for "Save Copy As...", 
Alt+Shift+S, does not work.

----------------------------------------------------------------------

>Comment By: Kurt B. Kaiser (kbk)
Date: 2004-03-29 23:21

Message:
Logged In: YES 
user_id=149084

Backported to release23-maint


----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-11-24 00:39

Message:
Logged In: YES 
user_id=149084

config-keys.def 1.20
configHandler.py 1.32
keybindingDialog.py 1.12

2.3 Backport Candidate

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-07-23 00:23

Message:
Logged In: YES 
user_id=149084

Duplicate of IDLEfork Bug 755647

None of the bindings with a Shift modifier
work because it is then necessary to use the upper
case keysym.  IDLE is using the lower case.

----------------------------------------------------------------------

Comment By: Matthew Shomphe (mshomphe)
Date: 2003-07-21 19:32

Message:
Logged In: YES 
user_id=716326

Checking through the code, it seems that the problem is in the 
file "configHandler.py".  The bindings are assigned with 
_lowercase_ letters:

'<<save-copy-of-window-as-file>>': ['<Alt-Shift-s>'], 
'<<save-window-as-file>>': ['<Alt-s>'],

So the keybindings will work when CAPSLOCK is active.  
Otherwise, it won't.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=775353&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 00:25:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 00:25:05 2004
Subject: [ python-Bugs-924703 ] test_unicode_file fails on Win98SE
Message-ID: <E1B8BkC-0003HE-00@sc8-sf-web3.sourceforge.net>

Bugs item #924703, was opened at 2004-03-28 03:48
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
>Assigned to: Martin v. L?wis (loewis)
Summary: test_unicode_file fails on Win98SE

Initial Comment:
In current CVS, test_unicode_file fails on Win98SE.  This 
has been going on for some time, actually.

ERROR: test_single_files (__main__.TestUnicodeFiles)

Traceback (most recent call last):
  File ".../lib/test/test_unicode_file.py", line 162, in 
test_single_files
    self._test_single(TESTFN_UNICODE)
  File ".../lib/test/test_unicode_file.py", line 136, in 
_test_single
    self._do_single(filename)
  File ".../lib/test/test_unicode_file.py", line 49, in 
_do_single
    new_base = unicodedata.normalize("NFD", new_base)
TypeError: normalized() argument 2 must be unicode, 
not str

At this point,

filename is TESTFN_UNICODE is
u&#039;@test-\xe0\xf2&#039;

os.path.abspath(filename) is
&#039;C:\Code\python\PC\VC6\@test-\xe0\xf2&#039;

new_base is
&#039;@test-\xe0\xf2

So abspath() removed the "Unicodeness" of filename, 
and new_base is indeed not a Unicode string at this 
point.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 07:25

Message:
Logged In: YES 
user_id=21627

I see. I'll look into changing _getfullpathname to return
Unicode output for Unicode input even if
unicode_file_names() is false.

However,  I do wonder what the purpose of _abspath then is:
On what system would it be used???

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-30 01:11

Message:
Logged In: YES 
user_id=31435

Nope, that can't help -- ntpath.py's _abspath doesn't exist 
on Win98SE (the "from nt import _getfullpathname" succeeds, 
so _abspath is never defined).  It's _getfullpathname() that's 
taking a Unicode input and returning a str output here.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:17

Message:
Logged In: YES 
user_id=21627

abspath(unicode) should return a Unicode path.

Does it help if _abspath (in ntpath.py) is changed to contain

            if not isabs(path):
                if isinstance(path, unicode): cwd = os.getcwdu()
                else: cwd = os.getcwd()
                path = join(cwd, path)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 00:44:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 00:44:41 2004
Subject: [ python-Bugs-924703 ] test_unicode_file fails on Win98SE
Message-ID: <E1B8C37-0004tB-00@sc8-sf-web2.sourceforge.net>

Bugs item #924703, was opened at 2004-03-27 20:48
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

Category: Unicode
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Martin v. L?wis (loewis)
Summary: test_unicode_file fails on Win98SE

Initial Comment:
In current CVS, test_unicode_file fails on Win98SE.  This 
has been going on for some time, actually.

ERROR: test_single_files (__main__.TestUnicodeFiles)

Traceback (most recent call last):
  File ".../lib/test/test_unicode_file.py", line 162, in 
test_single_files
    self._test_single(TESTFN_UNICODE)
  File ".../lib/test/test_unicode_file.py", line 136, in 
_test_single
    self._do_single(filename)
  File ".../lib/test/test_unicode_file.py", line 49, in 
_do_single
    new_base = unicodedata.normalize("NFD", new_base)
TypeError: normalized() argument 2 must be unicode, 
not str

At this point,

filename is TESTFN_UNICODE is
u&#039;@test-\xe0\xf2&#039;

os.path.abspath(filename) is
&#039;C:\Code\python\PC\VC6\@test-\xe0\xf2&#039;

new_base is
&#039;@test-\xe0\xf2

So abspath() removed the "Unicodeness" of filename, 
and new_base is indeed not a Unicode string at this 
point.

----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-30 00:44

Message:
Logged In: YES 
user_id=31435

Just a guess:  the os.path functions are generally just string 
manipulation, and on Windows I sometimes import 
posixpath.py directly to do Unixish path manipulations.  So it's 
conceivable that someone (not me) on a non-Windows box 
imports ntpath directly to manipulate Windows paths.

In fact, I see that Fredrik's "Python Standard Library" book 
explicitly mentions this use case for importing ntpath directly.  
So maybe he actually did it -- once <wink>.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:25

Message:
Logged In: YES 
user_id=21627

I see. I'll look into changing _getfullpathname to return
Unicode output for Unicode input even if
unicode_file_names() is false.

However,  I do wonder what the purpose of _abspath then is:
On what system would it be used???

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-03-29 18:11

Message:
Logged In: YES 
user_id=31435

Nope, that can't help -- ntpath.py's _abspath doesn't exist 
on Win98SE (the "from nt import _getfullpathname" succeeds, 
so _abspath is never defined).  It's _getfullpathname() that's 
taking a Unicode input and returning a str output here.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 17:17

Message:
Logged In: YES 
user_id=21627

abspath(unicode) should return a Unicode path.

Does it help if _abspath (in ntpath.py) is changed to contain

            if not isabs(path):
                if isinstance(path, unicode): cwd = os.getcwdu()
                else: cwd = os.getcwd()
                path = join(cwd, path)



----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924703&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 02:31:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 02:31:18 2004
Subject: [ python-Bugs-908936 ] rexec.r_eval() does not work like eval()
Message-ID: <E1B8DiG-0003Ce-00@sc8-sf-web2.sourceforge.net>

Bugs item #908936, was opened at 2004-03-03 10:58
Message generated for change (Comment added) made by pfremy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908936&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec.r_eval() does not work like eval()

Initial Comment:
I want to use the eval() function of python as simple
ultra-restricted expression evaluator. So, when
executing r_eval(), I want to pass a dictionnary of the
local and global variables, just like it is possible
with eval(). However, r_eval() does not allow it.

----------------------------------------------------------------------

>Comment By: Philippe Fremy (pfremy)
Date: 2004-03-30 09:31

Message:
Logged In: YES 
user_id=233844

http://www.python.org/doc/2.3.3/lib/module-rexec.html 
reads: "17.1 rexec -- Restricted execution framework" 
 
so it looks like the module does provide a "Restricted execution 
framework", no ? 
 
Now, I assume that you mean that the module has been marked 
obsolete in the most recent of python (which I am not using). 
 
Is there any replacement available ? 
 
 
 
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:34

Message:
Logged In: YES 
user_id=21627

The rexec module does not provide restricted execution, so
you should not be using it in the first place.

Closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908936&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 10:27:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 10:28:41 2004
Subject: [ python-Bugs-926075 ] re.sub on u'' gives NON-unicode ''
Message-ID: <E1B8L9b-0002dC-00@sc8-sf-web3.sourceforge.net>

Bugs item #926075, was opened at 2004-03-30 17:27
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926075&group_id=5470

Category: Regular Expressions
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Alex Martelli (aleax)
Assigned to: Fredrik Lundh (effbot)
Summary: re.sub on u'' gives NON-unicode ''

Initial Comment:
>>> import re 
>>> re.sub(u&#039;.&#039;, u&#039;&#039;, u&#039;&#039;) 
&#039;&#039; 
 
This holds for any RE that doesn&#039;t match the empty string. 
 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926075&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 10:28:03 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 11:02:57 2004
Subject: [ python-Bugs-925537 ] dir(mod) OK or use vars(mod).keys()?
Message-ID: <E1B8L9n-0002vK-00@sc8-sf-web4.sourceforge.net>

Bugs item #925537, was opened at 2004-03-29 14:28
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 4
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

>Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-30 10:28

Message:
Logged In: YES 
user_id=764593

The ideal fix would be in documentation (and therefore policy).

I want to do something like

import_list = [x for x in dir(other_mod) if wanted(x)]

It happens to work today on my machine, but the 
documentation says that dir(x) may return different results in 
different releases.  This means that I can't safely use it in 
released code.

If there were some indication that dir(module) would continue 
to return the same names as vars(module).keys(), then I could 
use it.  If the differences were only in variables not intended 
for export, that would also be OK -- but dir does not current 
promise this.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 17:11

Message:
Logged In: YES 
user_id=21627

I fail to see a bug. Which specific usage of dir() does not
work as intended?

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:58

Message:
Logged In: YES 
user_id=764593

Correction:  "The output of dir (module) will always include ..."

The most common use is figuring out what to do with (import 
from) a module.

Symmetry suggests the same for a no-argument call or a class 
or type object, but object instances do not use their __dict__ 
for their attributes; the results are already different there.

-jJ


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:39

Message:
Logged In: YES 
user_id=764593

If there concern is over attributes that are "public" but don't 
exist until called, then most uses of dir and vars are already 
broken.  An alternative reasonable promise would be

The output of dir(obj) will always include all (public?, 
non-magical?) names in vars(obj).keys().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925537&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 12:14:37 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 12:14:54 2004
Subject: [ python-Bugs-923576 ] Incorrect __name__ assignment
Message-ID: <E1B8Mov-0004vh-00@sc8-sf-web4.sourceforge.net>

Bugs item #923576, was opened at 2004-03-25 19:43
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: El cepi (elcepi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect __name__ assignment

Initial Comment:
When you use PythonLauncher or PythonIDE the value of 
__name__ is incorrectly assigned.

For example, in the attached file the output is "The module 
has been load" when the module is fun in PythonIDE.

With this you can not disciminate between the code you 
should run when you load the module and when you try to 
run it.



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-30 12:14

Message:
Logged In: YES 
user_id=593130

When making a bug report, please include at least the Python 
version.  The system you are running on is sometimes 
essential info also.

I am not familiar with either PythonLauncher or PythonIDE.  
Just PyWin and Idle.  If they are third-party items not part of 
the distribution, then this report should go to their authors.

'When you use' is also somewhat vague.  Saying what 
command line option or menu entry or buttom you used to 
run/load might also get a better answer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 12:50:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 15:02:49 2004
Subject: [ python-Bugs-925628 ] help does not help with imported objects
Message-ID: <E1B8NNg-00042E-00@sc8-sf-web1.sourceforge.net>

Bugs item #925628, was opened at 2004-03-29 16:34
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
Resolution: None
Priority: 2
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: help does not help with imported objects

Initial Comment:
help(re) just says it is a wrapper for sre.  To get actually 
help, you need to explicitly import sre as well.

re.__doc__ = re.__doc__ + sre.__doc__ helps, but still 
does not list information on classes or exported functions. 

Specific requests, such as 

help(re.subn) 

do work;  it is only the module-level help that is lacking 
when a module reexports imported objects.

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-30 12:50

Message:
Logged In: YES 
user_id=593130

I am not sure a see a bug here (as opposed to enhancement 
request).  re.__all__ and dir(re) list exported names.  help
(re.engine) gets the multipage doc from the wrapped engine 
without importing it.  The re doc string could be enhanced by 
adding a FOR MORE section that says so.

Automatically adding sre would have been wrong when there 
were multiple engines in the distribution.  Not sure if are or 
will be in 2.4, but there could be in the future again.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925628&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 11:57:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 15:03:24 2004
Subject: [ python-Bugs-922690 ] package manager page outdated link
Message-ID: <E1B8MYB-0007F1-00@sc8-sf-web1.sourceforge.net>

Bugs item #922690, was opened at 2004-03-24 15:07
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Russell Owen (reowen)
Assigned to: Nobody/Anonymous (nobody)
Summary: package manager page outdated link

Initial Comment:
The page http://www.python.org/packman/ has outdated links to Bob Ippolito&#039;s page. The correct link appears to be http://undefined.org/python/ (which includes links to various versions of the packages and to descriptions of the same).

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-30 11:57

Message:
Logged In: YES 
user_id=593130

To supplement the summary:  the two links (xml and html) on 
the bottom of the packman page work but they are specific 
to (an older? verseion) the pimp package.  The higher link 
suggested as a substitue lists other packages, including some 
that appear to have been extracted from pimp.  Since the 
current page references aeve 0.0.3 while the suggested link 
references aeve 0.0.4, the suggest change seems proper.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=922690&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 14:10:43 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 15:03:51 2004
Subject: [ python-Bugs-876278 ] Unbounded recursion in modulefinder
Message-ID: <E1B8OdH-0007Rt-00@sc8-sf-web4.sourceforge.net>

Bugs item #876278, was opened at 2004-01-13 19:46
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Heller (theller)
Assigned to: Just van Rossum (jvr)
Summary: Unbounded recursion in modulefinder

Initial Comment:
modulefinder goes into unbounded recursion when a
module named &#039;path.py&#039;, containing &#039;import os&#039;, is on
sys.path.

Last part of the traceback:
  File "c:\python23\lib\modulefinder.py", line 255, in
import_module
    m = self.load_module(fqname, fp, pathname, stuff)
  File "c:\python23\lib\modulefinder.py", line 285, in
load_module
    self.scan_code(co, m)
  File "c:\python23\lib\modulefinder.py", line 342, in
scan_code
    self._safe_import_hook(name, m, fromlist)
  File "c:\python23\lib\modulefinder.py", line 300, in
_safe_import_hook
    self.import_hook(name, caller)
  File "c:\python23\lib\modulefinder.py", line 124, in
import_hook
    q, tail = self.find_head_package(parent, name)
  File "c:\python23\lib\modulefinder.py", line 166, in
find_head_package
    q = self.import_module(head, qname, parent)
  File "c:\python23\lib\modulefinder.py", line 237, in
import_module
    self.msgin(3, "import_module", partname, fqname,
parent)
RuntimeError: maximum recursion depth exceeded

Running modulefinder with the &#039;-x os.path&#039; command line
option prevents the recursion.

This is not really a contrived situation, there&#039;s a
possibly useful path.py module from Jason Orendorff at
<http://www.jorendorff.com/articles/python/path>


----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-03-30 21:10

Message:
Logged In: YES 
user_id=11105

I think I have found something, but I still have to check if
this cures the original problem.

Imagine an (possibly empty) module foo.py.  Without this
patch, modulefinder would even find 'import foo.foo.foo'
modules.

The assert in the second hunk is commented out, although I
think it should be correct.

Just, any comments?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-03-25 22:09

Message:
Logged In: YES 
user_id=11105

It has something to do with os.path.  Adding 'os.path' to
the excludes list, the problem does not appear.

Adding print statements it seems that mf is looking for 
os.os.os.os.os.......something, it seems that it recurses
without noting that something failed.

If I had to fix this myself, I probably had to first step
through these imports with the C debugger, and then through mf.

----------------------------------------------------------------------

Comment By: Just van Rossum (jvr)
Date: 2004-03-25 21:53

Message:
Logged In: YES 
user_id=92689

Hm, not really. Do you have any idea what's causing it?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-03-25 21:06

Message:
Logged In: YES 
user_id=11105

<ping> Just, do you have time to look into this?

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-01-28 21:36

Message:
Logged In: YES 
user_id=11105

Just, do you have time to look into this?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=876278&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 14:46:55 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 16:02:42 2004
Subject: [ python-Bugs-924333 ] Build issues (lib path) on linux2-x86_64
Message-ID: <E1B8PCJ-0002RY-00@sc8-sf-web4.sourceforge.net>

Bugs item #924333, was opened at 2004-03-26 23:12
Message generated for change (Comment added) made by petrilli
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470

Category: Build
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Christopher Petrilli (petrilli)
Assigned to: Nobody/Anonymous (nobody)
Summary: Build issues (lib path) on linux2-x86_64

Initial Comment:
The current CVS HEAD won&#039;t build "out of the box" on a
Fedora x86_64 box, nor on any other Linux AMD64
platform.  This is due to the fact that the libraries
for many things are not in /usr/lib, but /usr/lib64,
and the current &#039;autoconf&#039; script, as well as the
current setup.py do not look there.  When added, they
detect, build.

----------------------------------------------------------------------

>Comment By: Christopher Petrilli (petrilli)
Date: 2004-03-30 14:46

Message:
Logged In: YES 
user_id=38410

See patch #926209

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 17:19

Message:
Logged In: YES 
user_id=21627

Can you submit a patch?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=924333&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 16:06:14 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 16:06:57 2004
Subject: [ python-Bugs-908936 ] rexec.r_eval() does not work like eval()
Message-ID: <E1B8QR4-0003MG-00@sc8-sf-web2.sourceforge.net>

Bugs item #908936, was opened at 2004-03-03 10:58
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908936&group_id=5470

Category: Python Library
Group: Python 2.2.2
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Philippe Fremy (pfremy)
Assigned to: Nobody/Anonymous (nobody)
Summary: rexec.r_eval() does not work like eval()

Initial Comment:
I want to use the eval() function of python as simple
ultra-restricted expression evaluator. So, when
executing r_eval(), I want to pass a dictionnary of the
local and global variables, just like it is possible
with eval(). However, r_eval() does not allow it.

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 23:06

Message:
Logged In: YES 
user_id=21627

No, not marked obsolete: "Changed in version 2.3: Disabled
module."

"While the rexec module is designed to perform as described
below, it does have a few known vulnerabilities which could
be exploited by carefully written code. "

Even in 2.2, when it still was enabled, it did not actually
do what it was designed to do, and it is not possible to fix
it. Also, there is no replacement available.

----------------------------------------------------------------------

Comment By: Philippe Fremy (pfremy)
Date: 2004-03-30 09:31

Message:
Logged In: YES 
user_id=233844

http://www.python.org/doc/2.3.3/lib/module-rexec.html 
reads: "17.1 rexec -- Restricted execution framework" 
 
so it looks like the module does provide a "Restricted execution 
framework", no ? 
 
Now, I assume that you mean that the module has been marked 
obsolete in the most recent of python (which I am not using). 
 
Is there any replacement available ? 
 
 
 
 

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:34

Message:
Logged In: YES 
user_id=21627

The rexec module does not provide restricted execution, so
you should not be using it in the first place.

Closing this as "won't fix".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=908936&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 16:09:24 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 17:02:31 2004
Subject: [ python-Feature Requests-925537 ] dir(mod) OK or use
	vars(mod).keys()?
Message-ID: <E1B8QU8-0003dm-00@sc8-sf-web2.sourceforge.net>

Feature Requests item #925537, was opened at 2004-03-29 21:28
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470

>Category: None
>Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 23:09

Message:
Logged In: YES 
user_id=21627

Ok, marking it as a feature request then: Explicitly
pointing out that behaviour may change in the future has
usually been done because change in behaviour is
anticipated, or has happened in the past. Giving stronger
guarantees about future versions a feature that is currently
not provided.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-30 17:28

Message:
Logged In: YES 
user_id=764593

The ideal fix would be in documentation (and therefore policy).

I want to do something like

import_list = [x for x in dir(other_mod) if wanted(x)]

It happens to work today on my machine, but the 
documentation says that dir(x) may return different results in 
different releases.  This means that I can't safely use it in 
released code.

If there were some indication that dir(module) would continue 
to return the same names as vars(module).keys(), then I could 
use it.  If the differences were only in variables not intended 
for export, that would also be OK -- but dir does not current 
promise this.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 00:11

Message:
Logged In: YES 
user_id=21627

I fail to see a bug. Which specific usage of dir() does not
work as intended?

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 21:58

Message:
Logged In: YES 
user_id=764593

Correction:  "The output of dir (module) will always include ..."

The most common use is figuring out what to do with (import 
from) a module.

Symmetry suggests the same for a no-argument call or a class 
or type object, but object instances do not use their __dict__ 
for their attributes; the results are already different there.

-jJ


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 21:39

Message:
Logged In: YES 
user_id=764593

If there concern is over attributes that are "public" but don't 
exist until called, then most uses of dir and vars are already 
broken.  An alternative reasonable promise would be

The output of dir(obj) will always include all (public?, 
non-magical?) names in vars(obj).keys().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 19:22:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 19:22:37 2004
Subject: [ python-Bugs-926369 ] pdb sometimes sets breakpoints in the wrong
	location
Message-ID: <E1B8TV3-0003em-00@sc8-sf-web1.sourceforge.net>

Bugs item #926369, was opened at 2004-03-30 16:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926369&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb sometimes sets breakpoints in the wrong location

Initial Comment:

If one attempts to set a breakpoint in one line function:
e.g for this code:

def f(x): return x*x

z=23

pdb silently sets a breakpoint on the line right after
the function definition (i.e. outside the function body!):

../python pdb.py.v1.66 pdb_one_line_func 
> <string>(1)?()
(Pdb) b f
Breakpoint 1   /src/Lib/pdb_one_line_func:3
(Pdb) c
> /src/Lib/pdb_one_line_func(3)?()
-> z=23

It&#039;s probably acceptable to limit pdb breakpoints to
multiline functions, but i don&#039;t think, it&#039;s acceptable
to create wrong breakpoints.

Note: that anyone attempting to fix this should also
take a look at bug 875404 (global statment causes
breakpoints..), as both bugs are caused by
pdb.checkline() logic


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926369&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 19:51:18 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 19:51:24 2004
Subject: [ python-Feature Requests-925537 ] dir(mod) OK or use
	vars(mod).keys()?
Message-ID: <E1B8Tws-00058W-00@sc8-sf-web1.sourceforge.net>

Feature Requests item #925537, was opened at 2004-03-29 14:28
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 4
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Nobody/Anonymous (nobody)
Summary: dir(mod) OK or use vars(mod).keys()?

Initial Comment:
The documentation on dir() notes that its behavior may 
change across releases.

Several library modules use dir(x) in ways that might 
break if it changed too much. 

Should these be changed to use vars(obj).keys() (and 
possibly sort()), or should the note on dir() be removed?

My own preference would just be to provide some 
guidance, such as "The output of dir() will always include 
all public variables which do not have a magic meaning."

I realize that the standard library itself could be updated 
if dir() changes in an uncomfortable way.  My real 
concern is which spelling to use in my own code.  The 
library examples suggest a simpler (and clearer) dir(), but 
the documentation still says otherwise.

A quick search for modules using dir() showed possible 
trouble in at least cgitb, cmd, FCNTL, inspect, optparse, 
os, pickle, rlcompleter, SimpleXMLRPCServer, TERMIOS, 
tokenize, unittest, and urllib2.


----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2004-03-30 19:51

Message:
Logged In: YES 
user_id=31435

Ya, dir() was *intended* to be a convenience for use at the 
interactive shell.  I expect the only promise Guido wants to 
make about it is that it will show him stuff he finds interesting 
as Python changes <0.7 wink>.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-30 16:09

Message:
Logged In: YES 
user_id=21627

Ok, marking it as a feature request then: Explicitly
pointing out that behaviour may change in the future has
usually been done because change in behaviour is
anticipated, or has happened in the past. Giving stronger
guarantees about future versions a feature that is currently
not provided.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-30 10:28

Message:
Logged In: YES 
user_id=764593

The ideal fix would be in documentation (and therefore policy).

I want to do something like

import_list = [x for x in dir(other_mod) if wanted(x)]

It happens to work today on my machine, but the 
documentation says that dir(x) may return different results in 
different releases.  This means that I can't safely use it in 
released code.

If there were some indication that dir(module) would continue 
to return the same names as vars(module).keys(), then I could 
use it.  If the differences were only in variables not intended 
for export, that would also be OK -- but dir does not current 
promise this.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 17:11

Message:
Logged In: YES 
user_id=21627

I fail to see a bug. Which specific usage of dir() does not
work as intended?

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:58

Message:
Logged In: YES 
user_id=764593

Correction:  "The output of dir (module) will always include ..."

The most common use is figuring out what to do with (import 
from) a module.

Symmetry suggests the same for a no-argument call or a class 
or type object, but object instances do not use their __dict__ 
for their attributes; the results are already different there.

-jJ


----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-03-29 14:39

Message:
Logged In: YES 
user_id=764593

If there concern is over attributes that are "public" but don't 
exist until called, then most uses of dir and vars are already 
broken.  An alternative reasonable promise would be

The output of dir(obj) will always include all (public?, 
non-magical?) names in vars(obj).keys().


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=925537&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 21:03:04 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 21:03:18 2004
Subject: [ python-Bugs-796042 ] sdist ignores scripts argument in setup
Message-ID: <E1B8V4K-0000Ml-00@sc8-sf-web1.sourceforge.net>

Bugs item #796042, was opened at 2003-08-27 11:09
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796042&group_id=5470

Category: Distutils
Group: Python 2.3
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Anna Ravenscroft (annarave)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sdist ignores scripts argument in setup

Initial Comment:
When writing the setup script for a distribution, section 3.4 explains:

3.4 Installing Scripts

So far we have been dealing with pure and non-pure Python modules, which are usually not run by themselves but imported by scripts.

Scripts are files containing Python source code, intended to be started from the command line. Scripts don&#039;t require Distutils to do anything very complicated. The only clever feature is that if the first line of the script starts with #! and contains the word ``python&#039;&#039;, the Distutils will adjust the first line to refer to the current interpreter location. 

The scripts option simply is a list of files to be handled in this way. From the PyXML setup script: 


setup (...
       scripts = [&#039;scripts/xmlproc_parse&#039;, &#039;scripts/xmlproc_val&#039;]
      )

Unfortunately, this doesn&#039;t work with sdist unless you ALSO create a manifest.in file. Otherwise, it silently ignores the scripts listed in setup. bdist works just fine, so it&#039;s apparently something wrong in sdist.

Please fix this. Thank you.

Anna Ravenscroft

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-30 21:03

Message:
Logged In: YES 
user_id=3066

Added note about inclusion of scripts in Doc/dist/dist.tex
revision 1.73.  This should be back-ported along with the
actual fix.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-25 17:17

Message:
Logged In: YES 
user_id=3066

This is fixed on the trunk as
Lib/distutils/command/build_scripts.py 1.22 and sdist.py 1.57.

I'm not entirely sure this should be backported for Python
2.3.x, but it probably should be.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796042&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 22:48:42 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 22:48:46 2004
Subject: [ python-Bugs-926423 ] socket timeouts + Ctrl-C don't play nice
Message-ID: <E1B8WiY-0005hO-00@sc8-sf-web1.sourceforge.net>

Bugs item #926423, was opened at 2004-03-30 22:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: David M. Cooke (dmcooke)
Assigned to: Nobody/Anonymous (nobody)
Summary: socket timeouts + Ctrl-C don't play nice

Initial Comment:
As reported by Koen Vossen in c.l.py, when a timeout is
set on a socket, a try...except block around a
socket.recv (or socket.recvfrom) won&#039;t properly catch a
keyboard interrupt (by Ctrl-C). I&#039;ve attached example
code that shows this. Run it and press Ctrl-C before
the socket times out. This is for Python 2.3 under Linux.

I believe the problem boils down to this sequence of
events inside of the socketmodule.c::sock_recv function
(and similiar for sock_recvfrom):

1) internal_select is called, which calls select, which
waits for a timeout. A SIGINT is received (and caught
by the default handler). The select returns with errno
set to EINTR. internal_select returns with timeout==1

2) without checking errno, recv() is called. Since
there is actually no data, it returns an error, with
errno set to EAGAIN.

3) the default socket error handler is called, which
calls PyErr_SetFromErrno(). Since errno != EINTR (it&#039;s
now EAGAIN), a socket_error exception is thrown.

4) the innermost try..except block is triggered.

5) next loop around in eval_frame, notices that SIGINT
was caught, and so KeyboardInterrupt is raised, exiting
innermost try..except clause

6) KeyboardInterrupt is caught by the outermost
try..except block. 

I was going to make a patch, but I couldn&#039;t figure out
the best way to fix this in general :-( There are
likely similiar problems with everywhere
internal_select is used. The quick fix is to check
errno before calling recv()


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926423&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 23:05:00 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 23:05:03 2004
Subject: [ python-Bugs-926427 ] OEM codepage chars in mbcs filenames are
	misinterpreted
Message-ID: <E1B8WyK-0006RR-00@sc8-sf-web1.sourceforge.net>

Bugs item #926427, was opened at 2004-03-30 21:04
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926427&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: OEM codepage chars in mbcs filenames are misinterpreted

Initial Comment:
My system: Windows XP, English - US locale, Python 
2.3.3

I believe the bug I am reporting here is this:

On Windows XP, when using os.listdir() with a non-
Unicode argument, characters that are not in the 
default locale&#039;s encoding (e.g. Greek capital letter 
Sigma, (U+03A3), is not in windows-1252), but that are 
in the default OEM code page (e.g. Sigma is in cp437), 
get mapped to ASCII characters other than &#039;?&#039;.

For example, things seem to work in a predictable way 
when I put windows-1252 characters into filenames (I 
do this in Explorer and then I see what os.listdir
(r&#039;C:\path\to\the\dir&#039;) returns):

? (U+2014) becomes \x97
? (U+2022) becomes \x95
? (U+00E9) becomes \xe9

But things are much less predictable when I use 
characters from outside this range. I thought I&#039;d try 
some Greek characters first. Some of them (the ones 
that happen to be in cp437, interestingly enough) come 
back as random ASCII letters:

&#920; (U+0398) becomes "T"
&#931; (U+03A3) becomes "S"
&#934; (U+03A6) becomes "F"

Greek letters that are not in cp437 come back as 
question marks, as expected (I guess):
&#932; (U+03A4) becomes "?"
&#933; (U+03A5) becomes "?"

...as do some Hebrew letters and Japanese hiragana:
&#1488; (U+05D0) becomes "?"
&#1492; (U+05D4) becomes "?"
&#1505; (U+05E1) becomes "?"
&#12354; (U+305F) becomes "?"
&#12358; (U+3046) becomes "?"
&#12383; (U+3042) becomes "?"

I don&#039;t know if this is something that anyone cares 
about, since the filenames are useless anyway, but it 
does seem to be unintended behavior.

(And before you ask, it&#039;s just a theoretical exercise; I 
have no urgent need to use os.listdir with non-Unicode 
directory names on Windows.)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926427&group_id=5470

From noreply at sourceforge.net  Tue Mar 30 23:45:02 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Tue Mar 30 23:45:08 2004
Subject: [ python-Bugs-918368 ] urllib doesn't correct server returned urls
Message-ID: <E1B8Xb4-0005GY-00@sc8-sf-web2.sourceforge.net>

Bugs item #918368, was opened at 2004-03-17 15:41
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918368&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Probin (robzed)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib doesn't correct server returned urls

Initial Comment:
On a URL request where the server returns a URL with spaces in, 
urllib doesn&#039;t correct it before requesting the new page.

I think this is technically a server error, however, it does work 
from web browsers (Mozilla, Safari) but not from Python urllib.

I would suggest that when urllib is following "moved temporarily" 
links (or similar) from a server it translates spaces to %20.

See example program file for more including detailed server/client 
transactions text.




----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-30 21:45

Message:
Logged In: YES 
user_id=371366

I agree that it is a server error to put something that doesn't 
meet the syntactic definition of a URI in the Location header 
of a response. I don't see any harm in correcting obvious 
errors, though, in the interest of usability.

As for your proposed fix, instead of just correcting spaces, I 
would do

    newurl = quote(newurl, safe="/:=&?#+!$,;'@()*[]")

quote() is a urllib function that does percent-encoding. It is 
way out of date and does poorly with Unicode strings, but if 
called with the above arguments, it should safely clean up 
most mistakes. The set of additional "safe" characters I am 
passing in is the complete set of "reserved" characters 
according to the latest draft of RFC 2396bis; these are 
characters that definitely do or might possibly have special 
meaning in a URL and thus should not be percent-encoded 
blindly.

I am currently working on a urllib.quote() replacement for 
4Suite's Ft.Lib.Uri library, and will then see about getting the 
improvements folded back into urllib.

----------------------------------------------------------------------

Comment By: Rob Probin (robzed)
Date: 2004-03-18 15:38

Message:
Logged In: YES 
user_id=1000470

I've tested a change to "redirect_internal(self, url, fp, errcode, errmsg, 
headers, data)" in "urllib.py" that adds a single line newurl = 
newurl.replace(" ","%20") after the basejoin() function call that appears 
to fix the problem.

This information is placed in the public domain.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918368&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 00:44:33 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 00:44:37 2004
Subject: [ python-Bugs-918368 ] urllib doesn't correct server returned urls
Message-ID: <E1B8YWf-00038F-00@sc8-sf-web1.sourceforge.net>

Bugs item #918368, was opened at 2004-03-17 15:41
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918368&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rob Probin (robzed)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib doesn't correct server returned urls

Initial Comment:
On a URL request where the server returns a URL with spaces in, 
urllib doesn&#039;t correct it before requesting the new page.

I think this is technically a server error, however, it does work 
from web browsers (Mozilla, Safari) but not from Python urllib.

I would suggest that when urllib is following "moved temporarily" 
links (or similar) from a server it translates spaces to %20.

See example program file for more including detailed server/client 
transactions text.




----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-30 22:44

Message:
Logged In: YES 
user_id=371366

In my previous example, I forgot to add a tilde to the "safe" 
characters. Tilde is an "unreserved" character, a class of 
characters allowed in a URI but for which percent-encoding is 
discouraged.

    newurl = quote(newurl, safe="/:=&?~#+!$,;'@()*[]")

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-30 21:45

Message:
Logged In: YES 
user_id=371366

I agree that it is a server error to put something that doesn't 
meet the syntactic definition of a URI in the Location header 
of a response. I don't see any harm in correcting obvious 
errors, though, in the interest of usability.

As for your proposed fix, instead of just correcting spaces, I 
would do

    newurl = quote(newurl, safe="/:=&?#+!$,;'@()*[]")

quote() is a urllib function that does percent-encoding. It is 
way out of date and does poorly with Unicode strings, but if 
called with the above arguments, it should safely clean up 
most mistakes. The set of additional "safe" characters I am 
passing in is the complete set of "reserved" characters 
according to the latest draft of RFC 2396bis; these are 
characters that definitely do or might possibly have special 
meaning in a URL and thus should not be percent-encoded 
blindly.

I am currently working on a urllib.quote() replacement for 
4Suite's Ft.Lib.Uri library, and will then see about getting the 
improvements folded back into urllib.

----------------------------------------------------------------------

Comment By: Rob Probin (robzed)
Date: 2004-03-18 15:38

Message:
Logged In: YES 
user_id=1000470

I've tested a change to "redirect_internal(self, url, fp, errcode, errmsg, 
headers, data)" in "urllib.py" that adds a single line newurl = 
newurl.replace(" ","%20") after the basejoin() function call that appears 
to fix the problem.

This information is placed in the public domain.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=918368&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 01:01:58 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 01:02:03 2004
Subject: [ python-Bugs-833405 ] urllib.urlencode doesn't work for output
	from cgi.parse_qs
Message-ID: <E1B8YnW-0000nj-00@sc8-sf-web2.sourceforge.net>

Bugs item #833405, was opened at 2003-10-30 15:39
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833405&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Myers Carpenter (myers_carpenter)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlencode doesn't work for output from cgi.parse_qs

Initial Comment:
>>>
urllib.urlencode(cgi.parse_qsl(&#039;ext=.jpg&outquality=56&#039;))
&#039;ext=.jpg&outquality=56&#039;
>>>
urllib.urlencode(cgi.parse_qs(&#039;ext=.jpg&outquality=56&#039;))
&#039;ext=%5B%27.jpg%27%5D&outquality=%5B%2756%27%5D&#039;

"%5B%27" = "[&#039;"

 

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-30 23:01

Message:
Logged In: YES 
user_id=371366

As per the urlencode() API documentation, you are passing in 
sequences, so you need to set the doseq flag.

>>> urllib.urlencode(cgi.parse_qs
('ext=.jpg&outquality=56'),doseq=1)
'ext=.jpg&outquality=56'

I recommend that this bug report be closed as Invalid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833405&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 02:40:20 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 02:40:40 2004
Subject: [ python-Bugs-926501 ] (ref-manual) position docstrings in source
	not documented
Message-ID: <E1B8aKi-0003bV-00@sc8-sf-web4.sourceforge.net>

Bugs item #926501, was opened at 2004-03-31 07:40
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926501&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: a.hofkamp (axhlkhb)
Assigned to: Nobody/Anonymous (nobody)
Summary: (ref-manual) position docstrings in source not documented

Initial Comment:
A colleaque of mine could not find anything about doc
strings in the Python language ref manual. I checked
his claim and found that there is indeed very little
documented about docstrings in it.

The current (online) ref manual has a number of __doc__
entries in the index, they all point to structure
descriptions of internal objects (like a function object).
A &#039;documentation string&#039; entry points to the docstring
of a code object.

What is not documented is where docstrings come from,
i.e. where in my program should I put it to make it
appear as __doc__ attribute.
The grammar only discusses Python statements.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926501&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 03:00:27 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 03:00:53 2004
Subject: [ python-Bugs-837228 ] Python.h must be included first
Message-ID: <E1B8aeB-00050v-00@sc8-sf-web4.sourceforge.net>

Bugs item #837228, was opened at 2003-11-06 09:59
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837228&group_id=5470

Category: Documentation
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 7
Submitted By: Fred L. Drake, Jr. (fdrake)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Python.h must be included first

Initial Comment:
Both the API reference and the Extending and Embedding
doc need to scream louder about the requirement to
#include Python.h first.

Should be fixed for all maintained versions.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-31 03:00

Message:
Logged In: YES 
user_id=3066

Fixed for Python 2.3.4 and 2.4:

Doc/api/intro.tex 1.3.24.3, 1.6
Doc/ext/extending.tex 1.24.10.3, 1.27


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=837228&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 05:28:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 05:28:18 2004
Subject: [ python-Bugs-926427 ] OEM codepage chars in mbcs filenames can be
	misinterpreted
Message-ID: <E1B8cx6-0006dJ-00@sc8-sf-web1.sourceforge.net>

Bugs item #926427, was opened at 2004-03-30 21:04
Message generated for change (Comment added) made by mike_j_brown
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926427&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
>Summary: OEM codepage chars in mbcs filenames can be misinterpreted

Initial Comment:
My system: Windows XP, English - US locale, Python 
2.3.3

I believe the bug I am reporting here is this:

On Windows XP, when using os.listdir() with a non-
Unicode argument, characters that are not in the 
default locale&#039;s encoding (e.g. Greek capital letter 
Sigma, (U+03A3), is not in windows-1252), but that are 
in the default OEM code page (e.g. Sigma is in cp437), 
get mapped to ASCII characters other than &#039;?&#039;.

For example, things seem to work in a predictable way 
when I put windows-1252 characters into filenames (I 
do this in Explorer and then I see what os.listdir
(r&#039;C:\path\to\the\dir&#039;) returns):

? (U+2014) becomes \x97
? (U+2022) becomes \x95
? (U+00E9) becomes \xe9

But things are much less predictable when I use 
characters from outside this range. I thought I&#039;d try 
some Greek characters first. Some of them (the ones 
that happen to be in cp437, interestingly enough) come 
back as random ASCII letters:

&#920; (U+0398) becomes "T"
&#931; (U+03A3) becomes "S"
&#934; (U+03A6) becomes "F"

Greek letters that are not in cp437 come back as 
question marks, as expected (I guess):
&#932; (U+03A4) becomes "?"
&#933; (U+03A5) becomes "?"

...as do some Hebrew letters and Japanese hiragana:
&#1488; (U+05D0) becomes "?"
&#1492; (U+05D4) becomes "?"
&#1505; (U+05E1) becomes "?"
&#12354; (U+305F) becomes "?"
&#12358; (U+3046) becomes "?"
&#12383; (U+3042) becomes "?"

I don&#039;t know if this is something that anyone cares 
about, since the filenames are useless anyway, but it 
does seem to be unintended behavior.

(And before you ask, it&#039;s just a theoretical exercise; I 
have no urgent need to use os.listdir with non-Unicode 
directory names on Windows.)

----------------------------------------------------------------------

>Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-31 03:28

Message:
Logged In: YES 
user_id=371366

I've added a script that demonstrates the issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926427&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 05:56:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 05:56:56 2004
Subject: [ python-Bugs-923576 ] Incorrect __name__ assignment
Message-ID: <E1B8dOt-0005uR-00@sc8-sf-web2.sourceforge.net>

Bugs item #923576, was opened at 2004-03-26 00:43
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: El cepi (elcepi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect __name__ assignment

Initial Comment:
When you use PythonLauncher or PythonIDE the value of 
__name__ is incorrectly assigned.

For example, in the attached file the output is "The module 
has been load" when the module is fun in PythonIDE.

With this you can not disciminate between the code you 
should run when you load the module and when you try to 
run it.



----------------------------------------------------------------------

>Comment By: Michael Hudson (mwh)
Date: 2004-03-31 11:56

Message:
Logged In: YES 
user_id=6656

Terry, this bug is in the 'Macintosh' category for a reason :-)

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-30 18:14

Message:
Logged In: YES 
user_id=593130

When making a bug report, please include at least the Python 
version.  The system you are running on is sometimes 
essential info also.

I am not familiar with either PythonLauncher or PythonIDE.  
Just PyWin and Idle.  If they are third-party items not part of 
the distribution, then this report should go to their authors.

'When you use' is also somewhat vague.  Saying what 
command line option or menu entry or buttom you used to 
run/load might also get a better answer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 10:07:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 11:02:35 2004
Subject: [ python-Bugs-923576 ] Incorrect __name__ assignment
Message-ID: <E1B8hIz-0006PN-00@sc8-sf-web1.sourceforge.net>

Bugs item #923576, was opened at 2004-03-25 19:43
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: El cepi (elcepi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect __name__ assignment

Initial Comment:
When you use PythonLauncher or PythonIDE the value of 
__name__ is incorrectly assigned.

For example, in the attached file the output is "The module 
has been load" when the module is fun in PythonIDE.

With this you can not disciminate between the code you 
should run when you load the module and when you try to 
run it.



----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-31 10:07

Message:
Logged In: YES 
user_id=593130

Lesson learned to check that header field.  Inappropriate 
comments withdrawn.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-03-31 05:56

Message:
Logged In: YES 
user_id=6656

Terry, this bug is in the 'Macintosh' category for a reason :-)

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-30 12:14

Message:
Logged In: YES 
user_id=593130

When making a bug report, please include at least the Python 
version.  The system you are running on is sometimes 
essential info also.

I am not familiar with either PythonLauncher or PythonIDE.  
Just PyWin and Idle.  If they are third-party items not part of 
the distribution, then this report should go to their authors.

'When you use' is also somewhat vague.  Saying what 
command line option or menu entry or buttom you used to 
run/load might also get a better answer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 11:56:25 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 11:56:37 2004
Subject: [ python-Bugs-833405 ] urllib.urlencode doesn't work for output
	from cgi.parse_qs
Message-ID: <E1B8j0r-0005eV-00@sc8-sf-web2.sourceforge.net>

Bugs item #833405, was opened at 2003-10-30 17:39
Message generated for change (Comment added) made by myers_carpenter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833405&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Myers Carpenter (myers_carpenter)
Assigned to: Nobody/Anonymous (nobody)
Summary: urllib.urlencode doesn't work for output from cgi.parse_qs

Initial Comment:
>>>
urllib.urlencode(cgi.parse_qsl(&#039;ext=.jpg&outquality=56&#039;))
&#039;ext=.jpg&outquality=56&#039;
>>>
urllib.urlencode(cgi.parse_qs(&#039;ext=.jpg&outquality=56&#039;))
&#039;ext=%5B%27.jpg%27%5D&outquality=%5B%2756%27%5D&#039;

"%5B%27" = "[&#039;"

 

----------------------------------------------------------------------

>Comment By: Myers Carpenter (myers_carpenter)
Date: 2004-03-31 11:56

Message:
Logged In: YES 
user_id=335935

Can you name one web app that you know will take args in the
form of "ext=[27.jpg]"?  Why not do some type inspection to
see what types you are dealing with?  What is the use of
encoding a list in a url using python syntax?

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-31 01:01

Message:
Logged In: YES 
user_id=371366

As per the urlencode() API documentation, you are passing in 
sequences, so you need to set the doseq flag.

>>> urllib.urlencode(cgi.parse_qs
('ext=.jpg&outquality=56'),doseq=1)
'ext=.jpg&outquality=56'

I recommend that this bug report be closed as Invalid.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=833405&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 12:09:05 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 12:09:08 2004
Subject: [ python-Bugs-926807 ] pdb sometimes sets breakpoints in the wrong
	location
Message-ID: <E1B8jD7-000245-00@sc8-sf-web4.sourceforge.net>

Bugs item #926807, was opened at 2004-03-31 09:09
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926807&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb sometimes sets breakpoints in the wrong location

Initial Comment:

If one attempts to set a breakpoint in one line function:
e.g for this code:

def f(x): return x*x

z=23

pdb silently sets a breakpoint on the line right after
the function definition (i.e. outside the function body!):

../python pdb.py.v1.66 pdb_one_line_func 
> <string>(1)?()
(Pdb) b f
Breakpoint 1   /src/Lib/pdb_one_line_func:3
(Pdb) c
> /src/Lib/pdb_one_line_func(3)?()
-> z=23

It&#039;s probably acceptable to limit pdb breakpoints to
multiline functions, but i don&#039;t think, it&#039;s acceptable
to create wrong breakpoints.

Note: that anyone attempting to fix this should also
take a look at bug 875404 (global statment causes
breakpoints..), as both bugs are caused by
pdb.checkline() logic


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926807&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 12:11:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 12:11:54 2004
Subject: [ python-Bugs-926807 ] pdb sometimes sets breakpoints in the wrong
	location
Message-ID: <E1B8jFm-00088p-00@sc8-sf-web3.sourceforge.net>

Bugs item #926807, was opened at 2004-03-31 09:09
Message generated for change (Comment added) made by isandler
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926807&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: Ilya Sandler (isandler)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdb sometimes sets breakpoints in the wrong location

Initial Comment:

If one attempts to set a breakpoint in one line function:
e.g for this code:

def f(x): return x*x

z=23

pdb silently sets a breakpoint on the line right after
the function definition (i.e. outside the function body!):

../python pdb.py.v1.66 pdb_one_line_func 
> <string>(1)?()
(Pdb) b f
Breakpoint 1   /src/Lib/pdb_one_line_func:3
(Pdb) c
> /src/Lib/pdb_one_line_func(3)?()
-> z=23

It&#039;s probably acceptable to limit pdb breakpoints to
multiline functions, but i don&#039;t think, it&#039;s acceptable
to create wrong breakpoints.

Note: that anyone attempting to fix this should also
take a look at bug 875404 (global statment causes
breakpoints..), as both bugs are caused by
pdb.checkline() logic


----------------------------------------------------------------------

>Comment By: Ilya Sandler (isandler)
Date: 2004-03-31 09:11

Message:
Logged In: YES 
user_id=971153

Sorry, accidentally resubmitted the bug

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926807&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 13:06:09 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 13:06:18 2004
Subject: [ python-Bugs-925500 ] os.py uses #' - undocumented magic?
Message-ID: <E1B8k6L-0004xJ-00@sc8-sf-web3.sourceforge.net>

Bugs item #925500, was opened at 2004-03-29 12:41
Message generated for change (Comment added) made by montanaro
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Invalid
Priority: 3
Submitted By: Jim Jewett (jimjjewett)
Assigned to: Skip Montanaro (montanaro)
Summary: os.py uses #' - undocumented magic?

Initial Comment:
os.py wraps the first section of code (determining which 
operating system and path to use) in lines containing just 

#&#039;

(A comment start followed by a single-quote start.)

This looks like unexplained magic.  It should either be 
deleted, or commented to indicate why it is there.



----------------------------------------------------------------------

>Comment By: Skip Montanaro (montanaro)
Date: 2004-03-31 12:06

Message:
Logged In: YES 
user_id=44345

It's not magic.  It's just there to get python-mode back in
sync.  Emacs's notion of string characters doesn't include
triple-quoted strings, so if you have something like:

    """Madam, I'm Adam."""

it can look unbalanced to python-mode (lone apostrophe). 
The #' simply "closes" that apostrophe.

I don't think it warrants a comment everywhere it's used. 
It's just something people need to understand.


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2004-03-29 16:09

Message:
Logged In: YES 
user_id=21627

Assigning to Skip, who added these in os.py 1.41, with a
check-in message of

added several more __all__ lists


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=925500&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 14:14:19 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 14:14:52 2004
Subject: [ python-Bugs-923576 ] Incorrect __name__ assignment
Message-ID: <E1B8lAJ-0002KO-00@sc8-sf-web2.sourceforge.net>

Bugs item #923576, was opened at 2004-03-26 00:43
Message generated for change (Comment added) made by elcepi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

Category: Macintosh
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: El cepi (elcepi)
Assigned to: Nobody/Anonymous (nobody)
Summary: Incorrect __name__ assignment

Initial Comment:
When you use PythonLauncher or PythonIDE the value of 
__name__ is incorrectly assigned.

For example, in the attached file the output is "The module 
has been load" when the module is fun in PythonIDE.

With this you can not disciminate between the code you 
should run when you load the module and when you try to 
run it.



----------------------------------------------------------------------

>Comment By: El cepi (elcepi)
Date: 2004-03-31 19:14

Message:
Logged In: YES 
user_id=1006669

No problem tjreedy

Here are the version information relevant to the report

* PythonIDE
  Version 1.0.1
  Python 2.3.3 (#1 March 12 2004, 13:49:58)
  GCC 3.1 20020420 (prerelease)

* PythonLauncher
  Version 0.1

* Mac OS X 
  Version 10.2.8 (6R73) 
  Darwin Kernel Version 6.8: Wed Sep 10 15:20:55 PDT 2003;
       root:xnu/xnu-344.49.obj~2/RELEASE_PPC

* Machine
  PowerBook G4 (version = 11.3)

This bug cause that your applications behave different when are 
executed from PythonLauncher or PythonIDE than from the shell 

For example, If I double-click the foo.pyc file it is executed by 
PythonLauncher but it execute the code under __name__==?test? 
instead of under __name__==?__main__? as append when I run it 
from the shell.


----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-31 15:07

Message:
Logged In: YES 
user_id=593130

Lesson learned to check that header field.  Inappropriate 
comments withdrawn.

----------------------------------------------------------------------

Comment By: Michael Hudson (mwh)
Date: 2004-03-31 10:56

Message:
Logged In: YES 
user_id=6656

Terry, this bug is in the 'Macintosh' category for a reason :-)

----------------------------------------------------------------------

Comment By: Terry J. Reedy (tjreedy)
Date: 2004-03-30 17:14

Message:
Logged In: YES 
user_id=593130

When making a bug report, please include at least the Python 
version.  The system you are running on is sometimes 
essential info also.

I am not familiar with either PythonLauncher or PythonIDE.  
Just PyWin and Idle.  If they are third-party items not part of 
the distribution, then this report should go to their authors.

'When you use' is also somewhat vague.  Saying what 
command line option or menu entry or buttom you used to 
run/load might also get a better answer.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=923576&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 14:34:01 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 14:34:06 2004
Subject: [ python-Bugs-926910 ] Overenthusiastic check in Swap?
Message-ID: <E1B8lTN-0007Pt-00@sc8-sf-web4.sourceforge.net>

Bugs item #926910, was opened at 2004-03-31 14:34
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926910&group_id=5470

Category: Threads
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: benson margulies (benson_basis)
Assigned to: Nobody/Anonymous (nobody)
Summary: Overenthusiastic check in Swap?

Initial Comment:
When Py_DEBUG is turned on, PyThreadState_Swap 
calls in a fatal error if the two different thread states 
are ever used for a thread.

I submit that this is not a good check. The 
documentation encourages us to write code that 
creates and destroys thread states as C threads come 
and go. Why can&#039;t a single C thread make a thread 
state, release it, and then make another one later?

One particular usage pattern:

We have an API that initializes embedded python. Then 
we have another API where the callers are allowed to be 
in any C thread. The second API has no easy way to tell 
if a thread used for it happens to be the same thread 
that made the initialization call. As the code is written 
now, any code running on the &#039;main thread&#039; is required 
to fish out the build-in main-thread thread state.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926910&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 14:43:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 14:43:51 2004
Subject: [ python-Bugs-474836 ] Tix not included in windows distribution
Message-ID: <E1B8lcm-00058H-00@sc8-sf-web2.sourceforge.net>

Bugs item #474836, was opened at 2001-10-25 13:22
Message generated for change (Comment added) made by theller
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Thomas Heller (theller)
Summary: Tix not included in windows distribution

Initial Comment:
Although there is a Tix.py available, there is no Tix
support in the precomiled 
Python-distribution for windows. So 

import Tix

works fine, but

root = Tix.Tk()

results in 

TclError: package not found. 

It is possible to circumvent this problem by installing
a regular Tcl/Tk distribution (e.g. in
c:\programme\tcl) and installing Tix in the regular
Tcl-path (i.e. tcl\lib).

Mathias

----------------------------------------------------------------------

>Comment By: Thomas Heller (theller)
Date: 2004-03-31 21:43

Message:
Logged In: YES 
user_id=11105

I'm willing to do some work to include tix in Python 2.3.4,
if someone can update the instructions.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-24 18:16

Message:
Logged In: YES 
user_id=764593

Note that the problem is still there in 2.3.3; if it can't be fixed, 
could the documentation at least mention that Tix requires 
3rd-party libraries on Windows?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-03 15:15

Message:
Logged In: YES 
user_id=21627

Reassigning to Thomas, who is doing Windows releases these days.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-10-03 15:13

Message:
Logged In: YES 
user_id=31435

Unassigned (doesn't look like I'll ever get time for this).

----------------------------------------------------------------------

Comment By: Aaron Optimizer Digulla (digulla)
Date: 2003-10-03 13:10

Message:
Logged In: YES 
user_id=606

loewis, when will your package show up in the official Python 
distribution? It's still not there in 2.3.2 :-(

----------------------------------------------------------------------

Comment By: Aaron Optimizer Digulla (digulla)
Date: 2003-07-28 15:22

Message:
Logged In: YES 
user_id=606

The Tix8184.dll is still missing in Python 2.3c2. The included 
Tix8183.dll (which is in the directory tcl\tix8.1\ along with a 
couple of other dlls -> can't be found by Python) is linked 
against Tcl/Tk 8.3.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-06-15 14:40

Message:
Logged In: YES 
user_id=21627

I found that the instructions need slight modification: In step 
2, use tk...\mkd.bat for mkdir. Apart from that, these 
instructions work fine for me, now. I have made a binary 
release of tix8.1 for Python 2.3 at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip

The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to 
tcl. It differs from the standard tix8.1 subdirectory only in 
fixing the path to the DLLs directory.

To test whether this works, execute Demo/tix/tixwidgets.py.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-04-26 12:22

Message:
Logged In: YES 
user_id=21627

I still think Python should include Tix. Here are some 
instructions on how to make Tix 8.1.4 work:

1. Unpack as a sibling of tcl8.4.1 and tk8.4.1
2. Edit win\common.mk, to set the following variables
    TCL_VER=8.4
    INSTALLDIR=<directory to pick up installation from later>
    MKDIR=mkdir
3. Edit win\makefile.vc, to set the following variables
    TOOLS32=<directory of cl>
    TOOLS32_rc=<directory of rc.exe>
4. Edit win\tk\pkgindex.tcl, to replace
    lappend dirs ../../Dlls
    with
    lappend dirs [file join [file dirname [info nameofexe]] Dlls]
5. nmake -f makefile.vc
6. nmake -f makefile.vc install
7. Copy INSTALLDIR\bin\tix8184.dll to <python>\DLLs
8. Optionally copy tix8184.lib somewhere
9. copy INSTALLDIR\lib\tix8.1 into <python>\tcl

With these instructions, invoking t.tk.eval("package require 
Tix") succeeds. For some reason, Tix won't still find any of 
the commands; I'll investigate this later.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-12-11 10:14

Message:
Logged In: YES 
user_id=33229

My you're courageous - going with a version of Tcl that doesn't
even pass its own tests :-) Been there, seen it, done it ....

8.1.4 will be out this week, which compiles with 8.4 but I don't
expect it to "support" 8.4 for a while yet (they added more problems
in 8.4.1). 8.3.5 is definitely "supported".

Check back with me before 2.3 goes into beta and I'll do
another minor release if necessary. Maybe Tk will test clean then.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-20 02:36

Message:
Logged In: YES 
user_id=31435

Parents shouldn't disagree in front of their children <wink>.

Not all the Tcl or Tk tests (their tests, not ours) passed 
when I built 8.4.1, but I couldn't (and can't) make time to 
dig into that, and all the Python stuff I tried worked fine.  So 
I don't fear 8.4, and am inclined to accept Martin's 
assurance that 8.4 is best for Python.

We intend to put out the first 2.3 Python alpha by the end 
of the year, and my bet is it won't be a minute before that.  
If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final 
release out well before then.  Yes?  No?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-11-19 23:12

Message:
Logged In: YES 
user_id=21627

I think the recommendation cannot apply to Python; I'm very
much in favour of releasing Python 2.3 with Tk 8.4.x. 

So the question then is whether Python 2.3 should include
Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can
be expected.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-19 20:10

Message:
Logged In: YES 
user_id=33229

Look on http://tix.sourceforge.net/download.shtml for
Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite,
but there are still issues with Tk 8.4 and it has not been
widely tested with yet with 8.4.1, so we still recommend 8.3.5.
(Tcl major releases often aren't stable until patch .3 or so.)

If you have any problems let me know directly by email
and I'll try and help.








----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-18 17:35

Message:
Logged In: YES 
user_id=31435

Does Tix 8.1.3 play with Tcl/Tk 8.4.1?  The 2.3. Windows 
distro is set up to include the latter now.  The 
win\common.mak file from Tix 8.1.3 doesn't have a section 
for Tcl/Tk 8.4, though.

There appear to be several reasons Tix won't compile on 
my box anyway without fiddling the Tix makefiles (e.g., my 
VC doesn't live in \DevStudio), so before spending more 
time on that I'd like to know whether it's doomed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 15:52

Message:
Logged In: YES 
user_id=6380

I support this. Tim, I know you're not a big Tk user (to say
the least). I'll offer to help in person.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 08:30

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 06:34

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 04:34

Message:
Logged In: YES 
user_id=6380

Yes, for 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 02:48

Message:
Logged In: YES 
user_id=31435

Guido, do you want me to spend time on this?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2002-03-07 14:38

Message:
Logged In: YES 
user_id=361926

Thanks.

Mathias

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-02-25 13:57

Message:
Logged In: YES 
user_id=21627

The zip file is slightly too large for SF, so it is now at

http://www.informatik.hu-
berlin.de/~loewis/python/tix813win.zip

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-02-25 13:56

Message:
Logged In: YES 
user_id=21627

Building Tix from sources is non-trivial, and I could not 
find any recent Windows binary distribution (based on Tix 
8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, 
as a drop-in into the Python binary distribution.

Compared to the original distribution, only tix8.1
\pkgIndex.tcl required tweaking, to tell it that 
tix8183.dll can be found in the DLLs subdirectory.

Also, unless TIX_LIBRARY is set, the Tix tcl files *must* 
live in tcl\tix8.1, since tix8183.dll will look in 
TCL_LIBRARY\..\tix<TIX_VERSION> (among other locations).

If a major Tcl release happens before Python 2.3 is 
released (and it is then still desirable to distribute 
Python with Tix), these binaries need to be regenerated.

Would these instructions (unpack zip file into 
distribution tree) be precise enough to allow 
incorporation into the windows installer?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2001-10-29 12:53

Message:
Logged In: YES 
user_id=361926

As mentioned in the mail above (by me, Mathias), Tix is a
package belonging to Tcl/Tk (to be found on sourceforge:
tix.sourceforge.net, or via the Python home page - tkinter
link). 

Everything needed can be found there, just read about it
(and dont forget about the winking,  eyes might be getting
dry)

Mathias



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-25 20:26

Message:
Logged In: YES 
user_id=31435

I don't know anything about Tix, so if somebody wants this 
in the Windows installer, they're going to have to explain 
exactly (by which I mean exactly <0.5 wink>) what's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 15:03:49 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 15:03:59 2004
Subject: [ python-Bugs-474836 ] Tix not included in windows distribution
Message-ID: <E1B8lwD-0001hl-00@sc8-sf-web4.sourceforge.net>

Bugs item #474836, was opened at 2001-10-25 13:22
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

Category: Tkinter
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Thomas Heller (theller)
Summary: Tix not included in windows distribution

Initial Comment:
Although there is a Tix.py available, there is no Tix
support in the precomiled 
Python-distribution for windows. So 

import Tix

works fine, but

root = Tix.Tk()

results in 

TclError: package not found. 

It is possible to circumvent this problem by installing
a regular Tcl/Tk distribution (e.g. in
c:\programme\tcl) and installing Tix in the regular
Tcl-path (i.e. tcl\lib).

Mathias

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-31 22:03

Message:
Logged In: YES 
user_id=21627

The instructions from 2003-04-26/2003-06-15 should still be
valid.

For 2.4, the story will be different, as Tix does not
currently build with VC7.

----------------------------------------------------------------------

Comment By: Thomas Heller (theller)
Date: 2004-03-31 21:43

Message:
Logged In: YES 
user_id=11105

I'm willing to do some work to include tix in Python 2.3.4,
if someone can update the instructions.

----------------------------------------------------------------------

Comment By: Jim Jewett (jimjjewett)
Date: 2004-02-24 18:16

Message:
Logged In: YES 
user_id=764593

Note that the problem is still there in 2.3.3; if it can't be fixed, 
could the documentation at least mention that Tix requires 
3rd-party libraries on Windows?


----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-10-03 15:15

Message:
Logged In: YES 
user_id=21627

Reassigning to Thomas, who is doing Windows releases these days.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2003-10-03 15:13

Message:
Logged In: YES 
user_id=31435

Unassigned (doesn't look like I'll ever get time for this).

----------------------------------------------------------------------

Comment By: Aaron Optimizer Digulla (digulla)
Date: 2003-10-03 13:10

Message:
Logged In: YES 
user_id=606

loewis, when will your package show up in the official Python 
distribution? It's still not there in 2.3.2 :-(

----------------------------------------------------------------------

Comment By: Aaron Optimizer Digulla (digulla)
Date: 2003-07-28 15:22

Message:
Logged In: YES 
user_id=606

The Tix8184.dll is still missing in Python 2.3c2. The included 
Tix8183.dll (which is in the directory tcl\tix8.1\ along with a 
couple of other dlls -> can't be found by Python) is linked 
against Tcl/Tk 8.3.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-06-15 14:40

Message:
Logged In: YES 
user_id=21627

I found that the instructions need slight modification: In step 
2, use tk...\mkd.bat for mkdir. Apart from that, these 
instructions work fine for me, now. I have made a binary 
release of tix8.1 for Python 2.3 at

http://www.dcl.hpi.uni-potsdam.de/home/loewis/tix8.1.zip

The tix8184.dll goes to DLLs, the tix8.1 subdirectory goes to 
tcl. It differs from the standard tix8.1 subdirectory only in 
fixing the path to the DLLs directory.

To test whether this works, execute Demo/tix/tixwidgets.py.

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2003-04-26 12:22

Message:
Logged In: YES 
user_id=21627

I still think Python should include Tix. Here are some 
instructions on how to make Tix 8.1.4 work:

1. Unpack as a sibling of tcl8.4.1 and tk8.4.1
2. Edit win\common.mk, to set the following variables
    TCL_VER=8.4
    INSTALLDIR=<directory to pick up installation from later>
    MKDIR=mkdir
3. Edit win\makefile.vc, to set the following variables
    TOOLS32=<directory of cl>
    TOOLS32_rc=<directory of rc.exe>
4. Edit win\tk\pkgindex.tcl, to replace
    lappend dirs ../../Dlls
    with
    lappend dirs [file join [file dirname [info nameofexe]] Dlls]
5. nmake -f makefile.vc
6. nmake -f makefile.vc install
7. Copy INSTALLDIR\bin\tix8184.dll to <python>\DLLs
8. Optionally copy tix8184.lib somewhere
9. copy INSTALLDIR\lib\tix8.1 into <python>\tcl

With these instructions, invoking t.tk.eval("package require 
Tix") succeeds. For some reason, Tix won't still find any of 
the commands; I'll investigate this later.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-12-11 10:14

Message:
Logged In: YES 
user_id=33229

My you're courageous - going with a version of Tcl that doesn't
even pass its own tests :-) Been there, seen it, done it ....

8.1.4 will be out this week, which compiles with 8.4 but I don't
expect it to "support" 8.4 for a while yet (they added more problems
in 8.4.1). 8.3.5 is definitely "supported".

Check back with me before 2.3 goes into beta and I'll do
another minor release if necessary. Maybe Tk will test clean then.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-20 02:36

Message:
Logged In: YES 
user_id=31435

Parents shouldn't disagree in front of their children <wink>.

Not all the Tcl or Tk tests (their tests, not ours) passed 
when I built 8.4.1, but I couldn't (and can't) make time to 
dig into that, and all the Python stuff I tried worked fine.  So 
I don't fear 8.4, and am inclined to accept Martin's 
assurance that 8.4 is best for Python.

We intend to put out the first 2.3 Python alpha by the end 
of the year, and my bet is it won't be a minute before that.  
If Tix 8.1.4 is at RC3 now, I'd *guess* you'll have a final 
release out well before then.  Yes?  No?

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-11-19 23:12

Message:
Logged In: YES 
user_id=21627

I think the recommendation cannot apply to Python; I'm very
much in favour of releasing Python 2.3 with Tk 8.4.x. 

So the question then is whether Python 2.3 should include
Tix 8.1.4 or no Tix at all, and at what time Tix 8.1.4 can
be expected.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-19 20:10

Message:
Logged In: YES 
user_id=33229

Look on http://tix.sourceforge.net/download.shtml for
Tix 8.1.4 RC3. It works with Tk 8.4.1 and passes the test suite,
but there are still issues with Tk 8.4 and it has not been
widely tested with yet with 8.4.1, so we still recommend 8.3.5.
(Tcl major releases often aren't stable until patch .3 or so.)

If you have any problems let me know directly by email
and I'll try and help.








----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-11-18 17:35

Message:
Logged In: YES 
user_id=31435

Does Tix 8.1.3 play with Tcl/Tk 8.4.1?  The 2.3. Windows 
distro is set up to include the latter now.  The 
win\common.mak file from Tix 8.1.3 doesn't have a section 
for Tcl/Tk 8.4, though.

There appear to be several reasons Tix won't compile on 
my box anyway without fiddling the Tix makefiles (e.g., my 
VC doesn't live in \DevStudio), so before spending more 
time on that I'd like to know whether it's doomed.

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-11-07 15:52

Message:
Logged In: YES 
user_id=6380

I support this. Tim, I know you're not a big Tk user (to say
the least). I'll offer to help in person.

----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 08:30

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Internet Discovery (idiscovery)
Date: 2002-11-03 06:34

Message:
Logged In: YES 
user_id=33229

I would really like to see Tix in 2.3 and will be glad to help.
AFAIK there are no major issues with tix-8.1.3 and Python 2.x
and it should be a simple drop in of a cannonically compiled Tix.

If there are any issues that need dealing with at Tix's end, I'll be 
glad to put out a new minor release of Tix to address them.

On Python's end I've suggested a fix for http://python.org/sf/564729

FYI, please also see my comments for bug 632323.


----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-03-23 04:34

Message:
Logged In: YES 
user_id=6380

Yes, for 2.3.

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2002-03-10 02:48

Message:
Logged In: YES 
user_id=31435

Guido, do you want me to spend time on this?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2002-03-07 14:38

Message:
Logged In: YES 
user_id=361926

Thanks.

Mathias

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-02-25 13:57

Message:
Logged In: YES 
user_id=21627

The zip file is slightly too large for SF, so it is now at

http://www.informatik.hu-
berlin.de/~loewis/python/tix813win.zip

----------------------------------------------------------------------

Comment By: Martin v. L?wis (loewis)
Date: 2002-02-25 13:56

Message:
Logged In: YES 
user_id=21627

Building Tix from sources is non-trivial, and I could not 
find any recent Windows binary distribution (based on Tix 
8.1). So I'll attach a build of Tix 8.1.3 for Tcl/Tk 8.3, 
as a drop-in into the Python binary distribution.

Compared to the original distribution, only tix8.1
\pkgIndex.tcl required tweaking, to tell it that 
tix8183.dll can be found in the DLLs subdirectory.

Also, unless TIX_LIBRARY is set, the Tix tcl files *must* 
live in tcl\tix8.1, since tix8183.dll will look in 
TCL_LIBRARY\..\tix<TIX_VERSION> (among other locations).

If a major Tcl release happens before Python 2.3 is 
released (and it is then still desirable to distribute 
Python with Tix), these binaries need to be regenerated.

Would these instructions (unpack zip file into 
distribution tree) be precise enough to allow 
incorporation into the windows installer?

----------------------------------------------------------------------

Comment By: Mathias Palm (monos)
Date: 2001-10-29 12:53

Message:
Logged In: YES 
user_id=361926

As mentioned in the mail above (by me, Mathias), Tix is a
package belonging to Tcl/Tk (to be found on sourceforge:
tix.sourceforge.net, or via the Python home page - tkinter
link). 

Everything needed can be found there, just read about it
(and dont forget about the winking,  eyes might be getting
dry)

Mathias



----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2001-10-25 20:26

Message:
Logged In: YES 
user_id=31435

I don't know anything about Tix, so if somebody wants this 
in the Windows installer, they're going to have to explain 
exactly (by which I mean exactly <0.5 wink>) what's needed.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=474836&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 15:11:51 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 15:12:06 2004
Subject: [ python-Bugs-926427 ] OEM codepage chars in mbcs filenames can be
	misinterpreted
Message-ID: <E1B8m3z-0007vJ-00@sc8-sf-web2.sourceforge.net>

Bugs item #926427, was opened at 2004-03-31 06:04
Message generated for change (Comment added) made by loewis
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926427&group_id=5470

Category: Python Library
>Group: 3rd Party
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: Mike Brown (mike_j_brown)
Assigned to: Nobody/Anonymous (nobody)
Summary: OEM codepage chars in mbcs filenames can be misinterpreted

Initial Comment:
My system: Windows XP, English - US locale, Python 
2.3.3

I believe the bug I am reporting here is this:

On Windows XP, when using os.listdir() with a non-
Unicode argument, characters that are not in the 
default locale&#039;s encoding (e.g. Greek capital letter 
Sigma, (U+03A3), is not in windows-1252), but that are 
in the default OEM code page (e.g. Sigma is in cp437), 
get mapped to ASCII characters other than &#039;?&#039;.

For example, things seem to work in a predictable way 
when I put windows-1252 characters into filenames (I 
do this in Explorer and then I see what os.listdir
(r&#039;C:\path\to\the\dir&#039;) returns):

? (U+2014) becomes \x97
? (U+2022) becomes \x95
? (U+00E9) becomes \xe9

But things are much less predictable when I use 
characters from outside this range. I thought I&#039;d try 
some Greek characters first. Some of them (the ones 
that happen to be in cp437, interestingly enough) come 
back as random ASCII letters:

&#920; (U+0398) becomes "T"
&#931; (U+03A3) becomes "S"
&#934; (U+03A6) becomes "F"

Greek letters that are not in cp437 come back as 
question marks, as expected (I guess):
&#932; (U+03A4) becomes "?"
&#933; (U+03A5) becomes "?"

...as do some Hebrew letters and Japanese hiragana:
&#1488; (U+05D0) becomes "?"
&#1492; (U+05D4) becomes "?"
&#1505; (U+05E1) becomes "?"
&#12354; (U+305F) becomes "?"
&#12358; (U+3046) becomes "?"
&#12383; (U+3042) becomes "?"

I don&#039;t know if this is something that anyone cares 
about, since the filenames are useless anyway, but it 
does seem to be unintended behavior.

(And before you ask, it&#039;s just a theoretical exercise; I 
have no urgent need to use os.listdir with non-Unicode 
directory names on Windows.)

----------------------------------------------------------------------

>Comment By: Martin v. L?wis (loewis)
Date: 2004-03-31 22:11

Message:
Logged In: YES 
user_id=21627

There is nothing we can do about this: the mapping from
characters outside the ANSI CP is done completely inside
Windows, using an undocumented algorithm. This algorithm
will typically replace characters with "similar" ones. 

E.g. U+0398 is GREEK CAPITAL LETTER THETA, which is similar
in sound to LATIN CAPITAL LETTER T. Similarity is sometimes
determined by sound, sometimes by glyph-likeness in a
typical font. If no similar character is available, Windows
puts in a question mark. The system call performing the
directory listing does not indicate whether such a mapping
has taken place.

Closing this as third-party bug.

----------------------------------------------------------------------

Comment By: Mike Brown (mike_j_brown)
Date: 2004-03-31 12:28

Message:
Logged In: YES 
user_id=371366

I've added a script that demonstrates the issue.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=926427&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 21:48:38 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 21:49:00 2004
Subject: [ python-Bugs-917055 ] add a stronger PRNG
Message-ID: <E1B8sFy-0001Z5-00@sc8-sf-web4.sourceforge.net>

Bugs item #917055, was opened at 2004-03-16 02:46
Message generated for change (Comment added) made by phr
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Raymond Hettinger (rhettinger)
Summary: add a stronger PRNG

Initial Comment:
The default Mersenne Twister algorithm in the Random
module is very fast but makes no serious attempt to
generate output that stands up to adversarial analysis.
 Besides cryptography applications, this can be a
serious problem in areas like computer games.  Sites
like www.partypoker.com routinely run online
tournaments with prize funds of 100K USD or more. 
There&#039;s big financial incentives to find ways of
guessing your opponent&#039;s cards with better than random
chance probability.  See bug #901285 for some
discussion of possible correlations in Mersenne
Twister&#039;s output.

Teukolsky et al discuss PRNG issues at some length in
their book "Numerical Recipes".  The original edition
of Numerical Recipes had a full blown version of the
FIPS Data Encryption Standard implemented horrendously
in Fortran, as a way of making a PRNG with no easily
discoverable output correlations.  Later editions
replaced the DES routine with a more efficient one
based on similar principles.

Python already has an SHA module that makes a dandy
PRNG.  I coded a sample implementation:

http://www.nightsong.com/phr/python/sharandom.py

I&#039;d like to ask that the Python lib include something
like this as an alternative to MT.  It would be similar
to the existing whrandom module in that it&#039;s an
alternative subclass to the regular Random class.  The
existing Random module wouldn&#039;t have to be changed.

I don&#039;t propose directly including the module above,
since I think the Random API should also be extended to
allow directly requesting pseudo-random integers from
the generator subclass, rather than making them from
floating-point output.  That would allow making the
above subclass work more cleanly.  I&#039;ll make a separate
post about this, but first will have to examine the
Random module source code.

----------------------------------------------------------------------

>Comment By: paul rubin (phr)
Date: 2004-04-01 02:48

Message:
Logged In: YES 
user_id=72053

FYI, this was just announced on the python-crypto list. 
It's a Python wrapper for EGADS, a cross platform
entropy-gathering RNG.  I haven't looked at the code for it
and have no opinion about it.

http://wiki.osafoundation.org/twiki/bin/view/Chandler/PyEgads

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-26 00:36

Message:
Logged In: YES 
user_id=72053

1. OK, though the docs should mention this.

2. One-way just means collision resistant, and we're trying
to make something without a distinguisher, which is a
stronger criterion.  I'm not saying there's any problem with
a single hash; I just don't see an obvious proof that
there's not a problem.  Also it makes me cringe slightly to
keep the seed around as plaintext even temporarily.  The PC
that I'm using (midrange Athlon) can do about a million sha1
hashes per second, so an extra hash per reseed "multiple"
times per second shouldn't be noticible, for reasonable
values of "multiple".

3. Since most of the real computation of this function is in
the sha1 compression, the timing indicates that evaluation
is dominated by interpreter overhead rather than by hashing.
 I presume you're using CPython.  The results may be
different in Jython or with Psyco and different again under
PyPy once that becomes real.  I think we should take the
view that we're designing a mathematical function that
exists independently of any specific implementation, then
figure out what characteristics it should have and implement
those, rather than tailoring it to the peculiarities of
CPython.  

If people are really going to be using this function in
2010, CPython will hopefully be dead and gone (replaced by
PyPy) by then, so that's all the more reason to not worry
about small CPython-specific effects since the function will
outlast CPython.  Maybe also sometime between now and then,
these libraries can be compiled with psyco.

4. OK

5. OK.  Would be good to also change %s for cnt in setstate
to %x.

6. Synchronization can be avoided by hashing different fixed
strings into s0 and s1 at each rehash (I did that in my
version).  I think it's worth doing that just to kick the
hash function away from standard sha.  I actually don't see
much need for the counter in either hash, but you were
concerned about hitting possible short cycles in sha.

7. OK.  WHrandom is already non-threadsafe, so there's
precedent.   I do have to wonder if the 160 bit arithmetic
is slowing things down.  If we don't care about non-IEEE
doubles, we're ok with 53 bits.   Hmm, I also wonder whether
the 160 bit int to float conversion is precisely specified
even for IEEE and isn't an artifact of Python's long int
implementation.  But I guess it doesn't matter, since we're
never hashing those floats.

Re bugs til 2010: oh let's have more confidence than that
:).  I think if we're careful and get the details correct
before deployment, we shouldn't have any problems.  This is
just one screenful of code or so, not complex by most
reasonable standards.  However, we might want post the
algorithm on sci.crypt for comments, since there's some
knowledgeable people there.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 09:08

Message:
Logged In: YES 
user_id=80475

Took another look at #5 and will change str() to hex().

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-25 08:25

Message:
Logged In: YES 
user_id=80475

1.  We don't care about non IEEE.

2.  One-way is one-way, so double hashing is unnecessary. 
Also, I've fielded bug reports from existing user apps that
re-seed very frequently (multiple times per second).

3.  The implementations reflect the results of timing
experiments which showed that the fastest intermediate
representation was hex.

4.  ['0x0'] is necessary to hanlde the case where n==0. 
int('', 16) raises a ValueError while int('0x0', 16) does not.

5.  random() and getrandbits() do not have to go through the
same intermediate steps (it's okay for one to use hex and
the other to use str) -- speed and space issues dominate. 
0x comes up enough in Python, there is little use in tossing
it away for an obscure, hypothetical micro-controller
implementation.

6.  Leaving cnt out of the s1 computation guarantees that it
will never track the updates of s0 -- any syncronization
would be a disaster.  Adding a count or some variant smacks
of desperation rather than reliance on proven hash properties.

7.  The function is already 100 times slower than MT. 
Adding locks will make the situation worse.  It is better to
simply document it as being non-threadsafe.  

Look at back at the mt/sha version.  Its code is much
cleaner, faster, and threadsafe.  It goes a long way towards
meeting your 
request and serving as an alternate generator to validate
simulation results.

If we use the sha/sha version, I'm certain that we will be
fielding bug reports on this through 2010.  It is also
sufficiently complex that it will spawn lengthy, wasteful
discussions and it will create a mine-field for future
maintainers. 


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-25 05:15

Message:
Logged In: YES 
user_id=72053

I'm not sure why the larger state space of mt/sha1 is
supposed to be an advantage, but the other points are
reasonable.  I like the new sha1/sha1 implementation except
for a few minor points (below).  I made the old version
hopefully threadsafe by adding a threading.Lock() object to
the instance and locking it on update. I generally like your
version better so maybe the lock can be added.  Of course
that slows it down even further, but in the context of an
interpreted Python program I feel that the generator is
still fast enough compared to the other stuff the program is
likely to be doing.

Re the new attachment, some minor issues:

1) The number 2.0**-160 is < 10**-50.  This is a valid IEEE
double but on some non-IEEE machines it may be a floating
underflow or even equal to zero.  I don't know if this matters.

2) Paranoia led me to hash the seed twice in the seed
operation in my version, to defeat unlikely
message-extension attacks against the hash function.  I
figured reseeding is infrequent enough that an extra hash
operation doesn't matter.

3) Storing s1 as a string of 40 hex digits in SHARandom2
means that s1+s2 is 60 characters, which means hashing it
will need two sha1 compression operations, slowing it down some.

4) the intiialization of ciphertxt to ["0x0"] instead of []
doesn't seem to do anything useful.  int('123abc', 16) is
valid without the 0x prefix.

5) random() uses hex(cnt) while getrandbits uses str(cnt)
(converting to decimal instead of hex).  I think it's better
to use hex and remove the 0x prefix from the output, which
is cleanest, and simpler to implement on some targets
(embedded microcontroller).  The same goes for the %s
conversion in jumpahead (my version also uses %s there).

6) It may be worthwhile to include cnt in both the s0 and s1
hash updates.  That guarantees the s1 hash never gets the
same input twice.

7) The variable "s1" in getrandbits (instead of self.s1) is
set but never used.

Note in my version of sharandom.py, I didn't put a thread
lock around the tuple assignment in setstate().  I'm not
sure if that's safe or not.  But it looks to me like
random.py in the CVS does the same thing, so maybe both are
unsafe.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-24 11:31

Message:
Logged In: YES 
user_id=80475

I attached a new version of the mt/sha1 combination.

Here are the relative merits as compared sha1/sha1 approach:
* simpiler to implement/maintain since state tracking is builtin
* larger state space (2**19937 vs 2**160)
* faster
* threadsafe

Favoring sha1/sha1:
* uses only one primitive
* easier to replace in situations where MT is not available


----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-22 00:56

Message:
Logged In: YES 
user_id=72053

Two small corrections to below: 1) "in favor of an entropy"
is an editing error--the intended meaning should be obvious.
 2) I meant Bryan Mongeau, not Eric Mongeau.  Bryan's lib is
at <http://eevolved.com/cryptkit/>.  Sorry for any confusion.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-22 00:49

Message:
Logged In: YES 
user_id=72053

I'm very much in favor of an entropy and Bram's suggested
interface of entropy(x) supplying x bytes of randomness is
fine.  Perhaps it should really live in a cryptography API
rather than in the Random API, but either way is ok.  Mark
Moraes wrote a Windows module that gets random numbers from
the Windows CAPI; I put up a copy at

     http://www.nightsong.com/phr/python/winrand.module

For Linux, Cygwin, and *BSD (including MacOS 10, I think),
just read /dev/urandom for random bytes.  However, various
other systems (I think including Solaris) don't include
anything like this.  OpenSSL has an entropy gathering daemon
that might be of some use in that situation.  There's also
the Yarrow generator (http://www.schneier.com/yarrow.html)
and Eric Mongeau(?) wrote  a pure-Python generator a while
back that tried to gather entropy from thread racing,
similar to Java's default SecureRandom class (I consider
that method to be a bit bogus in both Python and Java).

I think, though, simply supporting /dev/*random and the
Windows CAPI is a pretty good start, even if other OS's
aren't supported.  Providing that function in the Python lib
will make quite a few people happy.  A single module
integrating both methods would be great.  I don't have any
Windows dev tools so can't test any wrappers for Mark
Moraes's function but maybe one of you guys can do it.

I'm not too keen on the md5random.py patch for reasons
discussed in the c.l.py thread.  It depends too deeply on
the precise characteristics of both md5 and Mersenne
Twister.  I think for a cryptography-based generator, it's
better to stick to one cryptography-based primitive, and to
use sha instead of md5.  That also helps portability since
it means other environments (maybe including Jython) can
reproduce the PRNG stream without having to re-implement MT,
as long as they have SHA (which is a US federal standard).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 19:50

Message:
Logged In: YES 
user_id=80475

Bram, if you have a patch, I would be happy to look at it. 
Please make it as platform independent as possible (its okay
to have it conditionally compile differently so long as the
API stays the same).  
Submit it as a separate patch and assign to me -- it doesn't
have to be orginal, you can google around to determine prior
art.

----------------------------------------------------------------------

Comment By: Bram Cohen (bram_cohen)
Date: 2004-03-21 19:34

Message:
Logged In: YES 
user_id=52561

The lack of a 'real' entropy source is the gap which can't
be fixed with an application-level bit of code. I think
there are simple hooks for this on all systems, such as
/dev/random on linux, but they aren't cross platform. A
unified API which always calls the native entropy hook would
be a very good thing.

An example of a reasonable API would be to have a module
named entropy, with a single function entropy(x) which
returns a random string of length x. This is a problem which
almost anyone writing a security-related application runs
into, and lots of time is wasted writing dubious hacks to
harvest entropy when a single simple library could magically
solve it the right way.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-21 17:33

Message:
Logged In: YES 
user_id=80475

Attaching my alternative.  If it fulfills your use case, let
me know and I'll apply it.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 08:51

Message:
Logged In: YES 
user_id=72053

Updated version of sharandom.py is at same url.  It folds a
counter into the hash and also includes a getrandbits method.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-18 06:27

Message:
Logged In: YES 
user_id=72053

I don't mind dropping the time() auto-seed but I think that
means eliminating any auto-seed, and requiring a
user-supplied seed.  

There is no demonstrable minimum period for the SHA-OFB and
it would be bad if there was, since it would then no longer
act like a PRF.  Note that the generator in the sample code
actually comes from two different SHA instances and thus its
expected period is about 2**160.  Anyway, adding a simple
counter (incrementing by 1 on every SHA call) to the SHA
input removes any lingering chance of a repeating sequence.
 I'll update the code to do that.  It's much less ugly than
stirring in Mersenne Twister output.

I don't have Python 2.4 yet but will look at it when I get a
chance.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-17 11:27

Message:
Logged In: YES 
user_id=80475

It has some potential for being added.  That being said, try
to avoid a religious fervor.

I would like to see considerably more discussion and
evolution first.

The auto-seeding with time *must* be dropped -- it is not
harmonious with the goal of creating a secure random
sequence.  It is okay for the a subclass to deviate in this way.

Also, I was soliciting references stronger than (I don't
know of any results ... It is generally considered ... ). 
If we put this in, people are going to rely on it.  The docs
*must* include references indicating the strengths and
weaknesses of the approach.  It should also concisely say
why it works (a summary proof that makes it clear how a
one-way digest function can be tranformed into a sequence
generator that is cryptographicly strong to both the left
and right with the latter being the one that is not obvious).

Not having a demonstrable minimum period is also bad. 
Nothing in the  discussion so far precludes the existence of
a bad seed that has a period of only 1 or 2.  See my
suggestion on comp.lang.python for a means of mitigating
this issue.

With respect to the randint question, be sure to look at the
current Py2.4 source for random.py.  The API is expanded to
include and an option method, getrandbits().  That in turn
feeds the other integer methods without the int to float to
int dance.

Upon further consideration, I think the export control
question is moot since we're using an existing library
function and not really expressing new art.

----------------------------------------------------------------------

Comment By: paul rubin (phr)
Date: 2004-03-17 09:05

Message:
Logged In: YES 
user_id=72053

There are no research results that I know of that can
distinguish the output of sha1-ofb from random output in any
practical way.  To find such a distinguisher would be a
significant result.  It's a safe bet that cryptographers
have searched for distinguishers, though I don't promise to
have heard of every result that's been published.  I'll ask
on sci.crypt if anyone else has heard of such a thing, if
you want.  SHA1-HMAC is generally considered to be
indistinguishable from a PRF (pseudorandom function, i.e. a
function selected at random from the space of all functions
from arbitrary strings to 160-bit outputs; this term is from
concrete security theory).  MD5 is deprecated these days and
there's no point to using it instead of sha1 for this.

I'm not sure what happens if randint is added to the API. 
If you subclass Random and don't provide a randint method,
you inherit from the base class, which can call
self.random() to get floats to make the ints from.

US export restrictions basically don't exist any more.  In
principle, if you want to export something, you're supposed
to send an email to an address at the commerce department,
saying the name of the program and the url where it can be
obtained and a few similar things.  In practice, email to
that address is ignored, they never check anything.  I heard
the address even stopped working for a while, though they
may have fixed it since then.  See
http://www.bxa.doc.gov/Encryption/ for info.  I've emailed
notices to the address a few times and never heard back
anything.  Anyway, I don't think this should count as
cryptography; it's simply using a cryptographic hash
function as an PRNG to avoid the correlations in other
PRNG's; scientific rationale for doing that is given in the
Numerical Recipes book mentioned above.

The code that I linked uses the standard API but I wonder if
the floating point output is optimally uniform, i.e. the
N/2**56 calculation may not be exactly the right thing for
an ieee float64.

Using the time of day is what the Random docs say to do by
default.  You're correct that any security application needs
to supply a higher entropy seed.

I would like it very much if the std lib included a module
that read some random bytes from the OS for OS's that
support it.  That means reading /dev/urandom on recent
Un*x-ish systems or Cygwin, or calling CryptGenRandom on
Windows.  Reading /dev/urandom is trivial, and there's a guy
on the pycrypt list who wrote a Windows function to call
CryptGenRandom and return the output through the Python API.
 I forwarded the function to Guido with the author's
permission but nothing seemed to happen with it.  However,
this gets away from this sharandom subclass.  I'd like to
make a few more improvements to the module but after that I
think it can be dropped into the lib.  Let me know what you
think.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:52

Message:
Logged In: YES 
user_id=80475

One other thought:  if cryptographic strength is a goal, then 
seeding absolutely should require a long seed (key) as an 
input and the time should *never* be used.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2004-03-16 11:49

Message:
Logged In: YES 
user_id=80475

It would have been ideal if the Random API had been 
designed with an integer generator at the core and floating 
point as a computed value, but that it the way it has been for 
a long time and efforts to switch it over would likely result in 
either incompatibility with existing subclasses or introducing 
new complexity (making it even harder to subclass).  I think 
the API should be left alone until Py3.0.

The attached module would make a good recipe on ASPN 
where improvements and critiques can be posted.  Do you 
have links to research showing that running SHA-1 in a 
cipher block feedback mode results in a cryptographically 
strong random number generator -- the result seems likely, 
but a research link would be great.  Is there a link to 
research showing the RNG properties of the resulting 
generator (period, equidistribution, passing tests for 
randomness, etc)?  Also, is there research showing the 
relative merits of this approach vs MD5, AES, or DES?

If something like this gets added to the library, I prefer it to 
be added to random.py using the existing API.  Adding yet 
another random module would likely do more harm than 
good.

One other question (I don't know the answer to this):  would 
including a cryptographically strong RNG trigger US export 
restrictions on the python distribution?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=917055&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 23:07:17 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 23:07:22 2004
Subject: [ python-Bugs-927248 ] Python segfaults when freeing "deep" objects
Message-ID: <E1B8tU5-0004A9-00@sc8-sf-web3.sourceforge.net>

Bugs item #927248, was opened at 2004-03-31 23:07
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470

Category: Python Interpreter Core
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Jp Calderone (kuran)
Assigned to: Nobody/Anonymous (nobody)
Summary: Python segfaults when freeing "deep" objects

Initial Comment:
An example to produce this behavior:

>>> f = lambda: None
>>> for i in range(1000000):
...     f = f.__call__
... 
>>> f = None
Segmentation fault


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=927248&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 23:09:50 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 23:10:02 2004
Subject: [ python-Bugs-796042 ] sdist ignores scripts argument in setup
Message-ID: <E1B8tWY-00076h-00@sc8-sf-web1.sourceforge.net>

Bugs item #796042, was opened at 2003-08-27 11:09
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796042&group_id=5470

Category: Distutils
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Anna Ravenscroft (annarave)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: sdist ignores scripts argument in setup

Initial Comment:
When writing the setup script for a distribution, section 3.4 explains:

3.4 Installing Scripts

So far we have been dealing with pure and non-pure Python modules, which are usually not run by themselves but imported by scripts.

Scripts are files containing Python source code, intended to be started from the command line. Scripts don&#039;t require Distutils to do anything very complicated. The only clever feature is that if the first line of the script starts with #! and contains the word ``python&#039;&#039;, the Distutils will adjust the first line to refer to the current interpreter location. 

The scripts option simply is a list of files to be handled in this way. From the PyXML setup script: 


setup (...
       scripts = [&#039;scripts/xmlproc_parse&#039;, &#039;scripts/xmlproc_val&#039;]
      )

Unfortunately, this doesn&#039;t work with sdist unless you ALSO create a manifest.in file. Otherwise, it silently ignores the scripts listed in setup. bdist works just fine, so it&#039;s apparently something wrong in sdist.

Please fix this. Thank you.

Anna Ravenscroft

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-31 23:09

Message:
Logged In: YES 
user_id=3066

Backported for Python 2.3.4 as:

Lib/distutils/command/build_scripts.py  1.21.8.1
Lib/distutils/command/sdist.py  1.56.14.1
Doc/dist/dist.tex  1.56.8.5


----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-30 21:03

Message:
Logged In: YES 
user_id=3066

Added note about inclusion of scripts in Doc/dist/dist.tex
revision 1.73.  This should be back-ported along with the
actual fix.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-25 17:17

Message:
Logged In: YES 
user_id=3066

This is fixed on the trunk as
Lib/distutils/command/build_scripts.py 1.22 and sdist.py 1.57.

I'm not entirely sure this should be backported for Python
2.3.x, but it probably should be.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=796042&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 23:19:08 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 23:19:24 2004
Subject: [ python-Bugs-832251 ] Wrong reference for specific minidom methods
Message-ID: <E1B8tfY-0004II-00@sc8-sf-web2.sourceforge.net>

Bugs item #832251, was opened at 2003-10-29 04:39
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
Resolution: Fixed
Priority: 6
Submitted By: Francesco Ricciardi (nerby)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Wrong reference for specific minidom methods

Initial Comment:
In the HTML documentation the method in section 
13.7.1  "DOM Objects" of the library reference are listed 
as HTMLParser method.
In the "paper" documentation (PDF-A4 and Ps-A4) the 
same methods have no module reference.

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-31 23:19

Message:
Logged In: YES 
user_id=3066

Backported for Python 2.3.4 as Doc/lib/xmldomminidom.tex
1.8.12.1.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-25 11:51

Message:
Logged In: YES 
user_id=3066

Fixed in Doc/lib/xmldomminidom.tex revision 1.9.
Someone should backport this to Python 2.3.x and close this
bug report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=832251&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 23:23:32 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 23:23:57 2004
Subject: [ python-Bugs-725265 ] urlopen object's read() doesn't read to EOF
Message-ID: <E1B8tjo-0007k4-00@sc8-sf-web1.sourceforge.net>

Bugs item #725265, was opened at 2003-04-21 16:49
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470

Category: Documentation
Group: Python 2.2.2
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Christopher Smith (smichr)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: urlopen object's read() doesn't read to EOF

Initial Comment:
On http://python.org/doc/current/lib/module-urllib.html it says that 
the object returned by urlopen supports the read()method and that 
this and other methods "have the same interface as for file objects 
-- see section 2.2.8".  In that section on page 
http://python.org/doc/current/lib/bltin-file-objects.html it says about 
the read() method that "if the size argument is negative or omitted, 
[read should] read all data until EOF is reached."

I was a bit surprised when a project that students of mine were 
working on were failing when they tried to process the data 
obtained by the read() method on a connection made to a web 
page.  The problem, apparently, is that the read may not obtain all 
of the data requested in the first request and the total response 
has to be built up someting like follows:

import urllib
c=urllib.urlopen("http://www.blakeschool.org")
data = &#039;&#039;
while 1:
	packet=c.read()
	if packet == &#039;&#039;: break
	data+=packet
	
I&#039;m not sure if this is a feature or a bug.  Could a file&#039;s read method 
fail to obtain the whole file in one read(), too?  It seems that either 
the documentation should be changed or the read() method for at 
least urllib objects should be changed.

/c

Christopher P. Smith
The Blake School
Minneapolis, MN


----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-31 23:23

Message:
Logged In: YES 
user_id=3066

Backported to Python 2.3.4 as Doc/lib/liburllib.tex 1.50.8.2.

----------------------------------------------------------------------

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-25 12:04

Message:
Logged In: YES 
user_id=3066

This is an issue with reading from a socket; there's no way
to recognize the end of the stream until the remote end of
the socket actually closes the socket.

I've documented this limitation in Doc/lib/liburllib.tex
1.52.  Someone should backport the patch to Python 2.3.x and
close this report.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=725265&group_id=5470

From noreply at sourceforge.net  Wed Mar 31 23:45:44 2004
From: noreply at sourceforge.net (SourceForge.net)
Date: Wed Mar 31 23:45:48 2004
Subject: [ python-Bugs-793702 ] Section 13.1 HTMLParser documentation error
Message-ID: <E1B8u5I-0000T2-00@sc8-sf-web1.sourceforge.net>

Bugs item #793702, was opened at 2003-08-23 06:01
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793702&group_id=5470

Category: Documentation
Group: Python 2.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Martin Baker (kemokid)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Section 13.1 HTMLParser documentation error

Initial Comment:
The description for handle_comment() says:

     The comment argument is a string containing the
text between the "<!-" and "->" delimiters, but not the
delimiters themselves. For example, the comment
"<!-text->" will cause this method to be called with
the argument &#039;text&#039;.

This is incorrect - the comment delimiters are "<!--"
and "-->" (two hyphens, not just one). Purusing the
code, it appears that the module itself behaves
correctly, so this is only a very minor documentation
bug, but to a HTML newbie, it could be an incredibly
frustrating one.

This was seen on 2003/8/23 at
http://www.python.org/doc/current/lib/module-HTMLParser.html

And a big thank you to all Pythonic volunteers!

----------------------------------------------------------------------

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2004-03-31 23:45

Message:
Logged In: YES 
user_id=3066

Hmm, I must not have noticed this report when I fixed the
bug.  This was fixed in Doc/perl/python.perl 1.144.

I've backported the fix to Python 2.3.4 as
Doc/perl/python.perl 1.137.8.2.

This problem was only an issue for the HTML and iSilo
conversions (the later only because it relied on the HTML
conversion).

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-09-17 02:04

Message:
Logged In: YES 
user_id=80475

My fix didn't take.
Re-opening and assigning to Fred so the job gets done right.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2003-08-24 23:32

Message:
Logged In: YES 
user_id=80475

Thanks for the bug report.
It looks like TeX was considering -- as a special character 
and only printing it once.  Escaping the hyphen ought to fix 
it.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=793702&group_id=5470